Application Suite Preferences
Application Suite Preferences
- Subject: Application Suite Preferences
- From: Seth Willits <email@hidden>
- Date: Sun, 26 Feb 2012 23:06:39 -0800
Does anyone have any practical experience with "suite" preferences? I'm finding the API lacking so much that it's almost useless, but I'm willing to give it the benefit of the doubt.
I've come across this a few times now where I want two applications to share some common preferences. In my current case, I have a full GUI app which displays controls to changes preferences, and both it and a background application should use those preferences. These common preferences can be factored out into the persistent "suite" domain. A change to a default in the suite should affect both applications in the suite immediately, so if a preference is changed in the full GUI app, the background app will immediately update its in-memory user defaults.
Now that's how it *should* work, but NSUserDefaults doesn't do this. It's lacking a few things.
1) What I really expect is a simple interface in NSUserDefaults to do setObject:forKey:inPersistentDomain:, but instead I have to do it myself by creating a new dictionary for setPersistentDomain:forName:. Not a huge deal, but certainly a nuisance.
2) Changing a persistent domain doesn't post any kind of notification for other applications to see. For other suite members to know the suite domain changed, they'd all have to manually post and listen for a custom distributed notification for every change. When that notification comes in, the receiving application needs to manually trigger all preference-using/watching objects to refresh and pull the new values out of the suite domain. Even if the suite domain is added to the NSUserDefaults object with addSuite:, changes to the domain (on disk) do not post a NSUserDefaultsDidChangeNotification so there's no automatic suite-friendly mechanism in place.
3) Another thing that's missing and would be nice is NSUserDefaultsController support for non-application domains. If I want to use a suite domain for instance, I can't use NSUserDefaultsController and instead have to create my own controller to bind to, or revert to using old-school target-action behavior.
4) When the on-disk defaults changes for a suite, calling persistentDomain:forName: yields the on-disk version, but if you do a objectForKey:, you'll get the old cached value. So you need to know to call -synchronize to have the latter work. You'll want to use the latter in order to use the values from registerDefaults: when needed, so there's a disconnect there as well.
Lastly, the documentation for both NSUserDefaults and CFPreferences is often sketchy, misleading, or vague. It could really use a thorough cleanup from a keen eye to add more precise comments on methods and usage.
For instance, NSUserDefaultsDidChangeNotification says "This notification is posted when a change is made to defaults in a persistent domain." What it doesn't tell you is that it's only for changes made to the domain by the same application. It also is not triggered by a call to -synchronize which loads new changes that are on the disk, which effectively changes the domain as well.
Another instance where the documentation is sketchy is setPersistentDomain:forName:. It says of the domainName parameter: "This value should be equal to your application's bundle identifier." This is simply false. It "should" not be anything. It "can" be your app's identifier, or another app's, or a suite domain identifier etc.
Anyway, I'm sort of rambling. I'm working on a solution so that suite defaults are automatically synchronized between running applications. I've got it working minus bindings, but in my case I don't need them so I think I'll just move on. At any rate, I'm interested in hearing the thoughts of anyone who really knows how these suite preferences should be used.
--
Seth Willits
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden