I’m using PropertiesFile::getDefaultAppSettingsFile() to obtain the correct location for my application settings files. As your documentation states, it returns something like:~/Library/Preferences/[folderName]/[applicationName].[fileNameSuffix]
Now, reading Apple’s docs about submitting an application to the Mac App Store at http://developer.apple.com/devcenter/mac/documents/submitting.html#//apple_ref/doc/uid/TP40010572-CH16-SW9 I see:[quote]Your application may write to the following directories:
and indeed on my Mac OS X 10.6 the “Application Support” folder seems to be the usual choice for all the installed software, with very few exceptions. Could you please clarify this?
The Application Support folder was never really used very much, but does seem to be becoming more widely used - I think Apple have probably changed their advice at some point. In the past I think it tended to be more commonly used as a place where apps would put their resource files and larger items, while storing their prefs files in Preferences.
(On my machine I’ve got probably about the same number of things in both of those folders)
The tricky part for me is that if I change the path that the PropertiesFile class returns, then any app that uses it to open an existing prefs file will fail!
[quote=“jules”]The Application Support folder was never really used very much, but does seem to be becoming more widely used - I think Apple have probably changed their advice at some point. In the past I think it tended to be more commonly used as a place where apps would put their resource files and larger items, while storing their prefs files in Preferences.
(On my machine I’ve got probably about the same number of things in both of those folders)
The tricky part for me is that if I change the path that the PropertiesFile class returns, then any app that uses it to open an existing prefs file will fail![/quote]
Yeah, I think that’d need to be a compiler switch (though I dislike them in general for this kind of thing). Have the switch off by default but maybe have Introjucer set it on as those would be new projects.
I have modified my code and submitted the application again. Result: still rejected, this time because it writes in'~/Library/Caches/Juce/'
This seems to happen in class InterProcessLock::Pimpl of Juce. According to the rules of the Mac App Store, ‘Juce’ should be replaced with the name of the application.
Ironically enough, there’s a comment that says “don’t use getSpecialLocation() to avoid the temp folder being different for each app”…
Apparently I don’t love Steve Jobs enough to be allowed access to the link you posted earlier… Does it say anything else about file permissions? E.g. surely you’re allowed to use standard unixy things like “/var” or “/tmp” ?
I’m sorry Jules, I do not have my access parameters around now, I’ll let you know ASAP.
EDIT: I wonder if it actually would not be appropriate to define a symbol like ‘JUCE_MAC_STORE’ to manage all these problems in a coordinated fashion, as valley suggested. Even disabling, if necessary, features like the InterProcessLock.
Does these properties and settings APIs map neatly to all platforms, like Windows? How does that work? Is the registry involved? Is using an ApplicationProperties object more robust than just doing getSpecialFileLocation () and composing file paths myself?
I looked at the last changes in the tip and the solution for the preferences location is certainly valid, it builds on the existing code but it’s far more flexible.
As for the interprocess lock, I hope that the unixy way is acceptable to the Mac App Store, frankly I don’t know what to expect.
Will any of this stuff affect PropertiesFile locations for audio plugins? I mean, obviously the Juce changes will affect things, but are there some upcoming changes in Lion that will cause installers that put things in the previous locations to break?
For example, my plugins put some information in /Library/Preferences/MyPluginName.settings. The plugin generates this file when first instantiated, and writes user information in there during the authorization process. Is this kosher for Lion?
These changes have become necessary because of the policy of the Mac App Store. I do not think Lion will be just as strict and refuse to install software that was acceptable for Snow Leopard.
