I need some advice on the correct sandbox folders to use.
I see that the Application Support special folder is where I should place all data files etc. the convention that I use results in a folder called
user/Library/Application Support/progname
I have seen that some applications use the bundle id instead of progname above. Which is correct?
Also, writing output files to the documents folder. In my startup I create a folder within the user’s documents folder. This folder is the progname. If I understand sand boxing correctly this is not acceptable. I don’t ever directly save a file there and open a save dialog for the user but my default folder is the one I created.
Lastly, after writing a file to the user chosen folder following the save dialog I store the chosen folder and point to that in future saves. Is that acceptable?
Thanks all.
Simon.
The point is to have a unique name. Using the Reverse DNS name (which is usually what the bundle ID is) helps in this regard.
I don’t think using the Reverse DNS convention is mandatory, but it is recommended and preferred.
Your bundle ID, to my knowledge, doesn’t require to be in reverse DNS notation so what you see as progname might very well be a very inappropriate bundle ID.
I might be wrong in the above, I’ve been using the reverse DNS notation for over ten years now so at some point things might have become mandatory but not enforced.
If you are sandboxing, it pretty much doesn’t matter, as your app will get its own app support folder anyway.
I am not sure I understand you. Where would I create my new database on first run? Currently I create it in Application Support//.
I need some advice on what folder structure I need to refer to within my code.
Thanks.
Simon.
Once your app is sandboxed, SpecialFolder.ApplicationData points to ~/Library/Containers/bundleID/Data/Library/ApplicsationSupport
You need only to create whatever children you want at that location. Beware that is you assign SpecialFolder.ApplicationData to messageDlog.initialDirectory that this magic is broken and you get the usual folder even under sandboxing.
First of all, always start with the result of SpecialFolder.ApplicationData. Usually inside that, you create a folder for your company. And inside that company folder, you create a folder for your application.
Under sandboxing, the directory returned by SpecialFolder.ApplicationData is unique to your app’s group. Most sandboxed apps have their own group, but a special entitlement allows two (or more) sandboxed apps by the same developer to share a group, and thus share a container. Most developers do not write any special sandbox vs unrestricted code for this however. I was just pointing out that while sandboxed, making a company and/or app subdirectory is much less necessary, since the directory is unique to your app already.
Ok, so if I understand you guys correctly…
SpecialFolder.ApplicationData points to a different place before and after sandboxing.
That means I can develop without worrying about where the actual folder is. That is great, thank you all for your input.
Simon.
Bundle ID.
Yes that is correct.
Now obviously because I made App Wrapper Mini, I would recommend using it, but in this case I really recommend it. Once AWM is configured it runs every time you debug or build, thus making it much easier to develop an application for Sandboxing. You can also use App Wrapper as it also includes similar functions. This way, you can resolve Sandbox issues as you build the application, instead of building an application and then trying to resolve them. The same is said for working on Retina compatible applications too.
I have run into situations where apps get confused when there is a folder in the app container and the users library. It happens very occasionally, but it’s frustrating when it does. I think it’s an OS level issue, because I’ve also had it happen with Apple’s Xcode. For safety sake, I’d suggest making sure that there is only one “Application Support/com.developer.appName” folder.
If you don’t want to use a wrapping tool during development, then I would suggest that when you come to Sandbox your application, you use the ‘Migration’ options so that the regular App Support folder gets moved into the application container (AWM doesn’t yet support Migration while AW does).
Yes, this will work during that application life cycle.
However if you wish to have a Recent Items menu, then you’ll need to use NSDocumentController for maintaining a recent items menu, this will also automatically preserve access for any file within it. I’ve posted code for doing this, so check the forums.
If you want to automagically re-open files that the user had open last time, you need to do one of the following.
- Use the NSDocumentController for maintaining a recent items menu. Just to be aware, if the user resets the recent item menu, you’ll lose access to these files.
- Use Security-Scoped Bodgemarks for storing a reference to the file. I would actually advise against this, as SSB (for short) can lead to all kinds of issues, not to mention that every time you need to access anything from the folder item, you must wrap it in requestAccess & releaseAccess function. I have code available for this.
- Use the MBS plug-in and spend days adopting a document based structure so that you can take advantage of Lion’s persistence to automagically maintain open files and access. This is the best solution, but also the hardest to implement. While I have posted a working example (Photo Samurai uses this model), the changes that are needed in order for this to work, make it hard to adopt without starting again (which is why I’ve not released the code).
I hope that this bucket load of information helps in some way.
Sam, where do you put the data files and how do you access them from multiple computers? In windows you just have a shared folder with the data files in it, then supply the data path to the files in the program.
Thom, to expand on the short answer, there is no way to have a sandboxed network version of a program on a mac? That seems crazy. If you can’t then that of course rules out being in the mac store.
Network apps are fine. You asked about storing files in a shared public folder. That is not fine.
If you mean accessing files over a mounted volume like AFP or SMB, that works exactly like any other file. You’ll need the user to open the file using an OpenDialog, and use a security scoped bookmark to regain permission to it later.
Thom, thanks for the clarification.
Networking is fine, there are entitlements to allow your application operate as a client and/or server.
Technically it’s possible with a Temporary Entitlement allowing the application specific read and write access to a folder within /Users/Shared/. However I think you’ll have to do some Apple appeasement to be granted safe passage on the App Store, and this means it will only work on a per machine basis.
I would personally avoid a SSB over a network, you’re more likely to hit the access timeout - and then death will slowly prevail. Instead, stuff the URL in NSDocumentController or use Lion Persistence.
The reason why I hate SSBs is the time out, in one product the OS was releasing the access while we were still using the file, which not only resulted in corrupted data but if it happened too frequently it corrupts the application container, which then prevents your application from working.
Agreed on all points Sam. Personally, any time I see “Temporary Entitlement”, I read it as “Entitlement That Will Go Away In The Future”. To the best of my knowledge, Apple has not confirmed when or if the temporary entitlements will go away, but I’d be willing to bet they will be. They exist so existing apps can use them in the short time while exploring more “official” solutions. Developing any new features that rely on temporary entitlements is a bad idea.
The most frustrating thing I’ve seen with TE’s is that it’s down to the App Reviewer if your app can use them or not. I’ve got apps which contain TEs, but know of developers who’ve had to appeal and write essays to get the App Review team to allow his app to use it.
Apple are continuing to add new entitlements (I noticed there is now one to allow app creation, which should help Xojo and AW), but not all cases are covered yet.