Standalone: Saving prefs

[Zax]

Why not store preferences as a comma-delimited text file?

How do you store comma-delimited data in a comma-delimited text file?
(I know, with annoying and confusing escape characters)

[stam]

While there isn’t any really right or really wrong answer (if it works, it works), it’s about the effort needed by the developer to maintain preferences.

CSV is OK if that works for you. But then you have to remeameber or look up the order of the fields in the CSV and say you wan to remove or add preferences: it gets messy, prone to error and requires much ore effort to maintain.

It’s therefore preferred by many to store in a key:value format, where you can directly access the parameter by name regardless of order etc.

LiveCode arrays are a natural contender for this and livecode has built in options for serialising arrays to save to a file - either with arrayEncode() and saving a binary file (much more difficult for users to tamper with) or for example by converting to JSON with arrayToJson() and saving as a normal text file.

Alternatively you could store as a YAML text file (more human-readable than JSON but no built-in methods for this) or even SQLite database (compact and fast).

Personally if I only have a handful of prefs to save I don’t bother with this, I just create text where each line is a name /value pair separated by a delimiter, which is fine if you have just 3-4 values to parse and maintain (kind of a poor-man’s YAML), for for larger numbers of preferences I usually go down the route of array<->JSON as it lets me modify prefs easily in a text editor if needed.

The question was however where to store the file, not how….

[Zax]

The question was however where to store the file, not how….

You're right.
Let's say the "how" is some kind of bonus.

To explain my choice, the advantage of using an array is that you can store all forms of data in it, and that they are directly usable by LC.
Before arrays were managed in LC, I used XML.

[stam]

To be honest, if you're going to use a binary format rather than text format, might as well just store as a stack - no reason why you couldn't just store all prefs in a stack in your chosen location and just 'start using' that stack to get/set preferences directly without the rigamarole of importing/exporting.

The main reason to use JSON or YAML files is that they're easily editable outside the IDE/standalone, since they're simple text files - the more I think of it, the less reason there is to use anything but a stack if you want to store as binary file. Well, in my mind anyway...

[jacque]

Just a heads up: I have a project that saves prefs in a stack. That works fine stored in the Preferences folder in Mac OS X Monterrey and earlier. But testers running Ventura got failures, the stack was not written to the Preferences folder at all. I also tried the Application Support folder with no results. Apparently there has been a change and app-related files must be stored in the app's container folder which is located in ~/Library/Containers/<app name>/ That was the only location that worked.

I do see other apps with prefs stored in Preferences. My only guess is that binary files might be forbidden there but I'm not sure. At any rate I'd be interested if anyone else running Ventura has the same results.

[stam]

Thanks for the heads-up Jacque.
Because I needed a simple solution for Windows deployment I’ve been using the user’s Documents folder - not had issues with that.

Wasn’t aware of the prefs issue on MacOS but weird that there is a dedicated folder for prefs you can’t use… sigh…

[jacque]

Yeah, it is weird. The Preferences folder has been there since the first Mac. I see some other apps that still use it without problems so I can only guess that it's either a new requirement for newly installed apps on Ventura, or else the type of file matters. Livecode doesn't use a container and it works on Ventura. We need more info.

[jacque]

I may have figured this out. I think if the app is sandboxed it can write only to its own container. My app is sandboxed apparently, though I'm not sure how it happened. My guess is that mrSignNotarizeHelper did it, I'll have to find out.