In my app that I’m writing, I am use Core Data for persistent store. I have entities that are all related to other entities. I’m getting near completion and am just now about to implement settings for the user. These settings, by the way, are settings that should and will be changed during run-time. For that reason, I am not using the settings bundle.
But what I want to poll is
-
is it okay to have an entity in the same core data model that is unrelated to any other entity (in this case, a settings entity).
-
if so, is it silly to use a plist to store settings when I am already using Core Data for other persistent stores?
I am conflicted because I’ve heard people say, “Why use plists when you are already using Core Data?” Also having a ‘setting’ entity that holds all the possible setting attributes in one entity seems counter-intuitive. By that I mean, the ‘setting’ entity isn’t for one particular setting, nor is it an abstract super class. But maybe that’s just because of the name. If it was called ‘all settings’ or something, then all attributes could be thought of as an individual setting. I’m confusing my self the more I try to explain… :/ so…
What is the best way (in your opinion) to save user settings that can be changed during run-time?
NSUserDefaults is the best way to handle user settings (that’s what NSUserDefaults was made for).