Storyboards and Document-based OSX Apps

Storyboards appear to be a very good way of laying out a UI. After playing around a bit with them I created a new Document-based OSX app that uses storyboards.

Everything came to a screeching halt, because I had trouble figuring out how the primary (or any other) view controller was supposed to get at the document. It took awhile but I finally found one answer. Below is what your view controller needs to do. Note that Apple doesn’t provide a stub viewWillAppear() in the ViewController it makes for you; this indicates to me that they intend for things to get wired up differently, but that’s just a guess.


class ViewController: NSViewController {
...

	override func viewWillAppear() {
		if let document = self.view.window!.windowController!.document {
			Swift.print("\(document)")
			representedObject = document
		}
		super.viewWillAppear()
	}
...

representedObject is MVC-compliant so once you’ve done this you should be able to start setting up bindings. I haven’t yet tried this. I’m converting the Recipes project that’s in the Core Data by Core Data by Marcus S. Zarra (first edition, out of print) to use Storyboards, and will post any difficulties and solutions I run into here.


Addendum, 12/30

In working how to glue the UI to the data, I found out an unfortunate truth — containment relationships do not invoke prepareForSegue(). This means you can’t use, for example, prepareForSegue() to set the representedObjects of the subviews of a split view using prepareForSeque(). Apparently prepareForSegue() is called for popovers, modal dialogs, and sheets.

Another thing I’m working through is that if I use CoreData in my storyboard document-based app, the NSArrayController that mediates between Core Data and the UI can’t be set to “Prepares Content”. I think that’s because the sequence of initialization makes this not work, but I’m still trying to figure out what the deal is.

Leave a Reply

Your email address will not be published. Required fields are marked *