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

Reply via email to