I agree with you, to an extent. NSUserDefaults is very good when used as a
single-level repository for settings data. When you want to categorize the
settings by using collections, it starts to show the same problems that a
regular file has, except slightly worse. Collections are saved as an object,
which means that the collection itself will be mutable when it is read (i.e.
you can replace it), but the contents (nodes and leaves) are not. You must do a
mutable deep copy into a local mutable collection before you are able to modify
settings in the collection. At this point you are now managing the settings
yourself. Of course, saving the data in a plist file has the same problem,
except that you can read in a plist into a collection and have it be mutable
without too much fuss. As soon as you start using collections in your settings
you negate much of the benefits provided by NSUserDefaults, especially if the
collections are very deep.
I have saved preferences using both methods - I prefer using the NSUserDefaults
method, but I still keep a settings manager for the collections that are saved
in the defaults. The system gives you the standard user defaults, and
automatically keeps things like window frames in that version. It also provides
a nice KVC/KVO facility that is a bit more difficult (but doable) with your own
plist file. In short, just about everything that NSUserDefaults gives you, you
can create yourself by saving your own settings plist file. For simple apps, it
is a no-brainer to use NSUserDefaults. For a much more complex app, with
multiple collections needed for settings, it is a much more difficult call -
since you are already having to manage the settings yourself, it may actually
becomes easier to save and read the settings file yourself.
The collection issue also plays a part in using defaults write to modify
settings. To use it, the prefs file needs to be copied, collection extracted
and placed into its own file, change made, then you can use defaults write to
save it back. I would not put my QA people through that process.
As for populating the defaults, you still have to do that yourself with
NSUserDefaults. The [NSUserDefaults registerDefaults:] method does that, If you
are using collections, you still have to create the collection and save it in
the NSDictionary you create to hand to registerDefaults. In my experience with
large apps with complex settings, I already have created the managers for
handling the settings, so this actually becomes less of a feature - the
managers handle reading in the data and giving the user whatever settings they
need. Adding a setting is very easy here.
As usual, in the Mac, there are multiple ways of doing things. Each has its own
tradeoffs. The designer needs to consider the needs of that application in
order to make the right choice for that app. If the app needs to save multiple
collections of data, then it very well may be easier to save those collections
in multiple files, something that NSUserDefaults in not designed to do.
By the way, I also know developers who use an SQLite database for their
settings. It was the right way for their app...
Jack
> On Apr 6, 2021, at 6:41 AM, Gabriel Zachmann via Cocoa-dev
> <cocoa-dev@lists.apple.com> wrote:
>
>
>> We don?t use NSUserDefaults in the app. Instead we have an
>> NSMutableDictionary that holds the settings, and we write them to a file
>> when they change. We read them in at app startup.
>> That allows us to actually have different settings for various items
>
> Yes, that certainly works.
>
> There is, however, a nice feature of NSUserDefaults that you will, I think,
> loose,
> or that you will have to implement yourself by hand:
> when the app runs for the first time, NSUserDefaults gets populated by the
> (real) defaults that come (more or less) hard-coded with your app.
> When a user changes one of those settings himself, then the system will know
> that this is an actual user setting.
> Now, if you later change the values of the (real) defaults that come with the
> app, maybe because the new default values are better,
> then those new defaults will take effect *except* for those settings that the
> user has changed himself.
>
>> (these are USB devices like mice and keyboards), and allows us to work
>> around the restrictions of NSUserDefaults.
>>
>> My only real issue with NSUserDefaults is that you cannot hand edit the
>> prefs file since the system will overwrite your changes with its own cached
>> data.
>
> But you can always change them using the 'defaults' command , can't you?
> ('defaults write' even takes a plist as argument.)
>
>
> Best regards, Gabriel
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/jackbrindle%40me.com
>
> This email sent to jackbrin...@me.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
