Re: Temporarily disabling autosave
Re: Temporarily disabling autosave
- Subject: Re: Temporarily disabling autosave
- From: Mike Abdullah <email@hidden>
- Date: Sat, 20 Apr 2013 14:21:10 +0100
On 19 Apr 2013, at 21:42, Jerry Krinock <email@hidden> wrote:
>
> On 2013 Apr 19, at 12:37, Mike Abdullah <email@hidden> wrote:
>
>> Why, what's wrong with cancelling a [auto]save?
>
> That's a damned good question, Mike. You're probably thinking that, hey, we lived without any autosaves from 1984 to 2011. What's the big deal?
Nope, I'm thinking that the docs explicitly discuss bailing out of an implicitly cancellable autosave:
> For example, when periodic autosaving is being done only for crash protection, which doesn't need to be done all of the time, this method returns YES. When autosaving is being done because the document is being closed, this method returns NO.
>
> When this method returns YES your document-writing code can invoke unblockUserInteraction after recording the fact that changes to the document model made by the user should first cancel the rest of the writing. Your code that makes changes to the document model then must always do that cancellation first. If your writing code is implicitly cancelled in this way, it should set the NSError object passed by reference to the writing method to NSUserCancelledError in NSCocoaErrorDomain.
It just seems to me this system/flag exists for a reason and we should be using it rather than trying to hack an alternative.
> I have an app with a requirement similar to Steve's. The app can do long-winded sequences of operations that take tens of seconds, and change the document. So if I honored an autosave request during one these sequences, I'd have to interrupt the operations (which is tricky), save, and then save again at the end after the changes were done.
If you operations aren't suitable for interrupting, how about wrapping them in -performActivityWithSynchronousWaiting:… or -performAsynchronousFileAccessUsingBlock: so the document system doesn't interrupt you?
>
> The solution: Upon receiving a non-cancellable autosave message while other operations are in progress, I stash the completion handler that Cocoa sends in the message, create an operation to "really autosave" later, and add it to my operation queue.
>
> I had to do other stuff to deal with corner cases such as Revert, being in the Versions Browser, etc. Below, I've snipped out a few of the relevant methods from my NSDocument (actually it's NSPersistentDocument, which adds even more to the mess) implementation.
>
> Jerry
>
> - (void)autosaveWithImplicitCancellability:(BOOL)autosavingIsImplicitlyCancellable
> completionHandler:(void (^)(NSError *errorOrNil))completionHandler {
> if (autosavingIsImplicitlyCancellable) {
> // We can cancel this autosave if we want to.
> if (
> // If operations are currently in progress, cancel it. This is
> // because we will save when our operations are complete.
> ([[[self operationQueue] operations] count] != 0)
> ||
> // Prevent unnecessary saves, in case the document is in a watched folder
> // that triggers a syncing mechanism.
> (![self isDocumentEdited])
> ) {
> // Cancel it.
> completionHandler([NSError errorWithDomain:NSCocoaErrorDomain
> code:NSUserCancelledError
> userInfo:nil]) ;
> return ;
Since -autosave… is an async method, how about this pseudo-code:
Enqueue operation to run at a suitable time that:
Calls super's implementation
As far as the document system is concerned then, the autosave is simply taking quite some time to run, right?
I think the document system already serialises calling this methods, thus stopping another autosave kicking in midway. But if not, you would call -performAsynchronousFileAccessUsingBlock: as part of your implementation instead I believe.
_______________________________________________
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