Re: NSUserDefaults from within a bundle
Re: NSUserDefaults from within a bundle
- Subject: Re: NSUserDefaults from within a bundle
- From: Bill Bumgarner <email@hidden>
- Date: Sun, 2 Jul 2006 10:03:06 -0700
On Jul 2, 2006, at 9:17 AM, Benjamin Einstein wrote:
It seems storing user preferences in an application's bundle is a
scary concept to most, if it's even possible. We have an application
that's stored on the network, is copied from the server to the local
machine via another application, and then launched by that
application. The application can also be used offline. We would
really prefer to have global, "traveling" preferences that are
embedded in the application bundle but can be modified locally
(don't worry about rights, you must be a system admin and an
application admin to make preferences changes). Is there a way to
use NSUserDefaults to do this? Maybe CFPreferences? I can read a pre-
compiled plist in the bundle using NSBundle, but I have no idea how
to write and load specific key values. Any ideas?
There's one major catch: the application would have to be copied
back when the user quits so other users get their updated
preferences. Hmmmm. It would be okay unless the write failed.
Writing to the app wrapper isn't a scary concept. It is flat out
wrong behavior for many reasons; security, system maintenance, etc...
I would assume your "master application" has some automated mechanism
for copying around the embedded application? Why not carry a plist
along with that application? Store it in ~/Library/Application
Support/YourApplication/.
There isn't anything particularly special about user defaults beyond
the ability to persist defaults in a standard location. The actual
data is managed through a property list; NSDictionary, NSArray,
etc... You could easily create a "settings controller" class that
has an API similar to NSUserDefaults and persists to ~/Library/
Application Support/YourApplication/.
b.bum
_______________________________________________
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