On May 24, 2014, at 6:44 AM, John Pannell wrote: > I’m working on a document-based app and making every effort to adopt the > behaviors of a modern app. This includes state restoration, described in the > current documentation at: > > https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/CoreAppDesign/CoreAppDesign.html#//apple_ref/doc/uid/TP40010543-CH3-SW14
This doc is better, although may not address your concerns entirely: https://developer.apple.com/library/mac/documentation/DataManagement/Conceptual/DocBasedAppProgrammingGuideForOSX/StandardBehaviors/StandardBehaviors.html#//apple_ref/doc/uid/TP40011179-CH5-SW8 I have restore/auto-save working, and it was a relatively painless process. You might be over-thinking it a little--document-based apps get restoration support automagically as long as windows are marked restorable. That's pretty much it. The standard load/save methods will be called when needed, and you don't need to conserve yourself with any other part of restoration unless you need to explicitly maintain state that is not part of the document proper (generally). As a suggestion, I would start with the built-in behavior before you start overriding things, so at least you are proceeding from a working state. > Despite my best efforts, I’m not having any success with any actual > “restoration”… I’ve never seen any evidence of the system attempting to call > the relevant overrides when launching my app, after leaving documents open > during a quit or log out. Here’s what I know: > > - document windows have a restoration identifier. You don't have to specify this, unless you specifically need to reference it in your own code. > - document windows are set to be restorable. Good. > - document windows are confirmed to have a restoration class of my custom > NSDocumenController subclass (made solely to catch the calling of > restoreWindowWithIdentifier:state:completionHandler:). If I don’t subclass, > they are confirmed to have a restoration class of NSDocumentController. Pointless. This is all done automatically. Remove the code as you could be getting in the way. > - I’ve adopted automatic termination by setting the correct Info.plist entry. Do you mean NSSupportsAutomaticTermination? That is related to restoration but tangential although won't effect restoration behavior so it doesn't matter at the moment. > What works: > > I can see encodeRestorableStateWithCoder: being called on my window and on > view subclasses that I want to restore state for. This will only happen when the API thinks it needs to, and not necessarily (or typically) when you quit your app. I ran across this issue and I don't think it is properly documented. I.e., if the API doesn't believe that you state has changed since the window was opened, it won't save the state. If you use autosave, it will save state when the document autosaves, but you can run into a timing issue where changes to state that are made just after an autosave won't save. So the rule of thumb is use is, if it is part of the document I either register undo or force the dirty state of the document so a save will be forced; for everything else I always send -invalidateRetsorableState to the window every time I make a state change. Lastly, although it may be obvious, the "restore windows" system setting must be turned on, or you have to use the option-quit method. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
