I’d like to use multiple preference files in my AS app. I’m already using the ‘defaults’ command to read and write basic prefs. However, I’d like to read and write the same way to a multiple sets of prefs.
Why? The application I’m writing has multiple functionality and writing all of those prefs into a single .plist would make it very lengthy and perhaps unwieldy. I’d rather divde out each function into it’s own .plist. I also would like to use only the functions built into AS so others wouldn’t have to install additional applications to get this app to work on their machines.
I realize I can simply read/write to a file but I like the ease of using the .plist. Is there any way to address multiple .plists?
Perhaps you could keep the various files as “prefs-x.plist”, “prefs-y.plist”, then rename them when needed before calling user defaults from within your Studio app (as “myStudioAppName.plist” or “com.myDomainName.myStudioAppName.plist”)…
You may find that using /usr/bin/defaults for the plists that don’t match your application’s bundle ID* is easier and less kludgy than changing a plist value, synchronizing user defaults, moving the file, writing a new defaults value, and then repeating the process. Syntax example:
Note that you can’t actually read the plist file before using /usr/bin/plutil to convert it to XML, but that isn’t necessary when you want to read the values with /usr/bin/defaults:
If you want to nest values inside a defaults dictionary (an array of keyed values, essentially), this is the syntax:
That results in a defaults domain that looks like this:
Reading that data back in:
* Apple recommends that you do not use /usr/bin/defaults to alter defaults values when the domain’s parent application is running. This would be the plist file that matches the bundle ID of the application. For example, if you had an application whose bundle ID were “net.mikey-san.sandbox”, it would be bad form to use /usr/bin/defaults to alter the values within ~/Library/Preferences/net.mikey-san.sandbox.plist; instead, we want to use the application environment’s built-in defaults registration system. (Using AppleScript’s user-defaults system, or the methods in NSUserDefaultsController.)
When we want to alter or read from the arbitrarily named, non-registered ~/Library/Preferences/net.mikey-san.sandbox.extrastuff.plist, /usr/bin/defaults will provide a quick and clean way to do that, and that’s okay because that file isn’t technically “in use” by anything.
In other words, it’s okay to modify the arbitrary, non-registered defaults files directly (the ones not created automatically for the application that match the bundle ID), but not for the one attached specifically to the application’s bundle ID.