I continued the conversation with Quincey Morris offline, but if anyone is curious or might be caught by this in the future...
The answer to this question does not involve a coding problem. As some probably understood, default application created by Xcode should automatically support the Resume functionality. What was blocking this from working was the System Preference: General -> Close windows when quitting an app This preference was selected and closed the windows of the app upon quitting which naturally means there is nothing to resume when the app relaunches. > On Mar 11, 2016, at 9:38 PM, Eric Gorr <mail...@ericgorr.net> wrote: > > There are still several key details I seem to be missing. > > I have a new commit > > https://github.com/ericgorr/last_saved/commit/ba462a19062fefde68f7e0f4459a0c8293332e9f > > <https://github.com/ericgorr/last_saved/commit/ba462a19062fefde68f7e0f4459a0c8293332e9f> > > which shows an attempt to implement some of this. > > I am using my AppDelegate as the restoration class. I have the following in > my AppDelegate class: > > static func restoreWindowWithIdentifier( identifier: String, state: > NSCoder, completionHandler: (NSWindow?, NSError?) -> Void ) > { > let storyboard = NSStoryboard( name: "Main", bundle: nil ) > let windowController = > storyboard.instantiateControllerWithIdentifier( "Document Window Controller" > ) as! NSWindowController > } > > Based on other information I found, I believe it is correct to use create my > storyboard…but, what else should go in here considering that I am using core > data to store the document data. > > One problem I have is that restoreWindowWithIdentifier is never called. Why > might this be? > > In the Document class I have: > > override func makeWindowControllers() > { > // > // Returns the Storyboard that contains your Document window. > // > let storyboard = NSStoryboard( name: "Main", bundle: nil ) > let windowController = > storyboard.instantiateControllerWithIdentifier( "Document Window Controller" > ) as! NSWindowController > let theWindow = windowController.window! > > theWindow.restorationClass = AppDelegate.self > theWindow.identifier = "last_saved_window" > > self.addWindowController( windowController ) > } > > to setup the window for restoration. Does this look correct? > > > > > > >> On Mar 11, 2016, at 2:14 AM, Quincey Morris >> <quinceymor...@rivergatesoftware.com >> <mailto:quinceymor...@rivergatesoftware.com>> wrote: >> >> On Mar 10, 2016, at 17:05 , Eric Gorr <mail...@ericgorr.net >> <mailto:mail...@ericgorr.net>> wrote: >>> >>> I have a Core Data Document Based OS X application written in swift and >>> using storyboards. Whenever I build and launch the app, instead of >>> automatically opening the last opened document(s), it will create a new >>> document. What I want to be able to do is have the application >>> automatically restore whatever documents were last opened on application >>> launch, if they are available. How can I do this? >> >> I believe there’s nothing special to ease this case (as opposed to >> NSDocument-based apps, which have state restoration support provided by >> NSDocumentController). You’ll have to do this manually: >> >> 1. Set a state restoration class on each restorable window. You might use >> the window controller class, or the app delegate class, depending on what’s >> convenient. >> >> 2. Implement the state restoration protocol in this class. This is basically >> a way of establishing a link between a restoration ID and a window that may >> or may not exist at the time this is invoked. >> >> 3. Save and restore custom state in a suitable place, either a subclass of >> NSWindow, or a subclass of NSWindowController: a NSResponder subclass that’s >> going to be in the responder chain. >> >> The trick to it is to remember that state restoration is a layer on top of >> normal NSWindow handling, so you’re in charge of (re)creating the windows >> when the app launches. Window controllers are not intrinsically involved in >> state restoration, but in most cases (I’d imagine) it’s going to be easiest >> to centralize the actual work in the window controller. >> >> There’s been another thread about this in the last week or so, where we went >> into this in a fair amount of detail. > _______________________________________________ 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
