Mark Amery Mark Amery - 4 years ago 245
iOS Question

What does addChildViewController actually do?

I'm just dipping my feet for the first time into iOS development, and one of the first things I've had to do is implement a custom container view controller - lets call it

- that swaps out which of several possible child view controllers it shows, almost exactly like a standard
Tab Bar Controller
. (It's pretty much a
Tab Bar Controller
but with a hideable side menu instead of a tab bar.

As per the instructions in the Apple documentation, I call
whenever I add a child ViewController to my container. My code for swapping out the current child view controller being shown by the
looks like this:

- (void)showViewController:(UIViewController *)newViewController {
UIViewController* oldViewController = [self.childViewControllers

[oldViewController removeFromParentViewController];
[oldViewController.view removeFromSuperview];

newViewController.view.frame = CGRectMake(
0, 0, self.view.frame.size.width, self.view.frame.size.height
[self addChildViewController: newViewController];
[self.view addSubview: newViewController.view];

Then I started trying to figure out just what
does here, and I realised that I have no idea. Besides sticking the new
in the
array, it seems to have no effect on anything. Actions and outlets from the child controller's view to the child controller that I've set on the storyboard still work just fine even if I never call
, and I can't imagine what else it could affect.

Indeed, if I rewrite my code to not call
, and instead look like this...

- (void)showViewController:(UIViewController *)newViewController {

// Get the current child from a member variable of `SideBarViewController`
UIViewController* oldViewController = currentChildViewController;

[oldViewController.view removeFromSuperview];

newViewController.view.frame = CGRectMake(
0, 0, self.view.frame.size.width, self.view.frame.size.height
[self.view addSubview: newViewController.view];

currentChildViewController = newViewController;

... then my app still works perfectly, so far as I can tell!

The Apple documentation doesn't shed much light on what
does, or why we're supposed to call it. The entire extent of the relevant description of what the method does or why it should be used in its section in the
Class Reference
is, at present:

Adds the given view controller as a child.
This method is only intended to be called by an implementation of a custom container view controller. If you override this method, you must call super in your implementation.

There's also this paragraph earlier on the same page:

Your container view controller must associate a child view controller with itself before adding the child’s root view to the view hierarchy. This allows iOS to properly route events to child view controllers and the views those controllers manage. Likewise, after it removes a child’s root view from its view hierarchy, it should disconnect that child view controller from itself. To make or break these associations, your container calls specific methods defined by the base class. These methods are not intended to be called by clients of your container class; they are to be used only by your container’s implementation to provide the expected containment behavior.

Here are the essential methods you might need to call:





but it doesn't offer any clue as to what the 'events' or 'expected containment behavior' that it's talking about are, or why (or even when) calling these methods is 'essential'.

The examples of custom container view controllers in the "Custom Container View Controllers" section of the Apple documentation all call this method, so I assume that it serves some important purpose beyond just popping the child ViewController onto an array, but I can't figure out what that purpose is. What does this method do, and why should I call it?

Answer Source

I was wondering about this question too. I watched Session 102 of the WWDC 2011 videos and Mr. View Controller, Bruce D. Nilo, said this:

viewWillAppear:, viewDidAppear:, etc have nothing to do with addChildViewController:. All that addChildViewController: does is to say "This view controller is a child of that one" and it has nothing to do with view appearance. When they get called is associated with when views move in and out of the window hierarchy.

So it seems that the call to addChildViewController: does very little. The side effects of the call are the important part. They come from the parentViewController and childViewControllers relationships. Here are some of the side effects that I know:

  • Forwarding appearance methods to child view controllers
  • Forwarding rotation methods
  • (Possibly) forwarding memory warnings
  • Avoiding inconsistent VC hierarchies, especially in transitionFromViewController:toViewController:… where both VCs need to have the same parent
  • Allowing custom container view controllers to take part in State Preservation and Restoration
  • Taking part in the responder chain
  • Hooking up the navigationController, tabBarController, etc properties
Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download