macOS syncing plist

Hi guys and girls

I have a design question concerning synchronizing plists. My framework has a set a rules (you could call it preferences). The user may or may not change them (depending on the program that uses the framework). The application defaults are read from a plist from the mainbundle that uses the framework.

If the user is allowed to change them, I can register the defaults in NSUserDefaults in the "initialize" method of my class. In this case, synchronizing is dealt with by NSUserDefaults and the user can use any program to edit them.
The framework client then provides methods/GUI for editing the defaults.

But if the user is not allowed to edit, I should not expose the application defaults to the user and so there is no synchronization issue at all.

One way to combine both situations is to create a user plist in the application support directory and read this file if it exists or the plist in the mainbundle if not. But this creates a synchronization issue if the user is allowed to change the defaults. Changing the defaults do not have to occur in one central location, as is the case with preferences. What if one document changes the default? How do I tell the other documents? Reading the plist every time is one option, but this is probably inefficient.

Thanks for at least reading this far!

jared_kipe said:

I'm not 100% sure I understand, but I'll focus on just this bit. There isn't anything inefficient about reading a plist every time you open a document. You could store the contents of the plist into some ivars somewhere on launch if your plist is big or has a chance of moving during runtime.

Typically NSUserDefaults is used application wide, and should only store preferences that affect the global operation of the application. Meaning, that it shouldn't store anything document specific.

Documents should store their own preferences when that preference is only important to that document. It really shouldn't overlap or if it does, the NSUserPreferences should be used on every NEW document, and old ones store either the old preference or their own modified preference.

EXAMPLE:
Say you were writing an app that made bar graphs. A NSUserDefaults might be how many bars to use by default ( lets say 10). When creating a new document, the document will load that default and set up 10 bars.
If you modify that in the document, say setting up 15 bars, then you would save that in the document.

When loading that document, it would use its own 15 bars that you setup.
But new documents would still get 10 bars.

Click to expand...

It is not document specific, but application wide. NSUserDefaults are indeed a logical choice.
But suppose that the framework client decides how many bars are allowed, say 10 and that the user is not allowed to change that. Then using NSUserDefaults will expose that setting to the user. Maybe not within the program, but by editing directly the preferences file in the library folder.

jared_kipe said:

Then the programmer can ignore or override the preferences. Bottom line, the end user can always try to "hack" up a program, it's the programmers fault if the program blindly follows something like a preferences file without doing some checking to see if it is corrupted or has been tampered with.

Click to expand...

yes... and what is the best way for the framework to check the choice of the client program? I am not asking how the framework should behave, I am asking how best to implement it.

chown33 said:

The CFPreferences API has features that NSUserDefaults does not. AFAICT it can do everything the OP listed. It's not Objective-C, but it shouldn't be hard to put a suitable wrapper around it, or even to google for someone who has already done so.

http://developer.apple.com/mac/libr...e/CFPreferencesUtils/Reference/reference.html

Be sure to read the companion guide, "Preferences Programming Topics for Core Foundation".

Click to expand...

Thanks, I will read this.

jared_kipe said:

Why would the framework ask the client program what it should be doing. If the framework needs to look at a preference file, the framework should.

If the client program needs those preferences setup in a specific way, then it should write those preferences on launch or before the framework code runs.

OR the framework could take arguments. Either override the preferences file with those arguments OR if it doesn't get the arguments use the preference file version OR use some kind of default value.

Click to expand...

Well, I would prefer not use arguments of default values or have any communication with regard to this choice between client and framework. The framework should be smart enough to figure it out by itself. And if the client wants the user to change the preferences, then it should do this by providing the GUI to do so (the preferences can be communicated).

Yeah, I know, I am being difficult. I am trying to keep the code simple and lean, as well as the required actions on part of the client.
In any case, thanks for the suggestions! I will think them over.