When NSDocument Asynchronous Saving is enabled, is there any point in the call to -unblockUserInteraction in a simple -dataOfType: error :?

I have a direct, Mac OS X, Cocoa, document-based application that uses the new APIs 10.7 Autosave, Versions and Asychronous Saving. I make full use of the NSDocument to get all the features of an Apple Document-based application for free.

To support the new Lion Autosave / Versions / AsyncSaving, I overridden the following methods in my NSDocument subclass, for example:

 @implementation MyDocument ... + (BOOL)autosavesInPlace { return YES; } - (BOOL)canAsynchronouslyWriteToURL:(NSURL *)URL ofType:(NSString *)type forSaveOperation:(NSSaveOperationType)op { return YES; } 

I also overridden -dataOfType:error: to help implement saving the document data to disk:

 - (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outErr { NSData *data = nil; if ([typeName isEqualToString:MY_SUPPORTED_TYPE_NAME]) { data = makeSnapshotCopyOfMyDocumentData(); // assume return value is autoreleased } else if (outErr) { *outErr = [NSError errorWithDomain:NSOSStatusErrorDomain code:unimpErr userInfo:nil]; } // not sure this is doing much good, since i take no action after this. [self unblockUserInteraction]; return data; } ... @end 

See what I call -unblockUserInteraction at the end?

With support for the new 10.7 feature, AsyncSaving Apple recommends calling -unblockUserInteraction as soon as possible (after creating a copy of your snapshot data) in your implementation -dataOfType:error: But Apple's example showed that they do a lot more work after calling -unblockUserInteraction .

However, given that after that I do not take any other action, I wonder if there is anything at all to call -unblockUserInteraction .

So my questions are:

  • Given that after that I take no other action, is my call to -unblockUserInteraction useful?

  • Is the Apple Framework just calling -unblockUserInteraction right after -dataOfType:error: returned anyway? Should I just leave them to them?

+4
source share
1 answer

I noticed only a subtle difference in the wording of the NSDocument documentation and the comment in NSDocument.h:

Docs:

If saveToURL: ofType: forSaveOperation: completeHandler: does not record the main stream, because canAsynchronouslyWriteToURL: ofType: forSaveOperation: returned YES, but it still blocks the main stream, this method blocks the main stream. Otherwise, he does nothing.

Title:

If -saveToURL: ofType: forSaveOperation: completionHandler: does not record the main stream, because -canAsynchronouslyWriteToURL: ofType: forSaveOperation: returns YES, but still blocks the main stream, unlocks the main stream. Otherwise, do nothing.

I guess the headline is more modern.

I am working on an application that calls unblockUserInteraction after the last line that should run in the main thread. (At least as I understood it)
I think our code matches the scenario that Apple had in mind when developing the async-saving part of NSDocument:

in fileWrapperOfType: we ...

  • create a QL preview for our file shell (which should run on the main thread) ...
  • unblockUserInteraction ...
  • ... "long" file save task (including compression)
+4
source

All Articles