On Jun 20, 2013, at 12:06 , Karl Moskowski <kmoskow...@me.com> wrote:
> I’m creating a document-based OS X app. The document itself will be a > package, with most of the its properties archived in a plist (via > NSFileWrapper). However, the document package will also contain a potentially > — probably, even — large asset file that’s too big to keep in memory. The > first step of the new document workflow is that the user chooses the asset to > import. It’s then displayed for editing. > > My problem arises in the creation phase. After the new NSDocument object is > instantiated (in either -init or -initWithType:error:), but before the > document is saved, I don’t have an on-disk location to which to import, as > far as I can tell; all of the URL-ish properties and methods of NSDocument > are nil. It’s a modern app, with the various autosave methods returning YES, > and when the app quits, the new document is in "~/Library/Autosave > Information”. Consider what happens later, when an existing document needs to be re-saved. Since, in general, your save method must handle the case where the save is to a different location (Save As, for example), you need a mechanism to clone the large file. (You could hard link it when possible, but there'll always be situations where you have to copy it -- saving to a network volume, for example.) With a little care, you should be able to use the same code for new documents. Import the asset into a temp file. At save time, you'd notice that the asset file isn't in the save destination, so you'd clone it. There are other approaches, but this one fits most neatly in the NSDocument architecture, if it suits your use case. > Should I be taking the approach of Xcode, where the “New > Project” process > asks the user to choose a location for the project, and it’s saved > immediately? Or is there a property or method I’m missing that gives the > autosaved new document’s location? I think this is a different issue. It's mostly about whether it makes sense for the user to have an untitled-document experience for your app. If the import takes a long time, you can do it *before* creating the NSDocument instance, or *after* the document creation process is complete (that is, after makeWindowControllers is called). That's because you want a long import to have UI (progress/cancel), and the middle of a NSDocument 'init…' is not the place to do that. If you choose "before", then it's probably easier to have the user choose the save location before, too. If you choose "after", then it's probably better to maintain the untitled document experience for the user (if you want one). I've found from experience, though, that the implementation of both approaches amounts to much the same code, just in different places. From an implementation perspective, neither is preferable to the other. _______________________________________________ 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
