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: Shawn Bakhtiar <email@hidden>
- Date: Thu, 30 Sep 2010 15:11:38 -0400
- Importance: Normal
Have you looked at the sample code for NSUserDefaults ?
I think this IS the place you want to put your info, even though you may not have realized it yet ;)
You can serialize any data that can take advantage of NSCoding? ie NSData, and save that as a key value pair.
Also, you should first look at the defaults command, to see how well some application have been able to serialize there configurations.
just type "defaults read" and you will see all the domains, application, etc... and how some of the configuration information is saved. Notice, how window coordinates, colors, etc... are saved.
I don't see why the serial number of the project/camera/etc.. could not be hashed into the key, so you can retrieve specific values; number of options could not be encoded in to say XML, that is than saved/loaded via the NSString and parsed using and XML interpreter for those specific values.
Hope this gives you some ideas,
> From: email@hidden
> Date: Thu, 30 Sep 2010 12:42:04 +0100
> To: email@hidden
> Subject: Should I use NSDocument, NSUserDefaults or something else
>
> Thankyou for peoples patience with my recent very basic conceptual cocoa questions. I have another where I am trying to understand the best way of handling some persistent data storage.
>
> My app is a workstation for a type of microscope, which from the point of view of the software consists of several different video cameras and some other devices controlled over USB. Each camera has associated settings (e.g. exposure) that I want to persist between app launches. I am not sure what the best way is of storing this information. There are multiple cameras involved, with each camera having quite a distinct role, so I would like to tie the settings to individual camera serial numbers.
>
> I had a look into NSUserDefaults but that doesn't sound quite ideal. As far as I can see (and I may be missing something) it is not inherently designed for hierarchical data storage. If I wanted to store, say, QI1438.exposure and PS1451.exposure as separate (flat) keys, then I don't think there would be a way of specifying a default value for the generalized key "exposure" in registerDefaults (regardless of the camera serial number). It could also be argued that these settings are not really "user preferences", particularly since one could imagine having a different bank of settings for different experiments.
>
> 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. Can anybody point me towards some example code that uses an NSDocument for this sort of application?
>
> Any advice people have on which of these solutions (or indeed a third one...) I should be using would be very welcome.
>
> Cheers
> Jonny_______________________________________________
>
> 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
_______________________________________________
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