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: j.m.tay...@durham.ac.uk
> Date: Thu, 30 Sep 2010 12:42:04 +0100
> To: cocoa-dev@lists.apple.com
> 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 (Cocoa-dev@lists.apple.com)
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/shashaness%40hotmail.com
> 
> This email sent to shashan...@hotmail.com
                                          
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to