Re: What is the rationale behind keeping preferences in one place and "Application Support" files in another?
Re: What is the rationale behind keeping preferences in one place and "Application Support" files in another?
- Subject: Re: What is the rationale behind keeping preferences in one place and "Application Support" files in another?
- From: John Stiles <email@hidden>
- Date: Thu, 8 Dec 2005 10:34:06 -0800
On Dec 8, 2005, at 10:29 AM, Andy Armstrong wrote:
On 8 Dec 2005, at 18:22, John Stiles wrote:
I don't think those things are relevant to end users.
Remember, we're developers. We are all a special case.
I can't quite believe the arrogance of this. Are we not also end
users? There's a useful mechanism there and we're contemplating
breaking it not for any particular technical advantage but because
we've decided that it's not useful to mere mortals?
You misread my post, I think. Please reread it.
NSUserDefaults is good. I like it. Everyone should use it unless they
have a highly compelling reason not to. I never stated otherwise.
All I was trying to say is that NSUserDefaults' strongest point isn't
that it is compatible with the "defaults" command line tool. To most
users, that's totally irrelevant, since they don't even know how to
use the command line, and they certainly don't know the secret
preference settings of your app. (Do you even get "defaults" unless
you install the developer package? I don't remember.)
Reasons that NSUserDefaults is a good thing:
• Using the built-in API is a lot more robust than writing your own
• Using the built-in API is simple
• Using the built-in API will future-proof you when Apple changes
everything :)
• Many built-in Cocoa functions will generate a plist for your app
anyway, and having 2 separate prefs files is icky
• Property List Editor support
I could go on, but please understand—I'm not advocating a "do-it-
yourself" approach to prefs. _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden