Can multiple container scenes use a common view controller? - ios

Question

I've got four scenes in my storyboard. One scene is acting as the parent to all the others via container views. Everything is arranged like so:
If you squint, you'll notice that all four are subclassed from the same view controller. I did this so that I could connect each scene's elements to a single, common view controller and avoid subclassing UIViewController four times. The ProductDetailViewController implementation looks like this:
#implementation ProductDetailViewController {
// Scene 1
__weak IBOutlet UINavigationBar *_navigationBar;
// Scene 2
__weak IBOutlet UILabel *_productName;
// Scene 3
__weak IBOutlet UILabel *_typeNameLabel;
__weak IBOutlet UILabel *_categoryNameLabel;
__weak IBOutlet UIImageView *_richImage;
// Scene 4
__weak IBOutlet UIImageView *_productImageView;
}
The problem is that viewDidLoad fires four times (obviously) and things are showing up blank. When I step through the debugger, the product object I'm passing around is nil for three cycles and then initializes on the fourth. Maybe the view controllers are loading out of order?
In any case, is this setup even ok to do? I'm thinking there's got to be a better way to avoid a subclassed view controller for every storyboard scene.

Answer 1

Setting multiple .xibs to be the same class is common. Not wanting to subclass UIViewController four times is also common.
One problem is that by doing this with Child View Controllers embedded in a Parent View Container and all the same View Controller class, you are creating four instances of the class that are all different and when writing you can't assume anything about which one you are. No wonder the product object is getting lost.
This structure can be salvaged, and it has a lot to recommend it, but it will take some arrangement. A good way is for the parent-delegate to make all the decisions.
Give the class a delegate property, of its own kind, of course weak (weak because the child can't keep the parent alive). Throughout, this you can check to see if it's nil, because if it has a delegate it's a child, but if it has no delegate it's a parent. You usually don't need to know, though.
Use Segue Identifiers. In IB, give each of those embed segues an identifier. Then, in your View Controller class, implement prepareForSegue:sender: with the body
if ([segue.identifier isEqualToString:#"ProductNameIdentiferInStoryboard"]) {
/*...*/ }
else if ([segue.identifier isEqualToString:#"typeBarIdentiferInStoryboard"]) {
/*...*/ }
else if ([segue.identifier isEqualToString:#"productImageIdentifierInStoryboard"]) { /*...*/ }
Implement three properties, again of the same kind, each representing a childViewController,
#property ProductDetailViewController *productNameViewController;
#property ProductDetailViewController *productTypeBarViewController;
#property ProductDetailViewController *productImageBarViewController;`
In prepareForSegue from step 2, fill in with the pattern:
self.productNameViewController = segue.destinationViewController;
self.productNameViewController.delegate = self;
Note prepareForSeque:sender: fires before any viewDidLoad, so you have the references: do all the setup here from the parent's point of view. self.productNameViewController.titleLabel.text = #"Product Name"; The children will fire first, regardless sending a message to nil does nothing, so it's fine they play with their imaginary children. They have a delegate if they need to send information up or ask something important.
This may seem cumbersome, and the identifier stuff definitely is. However, the benefits of keeping centralized control in the code while working with spread out layouts in IB are obvious as a way to handle view controllers.

Answer 2

You definitely can have a single view controller class shared by these four scenes, but there will be four instances of that view controller class, not one.
Having said that, I would advise against this approach and I would suggest either:
Keep the storyboard layout you have, but use a unique view controller class for each child scene, each with its own unique IBOutlet references.
If you'd like the parent view controller to have access to data entered in the child view controllers, you can obviously have the child view controllers update the parent view controller (e.g., using delegate-protocol pattern). But I wouldn't personally expose the child's UIKit properties to the parent view controller (a view controller has no business accessing the UIKit objects of another controller's view), but rather pass back the model data.
If you don't want separate controllers, just don't put these child views in separate scenes. Your example does not appear to be a very compelling use of view controller containment, anyway. In my mind, those child scenes would have to have some reasonable degree of complexity to justify the use of a separate scene (and thus justify separate view controllers). If they're not that complicated, you'd just add subviews to the parent view controller, which is much easier, rather than using container views and the view controller containment that entails.