Re: NSPersistentDocument Migration with Sandbox
Re: NSPersistentDocument Migration with Sandbox
- Subject: Re: NSPersistentDocument Migration with Sandbox
- From: Jim McGowan <email@hidden>
- Date: Thu, 16 May 2013 12:01:52 +0800
For the sake of the archives, here is how I solved this issue:
First off, I turned off automatic migration in my NSPersistentDocument subclass
I overrode -openDocumentWithContentsOfURL:display:completionHandler: in a subclass on NSDocumentController. In this method I check the UTI of the URL parameter and if it is a regular 'new' format document, go ahead and call super's implementation.
If the UTI is for the older document format, I begin migration to a temporary file inside the sandboxed temporary directory (from NSTemporaryDirectory()). I then open the migrated temporary doc without showing the UI (with -openDocumentWithContentsOfURL:tempURL display:NO completionHandler:…) and open a new blank doc with -openUntitledDocumentAndDisplay:error: Making use of the fact that my model classes already implement NSPasteboardWriting, I copy of the the contents of the temp doc into the new doc.
Then I show an alert in a sheet attached to the new doc window that explains to the user that the contents of the old doc have been upgraded, but the original file has not been altered. The sheet has a 'don't show this again' switch. The user can then save at their convenience.
Jim
On 11 May, 2013, at 10:40 AM, Jim McGowan <email@hidden> wrote:
> On 11 May, 2013 2:07:18 HKT, Quincey Morris <email@hidden> wrote:
>
>> On May 10, 2013, at 07:12 , Jerry Krinock <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden