Understanding View Controller Nesting in iOS

Question

Ive been tearing my hair out over the last couple of days trying to understand this one seemingly basic concept of iOS development:

• If I want to have two or more View Controllers displayed and usable in the same "screenful", is this:

  1. Not advisable as per Apple's "One VC per screenful of content"
  2. Completely possible by adding the VC's via code
  3. Just not done. Instead, use one VC and simply add code that mimics the functionality of the view controllers you want.

Let me rephrase a bit:

If I wanted to have, in an iPad app, a UIView (A) that takes up a large portion of the left side of the screen, and a second UIView (B) that takes up the rest of the right side of the screen, and I wanted to add a button to UIView B that when clicked would use the Modal transition to slide up a UITableview to replace UIView B, and this UITableview would then act like a typical UITableviewController whereby when the user picks an item from the table, the typical events are sent to the tableview controller to push in a new set of items, is this possible?

It just seems to me that if Im already able to easily create two separate UIViewControllers, and have a button in one VC modally bring up the second VC, why cant I combine this functionality so that one VC has two children VCs, and those children VCs handle their own modal transitions.

Or is the best practice in a case like this to simply have one VC that handles everything, and then manually handle animating the slides in / out of various views after various clicks on various UI elements?

As you can tell, I think Ive read too many different, conflicting responses to questions similar to this that Ive gotten entirely confused about whats what anymore. If anyone out there understands what Im getting at and can lend a helping explanation or some pointers Id greatly appreciate it.

Answer 1

The answer depends on whether you need to support iOS 4 or not. If yes, the answer is:

Answer number 1 - With the exception of Apple's own container controllers, notably UITabBarController, UINavigationController, UISplitViewController, UIPageViewController and UIPopoverController (did I miss any?) there is no properly supported way to have multiple view controllers active on the same screen, managing different portions of the view. View controller methods such as presentModalViewController, etc all work on the assumption that there is a single "frontmost" view controller that owns the whole screen, and if you try to have multiple view controllers manage different parts of the view, all kinds of things will break, such as forwarding of screen rotation events and resizing/positioning of views after a page transition.

However if you only need to support iOS 5, the answer is:

Answer number 2 - No problem! Just make sure that all your sub-page-view controllers are correctly hooked up to a master view controller that manages the whole page. That means that in addition to the controllers' views being subviews of a common parent view, the controllers themselves should be child-controllers of a common parent controller. As long as the controller's parentViewController properties are all set correctly, you should be able to manage this kind of composite interface without too much hassle.

Unfortunately, Apple only added public setters for childViewControllers and parentViewControllers in iOS5. In iOS4 and earlier you're limited to Apple's own container controller arrangements and cannot create your own (at least, not without event forwarding issues).

So assuming you need to support iOS4 for now, answer number 3 seems like your best bet: Build your interface using multiple views but a single controller. This isn't too bad though. You can create custom view subclasses that manage heir own subviews (for example there's no rule that says a tableViewDataSource or delegate has to be a UIViewController subclass, or that a button IBAction has to be a method on a view controller instead of another view).

You'll actually find that most of the functionality you normally build into a view controller can be built into a "smart" container view instead, allowing you to split your screen into multiple standalone "controller-views" that manage their own contents.

The only bit that's tricky is doing stuff like transitions between one view and the next. For this you won't be able to use the standard presentModalViewController or pushViewController methods, you'll have to do the animations yourself using CATransitions or UIView animations.

Answer 2

This is definitively possible in IOS 4 :

You have a view controller "A" with its view :

• Alloc init the view controller "B" you want to had on your view controller "A"
• Call (void)addSubview:(UIView *)view on the view of the view controller "A" with the view of the view controller "B" as parameter
• The frame of the view of the view controller "B" is set to fullscreen because of addSubView, so change it to put the view where you want on the view of view controller "A".
• Add some UIView animations when you change the frame to have a good display.

On IOS5 just use the method on your view controller "A" :

• (void)addChildViewController:(UIViewController *)childController

Answer 3

The View Controller Programming Guide covers this pretty well.

A view controller manages a set of views. You can have content view controllers and container/navigation view controllers which manage the hierarchy of view controllers (example: navigation view controller can manage a listview controller and a detail controller).

It's covered in more detail here:

http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007457

A view controller manages a discrete portion of your application’s user interface. Upon request, it provides a view that can be displayed or interacted with. Often, this view is the root view for a more complex hierarchy of views — buttons, switches, and other user interface elements with existing implementations in iOS. The view controller acts as the central coordinating agent for this view hierarchy, handling exchanges between the views and any relevant controller or data objects.

Multiple view controllers coordinate their efforts to present a single unified user interface.