Re: Implementing an import command in NSDocument-based app
Re: Implementing an import command in NSDocument-based app
- Subject: Re: Implementing an import command in NSDocument-based app
- From: Alastair Houghton <email@hidden>
- Date: Wed, 16 May 2018 10:32:44 +0100
On 16 May 2018, at 08:55, Pascal Bourguignon <email@hidden> wrote:
>> Le 16 mai 2018 à 09:26, Rick Mann <email@hidden> a écrit :
>>
>> I'm working on a little NSDocument-based app. The documents are packages (a
>> directory containing multiple files). One of the operations is to import a
>> music file into the document, which should copy the music file into the
>> package, and set it as the track for the document.
>>
>> Undoing this operation is somewhat complex (where do I store the previous
>> track if any?). So for now, I want to ignore undo.
The user’s temporary folder would be a good place to store the previous track
(you probably want to delete it when the program terminates).
> You have a choice, for « unsaved » documents:
> - either you keep them only in memory, or
> - you record them in a « untitled » file package, perhaps in /tmp.
I wouldn’t recommend /tmp. The trouble with /tmp is that it’s global, not
per-user, and so if you’re using that location you typically need to take steps
to make a per-user subdirectory in order to keep others from tampering with the
current user’s files; there are a lot of ways to get that wrong and end up with
a security hole.
However, you can use NSFileManager’s
-URLForDirectory:inDomain:appropriateForURL:create:error: method to obtain an
appropriate per-user temporary folder that you can use instead.
> I guess you see where I’m drifting to: it’s best to keep your document saved
> on disk all the time, even before it’s saved explicitely by the user.
Agreed.
> The bonus feature, is that if your application crashes, or the system is
> powered off, you can restore the unsaved document (if you don’t put it in
> /tmp, but eg. in ~/Documents/Unsaved\ Documents/).
But please don’t create your own subfolders in the user’s Documents folder. The
Documents folder belongs to the user — it isn’t yours to tinker with as you
please, and I know I’m not alone in feeling a visceral hatred when I see that
software has, without asking, created its own subfolders there. If you want
somewhere to store these, I’d suggest putting them in ~/Library/Application
Support/<your app>/Unsaved Documents (or similar) instead.
> Then you can copy the imported data to a file as soon as the import function
> is activated, so even if the imported file is deleted, the imported data will
> be there. And then you don’t have to implement in-memory data structure for
> unsaved documents, since by definition all documents are backed by files the
> same way (only a different path), whether they’re « saved » nor not « saved
> ». Much simplier. When you launch the application, scan the unsaved
> documents folder for unsaved document, and re-open them, to let the user
> choose whether to close (and delete them), or to save them.
If you’re going to open them automatically, it is a very good idea to prompt
the user first — i.e. let them know they have unsaved documents from a previous
session and offer to open them. Why? Because if the thing that caused your
application to terminate was a crash caused by some problem with the document
structure, then auto-opening will likely cause your application to crash again
— and that will be quite infuriating for the end user.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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