On Jun 20, 2013, at 3:53 PM, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote:
> 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. Thanks, Quincey. It could take a long time to do the import, and the user will likely have to "pre-edit” the asset in some UI at least a bit first. In fact, I think that will almost always be the case, so the link-to-an-external asset approach may not be practical. Anyway, would that approach work with Sandbox restrictions? What about potential iCloud sync in the future (forgetting for a moment the issues of file size)? —Karl.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
