I’m preparing to “appwrap” my first app for the Mac App Store. Everything else seems to be going fine except the container migration. My non-sandboxed app has a couple of .db files in ~/Library/Application Support/MyAppName that I’d like to be moved to the sandbox.
I’ve checked the “Move non-sandbox items into the App Sandbox” and specified ${ApplicationSupport}/MyAppName as migration path. But after launching the sandboxed app the files do not get moved. Am I missing something else here?
The migration only works when the container is first created. So if you delete the container and then try to run the Sandboxed version, it should then import the files.
Be warned that it will physically move the files into the container. So if you want to use the un-sandboxed version or test migration again, you’ll need to move the files back to their original location.
Another related question. How should I handle a situation where user has defined another path for my app’s database? Naturally the sandboxed app can’t access it. Ask the user to find the database using OpenDialog?
My recommendation is that you explain to the user that you’ve adopted Apple’s latest security mechanism and therefore they must re-select the old database (if it’s in a custom) location. You should then move the database to be within the Application Support folder.
Alternatively, if you allow multiple databases, then get a copy of the Sandbox Kit and use the OWRecentItems class to add it to the Recent Items menu.
Both of these methods will make your life so much easier than fighting the Sandbox. Do not consider using a Security-Scoped Bookmark as these are not compatible with the Xojo database frameworks.
My users must have the option to place the database outside the container. Can the app use the database outside of the container if user selects it once?
In order to keep the authorization to a non sandboxed area you probably need to use Security Scoped Bookmarks. It does not seem very simple, according to what one can read by searching " Security Scoped Bookmarks" in the forum.
Otherwise, you could simply save the database in your sandboxed area, and if the user needs to get the database file, offer an export option.
Oh, I thought that the app would have authorization to the file forever. But yeah, you are right.
I don’t know anything about those bookmarks, I guess I’ll have to do more research. I suspect it’s not very easy?
I need an easy way for users to use the same database with multiple computers, not necessarily at the same time. So many users have the database file in Dropbox. The export thing wouldn’t work in my case.
BTW @Sam Rowlands, the new beta works nicely and my original issue is resolved. Thanks!
[quote=172772:@Thomas White]I need an easy way for users to use the same database with multiple computers, not necessarily at the same time. So many users have the database file in Dropbox. The export thing wouldn’t work in my case.
[/quote]
You did not mention DropBox before. From what I read at the developer side of the DropBox site, it seems possible to build access right into your app : https://www.dropbox.com/developers
There are two ways to retain that authorization safely: #1 Use the OWRecentItems from the Sandbox Kit, it uses the OS APIs for creating and maintaining a recent items menu, and at which point the OS holds on the authorization for the files in that menu. #2 Use the OWWindowRestoration classes from the Sandbox Kit to get at Lion’s Resume functionality so that the file will auto re-open when the application is re-started (providing the user has the option set in the System Preferences).
Security-Scoped Bookmarks are not too difficult, however they have a list of situations in which they can fail (even upgrading from Mavericks to Yosemite can break them) and if you get it really wrong, it’ll break your application. I’ve posted a list of reasons as to why they can fail on this very forum. If you still pursue SSBs, I would of course recommend that you check out the OWBookmark class from the Sandbox Kit.
The Sandbox Kit is the same code that we use in our own applications.
In OS 10.7 ~ 10.8.3, you need to disable journaling as the PowerBox will not allow the SQLLiteDatabase to work correctly otherwise. Or you set the minimum OS to 10.8.4.
Due to file locking when accessing the database, having multiple machines access the same database file is not a recommend approach. The best solution would be to have a server application that does the file processing and the others connect to it.
I’m pleased to hear it, and I’m sorry that there was a bug in there before.
So I’m still thinking about what to do with my situation. My app is LSUIElement. It doesn’t have a menu so it doesn’t have Recent Items. It also looks like OS X doesn’t support Resume for apps using LSUIElement. So SSB seems to be my only option. But you say Xojo database framework is not compatible with them? What do you mean?
I would store the database in the Application Support folder.
I’m not 100% sure of the issues that arise from using a SQLDatabase with a Security-Scoped-Bodgemarks as I’ve never tried it, just seen several people on this forum who’ve run into these problems.
You must request and release access to the database anytime that you do anything read or write from the database.
Bear in mind that SSB will only let your application access that specific file, AFAIK the SQLDatabase uses journaling (creates a temporary file), however I recall (if you search for it) that there is a command to disable Journaling, but also be warned that this can easily lead to a database corruption.
[quote]Note: In the case of a SQLite journal file, beginning in 10.8.2, journal files, write-ahead logging files, and shared memory files are automatically added to the related items list if you open a SQLite database, so this step is unnecessary.
[/quote]
But is it automatic with Xojo’s SQLiteDatabase…