Recording user's preferences - what is best approach

We prefer an encrypted SQLite database because it keeps the users from manually editing the preferences and it can be moved and used across operating system platforms.

[quote=15912:@Sam Rowlands]Thinking about it, I would actually suggest that you use each platforms preferred preference mechanism. This would reduce the likelihood of a new version breaking your application.

For instance Apple advise against reading & writing files directly the Preferences Folder, instead they recommend usage of NSUserDefaults to store preference values. Document Data should be stored however suits you, but it should be in a location of the users choosing.

I’m not sure what Windows uses at the moment, back in early naughties, there seemed to be a push to move to XML files in a special location, but most people were still using the Windows Registry for storing preference values.[/quote]

I’ve been using SpecialFolder.ApplicationData for user prefs for quite some time, but this thread prompted me to think “Wouldn’t it make more sense to use SpecialFolder.Preferences?”. Then after reading your comment that Apple advises against reading and writing to the Preferences folder (which seems odd, but whatever) I’m now wondering if I might end up with permissions problems under Lion if I change to SpecialFolder.Preferences. I’ve no idea how to use NSUserDefaults from within Xojo and very little desire to learn at this moment…

I’m not sure about Lion/Mountain Lion, but you will definitely be rejected from the Mac App Store if you use SpecialFolder.Preferences.

Thanks, Paul. My app will never be on the App Store but I don’t want users to have permissions problems. I’ll stay with ApplicationData I guess.

Paul wrote:

Really? What in the world is the Preferences folder for if not for reading/writing preferences? What’s the alternative?

It’s appears to be a pass over from the classic system. While NSUserDefaults currently reads and writes plist files in the preferences folder, Apple have warned that it may change in the future and if you’re manually accessing files in that folder your application may break.

However I didn’t know that they were rejecting apps because of it.

I guess the Application Support folder like Julia is using is a good alternative if you don’t use NSUserDefaults or CFPreferences.

What about creating a STUB from user defined preferences (pseudo compiling method).

Pseudo compiler

Because Apple wants to ensure that you read/write prefs in the standard way so that OTHER processes/programs can read/write them as well. Which actually happens and is officially supported.

An example of this is RS’s own Remote Debugger Stub for OS X: That one writes its prefs file on its own, violating two rules:

  1. It doesn’t use the proper file name.
  2. It reads and writes the data itself, expecting a xml formatted text file.
    It’s lucky that it violates both at the same time, though. If it would use the correct name, it would really run into trouble when the OS decides to convert the file format from XML text to the binary plist format - in that case, the Stub would not be able to understand the contents any more, doing its own parsing.

The correct way is to use OS X’s API for reading and setting preferences, i.e. either the CF… functions or the NSUserDefaults class (or both, you may mix them).

Anyone doing serious OS X apps should know about the “MacOSLib”, which contains code for this, including my very own “TTsSmartPreferences” which make using the OS X prefs API very easy, similar to what the JSONItem does.

Also: The Prefs folder is, like many other folders inside Library, organized by Apple, not by the user. Apps are not supposed to go wild inside them. The only ones an App may write to are their specific one in “Application Support”. Anything else is off-limits, including the Applications folder or even the own app bundle.

I wouldn’t be surprised if Apple decides to change where the user defaults system writes its data in the future. Basically for all of the reasons that Thomas mentioned.

“roll-your-own” pref file :slight_smile: safer option in the long run IMO

Everything “Apple” has always been and will always continue to be “Over complicated”.

  1. what about an xml file ?

  2. There are two Library folders in an OS X boot hard disk.
    one for all users, the second user specific (say in the folder, but its invisible bit is set to true).

All this looks strange to me. It seems that Apple is trying to tell us something but without announcing a major change, yet (it may comes in 10.9 or 10.10 or ?).

Apple’s always recommended the use of CFPreferences/NSUserDefaults for storing preferences on OS X. This isn’t a change.

[quote=15847:@Dave S]and why can’t I edit a post?

http://www.rdS.com/classini_file.rbo[/quote]

I use this
pref_save

pref_clear pref_add "Font",Window1.TextArea1.TextFont pref_add "Size",Window1.TextArea1.TextSize pref_add "Top",Window1.Top pref_add "Left",Window1.Left pref_add "Width",Window1.Width pref_add "Height",Window1.Height if not pref_write then msgbox "Could not write Prefs!"

pref_load

if pref_read then Window1.TextArea1.TextFont=pref_get("Font") Window1.TextArea1.TextSize=pref_get("Size") Window1.Top=pref_get("Top") Window1.Left=pref_get("Left") Window1.Width=pref_get("Width") Window1.Height=pref_get("Height") else msgbox "No Prefs found!" end if

Window1.TextArea1.TextSize is not working, I don’t know why

Apple don’t allow your App’s to read/write directly to the SpecialFolder.Preferences as a security measure. Malicious code could write to the pref’s file of any app and wreak havoc. That makes sense really. You have access to your SpecialFolder.ApplicationSupport folder as only Your app can access it and so Apple allow you to do as you please in there.

If you wan to use SpecialFolder.Preferences to read/write to your plist file don’t access it direct, use NSUserDefaults/CFPreferences. This allows your app access only to YOUR plist file therefore security against malicious code as mentioned above.

Just because Xojo has SpecialFolder.Preferences built in doesn’t mean Apple will accept it’s use. If we had SpecialFolder.Root would you expect this to be fully read write and accepted by Apple.

Emile, by use of NSUserDefaults, if Apple did change anything, your code wouldn’t break, Simply using NSUserDefaullts would read/write to Apples newly defined location.

[quote=16293:@Lee Page]“roll-your-own” pref file :slight_smile: safer option in the long run IMO

Everything “Apple” has always been and will always continue to be “Over complicated”.[/quote]

Not particularly safer, saves you using NSUserDefaults/CFPreferences. You will be limited to SpecialFolder.ApplicationSupport if you want to get your App past apple.

Yes and for very good reasons.