On 16 May 2018, at 08:55, Pascal Bourguignon <p...@informatimago.com> wrote:
>> Le 16 mai 2018 à 09:26, Rick Mann <rm...@latencyzero.com> 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 (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
