Interface Builder is great for composing plain interfaces, where each view controller is represented by a single instance of view in a view hierarchy.
Embedded view controllers are different.
Even though you can create multiple Embed segues connecting different places in a storyboard to the same embedded view controller - during app initialization the framework will create as many instances of that controller as there are segues.
This is counter-intuitive at first. A collection of views is an ordered tree, where each node has a reference to its single parent. But in a storyboard the view controllers can be connected by Embed segues arbitrarily and can form cycles.
It appears Apple gets away with this by forcing each Embed segue to create a new instance of a destination view controller.
For example, the following storyboard with embedded view controllers (part of a project in a
coursera.org course) has many parent-child Embed relations:
Note the three parent Container views, and two of them share a view controller.
A parent view controller will have outlets to instances of child view controllers. Those outlets are declared weak and fished out of the storyboard in an override of prepareForSegue() method. If there are multiple instances of the same embedded view controller (as in the screenshot) - you’d want them stored in an array of weak references. But the challenge with Swift 2 is that it does not support collections of weak references.
In a simple case - having separate weak refs is ok. The prepareForSegue() implementation might look like this:
// MARK: - Navigation
override func prepareForSegue(segue: UIStoryboardSegue, sender: AnyObject?) {
// !!! Embed segues are processed before viewDidLoad().
switch segue.destinationViewController {
case let vc as MyHobbiesCollectionViewController:
// Note that this embedded VC has multiple instances,
// need additional id check (i.e. by segue.identifier).
switch segue.identifier {
case .Some("My1stHobbiesEmbedSegue"):
my1stHobbiesCVC = vc;
default:
my2ndHobbiesCVC = vc;
}
// Also prepare non-embed segues.
case let vc as EditHobbiesViewController:
break;
default: break;
}
}
In other more advanced cases, a recommended solution is to declare a weak ref in a structure and then have an array of those structures. Hopefully Apple is working to fix this minor annoyance.
A few words about how a hierarchy of view controllers should communicate with the rest of the tree.
KVO and NSNotificationCenter are ok in general case, but they lack type-safety of messages, and require not very nice symmetry of subscrbe/unsubscribe calls. Instead, I prefer declaring protocols for each child view controller, then a parent would implement those protocols, and assign itself to weak ref delegates of its children.
Events of the child controllers will first travel up a hierarchy, where a parent will route them to peers.
This messaging system could make use of a collection of weak ref delegates, which would be referred to as multi-cast delegates. But this will have to wait till a version of Swift that implements weak ref collections natively.
