On 19 Apr 2013, at 21:42, Jerry Krinock <je...@ieee.org> wrote:
>
> On 2013 Apr 19, at 12:37, Mike Abdullah <cocoa...@mikeabdullah.net> 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 (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
