Re: Should I use NSDocument, NSUserDefaults or something else
Re: Should I use NSDocument, NSUserDefaults or something else
- Subject: Re: Should I use NSDocument, NSUserDefaults or something else
- From: Quincey Morris <email@hidden>
- Date: Thu, 30 Sep 2010 13:24:38 -0700
On Sep 30, 2010, at 04:42, Jonny Taylor wrote:
> This made me think that an NSDocument might be a more appropriate solution (different document for each experiment, storing a hierarchical dictionary of key/value pairs but implementing my own handling of defaults for missing keys, etc). However this class is understandably a very complex class and I'm finding it hard to drill down to the details of what I would need to do in order to implement this pretty basic functionality - particularly since in some ways it would be a non-standard use of the class, in that the "document" was not associated with one single window, etc.
You have some design work to do before you can choose an implementation. The issue is not so much whether to use NSDocument or not, but rather what functionality and user experience you want your application to have.
There are probably 3 basic approaches here. The boundaries between the different approaches are not clear cut, but it might help you to think in these terms.
1. Settings. You'd remember the current hardware settings for your devices, and restore them whenever starting the application. There's absolutely no reason why you couldn't use NSUserDefaults for this. It *is* inherently designed for "hierarchical data storage", because you can put dictionaries into user defaults, and dictionaries are nothing if not hierarchical.
2. Configurations. You'd have all of #1, plus the ability to swap named sets of settings in and out of the current settings. You'd need to add an interface to manage the settings (name, activate, delete, etc). This could also live in user defaults. Alternatively, your settings could be in a file (or set of files) in the Application Support folder. The difference is that the Preferences folder is not really intended as something that users should go into, but Application Support can be. So, if you wanted users to be able to move configurations from one Mac to another, files in Application Support may be a slightly better choice.
3. Documents. This is similar to #3, except that the document files are placed wherever the user chooses. That makes it easy for the user to "own" the files, without having to hunt for them if it's necessary to move them to a different Mac, or to organize them into subfolders, or to back them up. The consequence of this choice is that the Mac OS document metaphor applies -- users will need to save documents explicitly, unlike #2 where the settings get "saved" automatically.
Depending on your user requirements, the document metaphor may or may not be appropriate. If not, but you still want to ease the transfer of settings between Macs, you can use something like:
3a. Configurations with export. You'd add to #2 the ability to export settings files (which could be a completely separate format, possibly even text files), and the ability to import settings files.
HTH
_______________________________________________
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