On 11 May, 2013 2:07:18 HKT, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote:
> On May 10, 2013, at 07:12 , Jerry Krinock <je...@ieee.org> wrote: > >> I think that it would help to have a higher-level understanding of the >> problem. How about this… >> >> You have a sandboxed app in which the user has somehow opened a document >> outside your sandbox (because the user navigated to it in an Open dialog?). >> […] Yes, all of a user's existing documents (from the old version on the app, in the old format) would be outside the sandbox. This is just a regular document based app, so users' documents could be anywhere on any volume. > In the case of Core Data, this means that a sandboxed app cannot use > automatic migration, but must migrate manually. This is what I'm beginning to suspect. > > It's not clear that interacting with the user must be confusing. You could > start with an alert that explains that the document format needs updating, > offering a Save button that leads to the Save dialog. Annoying, perhaps, but > not necessarily confusing. > > There are a couple of other approaches that might be preferable to you. The > question is how well (or if) they work with NSPersistentDocument: > > 1. Use post-Lion "autosave elsewhere" to migrate the Core Data store into a > new untitled document in a temporary location. This would defer the Save > dialog until the document window closes. This sounds like a promising approach. Deferring the save dialogue until close seems like the most intuitive UX. THis is what Pages does when you open an MS Word file. The new version of this app uses autosave in place, but it could be possible to change this during the migration... > > 2. Put your Core Data store inside a file package. Then do the migration > within the package. However, you likely wouldn't be able to use > NSPersistentDocument any more, since it doesn't sound like it supports > packages directly. > > 3. Migrate your Core Data store to a temporary file, then move the migrated > file back to the original location, replacing the pre-migration file. > Presumably, this is the same approach that NSDocument Save takes, but you'd > need to implement it yourself, since NSPersistentDocument doesn't (AFAIK) do > this. The replacement needs to be safely done (using the file system's > "exchange objects" API), otherwise a crash or failure during replacement > would effectively destroy the document. Thanks, Jim _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
