Ios – What does addChildViewController actually do

iosuicontainerviewuiviewcontroller

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 SideBarViewController – 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 addChildViewController whenever I add a child ViewController to my container. My code for swapping out the current child view controller being shown by the SideBarViewController looks like this:

- (void)showViewController:(UIViewController *)newViewController {
    UIViewController* oldViewController = [self.childViewControllers 
                                           objectAtIndex:0];
    
    [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 addChildViewController does here, and I realised that I have no idea. Besides sticking the new ViewController in the .childViewControllers 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 addChildViewController, and I can't imagine what else it could affect.

Indeed, if I rewrite my code to not call addChildViewController, 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 addChildViewController 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 UIViewController 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:

addChildViewController:
removeFromParentViewController
willMoveToParentViewController:
didMoveToParentViewController:

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?

Best Answer

I think an example is worth a thousand words.

I was working on a library app and wanted to show a nice notepad view that appears when the user wants to add a note.

enter image description here

After trying some solutions, I ended up inventing my own custom solution to show the notepad. So when I want to show the notepad, I create a new instance of NotepadViewController and add its root view as a subview to the main view. So far so good.

Then I noticed that the notepad image is partially hidden under the keyboard in landscape mode.

enter image description here

So I wanted to change the notepad image and shift it up. And to do so, I wrote the proper code in willAnimateRotationToInterfaceOrientation:duration: method, but when I ran the app nothing happened! And after debugging I noticed that none of UIViewController's rotation methods is actually called in NotepadViewController. Only those methods in the main view controller are being called.

To solve this, I needed to call all the methods from NotepadViewController manually when they're called in the main view controller. This will soon make things complicated and create an extra dependency between unrelated components in the app.

That was in the past, before the concept of child view controllers is introduced. But now, you only need to addChildViewController to the main view controller and everything will just work as expected without any more manual work.

Edit: There are two categories of events that are forwarded to child view controllers:

1- Appearance Methods:

- viewWillAppear:
- viewDidAppear:
- viewWillDisappear:
- viewDidDisappear:

2- Rotation Methods:

- willRotateToInterfaceOrientation:duration:
- willAnimateRotationToInterfaceOrientation:duration:
- didRotateFromInterfaceOrientation:

You can also control what event categories you want to be forwarded automatically by overriding shouldAutomaticallyForwardRotationMethods and shouldAutomaticallyForwardAppearanceMethods.

Related Solutions

Iphone – When to use addChildViewController vs pushViewController

Yes, pushViewController: is for navigation controllers that manage a stack of view controllers. addChildViewController: on the other hand is part of an iOS 5 feature called "view controller containment".

The basic idea behind this is that you can embed your view controllers into other view controllers of your own (e.g. when porting an iPhone app to the iPad) and thus easily do your own implementation of things like navigation controllers, split view controllers etc.

One problem with an implementation like the one you show is that you only handle views. View controller events like orientation changes will not be passed properly down the hierarchy. View controller containment tries to ensure that all contained view controllers will get the appropriate messages, too.

Looking at your implementation you should also think about what you really want to achieve by this. A navigation controller may be the right thing or you might even show the next controller modally (see https://developer.apple.com/library/content/featuredarticles/ViewControllerPGforiPhoneOS/PresentingaViewController.html) A bonus when using these methods (e.g. navigation controllers and modal views) is that the user is already familiar with those navigation techniques.

In any case https://developer.apple.com/library/content/featuredarticles/ViewControllerPGforiPhoneOS/ is a good read about how to transition between view controllers.

When using view controller containment you basically have to add the view to the containing view as usual (this has to be done even if the controller is added). Then you use addChildViewController: to add the child view controller to the surrounding one. You also have to notify the child controller by didMoveToParentViewController: that it has been put into another controller. You can also use transitionFromViewController:toViewController: to exchange one view controller for another, optionally giving an animation.

Ios – Animate change of view controllers without using navigation controller stack, subviews or modal controllers

EDIT: New answer that works in any orientation. The original answer only works when the interface is in portrait orientation. This is b/c view transition animations that replace a view w/ a different view must occur with views at least a level below the first view added to the window (e.g. window.rootViewController.view.anotherView).

I've implemented a simple container class I called TransitionController. You can find it at https://gist.github.com/1394947.

As an aside, I prefer the implementation in a separate class b/c it's easier to reuse. If you don't want that, you could simply implement the same logic directly in your app delegate eliminating the need for the TransitionController class. The logic you'd need would be the same however.

Use it as follows:

In your app delegate

// add a property for the TransitionController

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    MyViewController *vc = [[MyViewContoller alloc] init...];
    self.transitionController = [[TransitionController alloc] initWithViewController:vc];
    self.window.rootViewController = self.transitionController;
    [self.window makeKeyAndVisible];
    return YES;
}

To transition to a new view controller from any view controller

- (IBAction)flipToView
{
    anotherViewController *vc = [[AnotherViewController alloc] init...];
    MyAppDelegate *appDelegate = [UIApplication sharedApplication].delegate;
    [appDelegate.transitionController transitionToViewController:vc withOptions:UIViewAnimationOptionTransitionFlipFromRight];
}

EDIT: Original Answer below - only works for portait orientation

I made the following assumptions for this example:

You have a view controller assigned as the rootViewController of your window
When you switch to a new view you want to replace the current viewController with the viewController owning the new view. At any time, only the current viewController is alive (e.g. alloc'ed).

The code can be easily modified to work differently, the key point is the animated transition and the single view controller. Make sure you don't retain a view controller anywhere outside of assigning it to window.rootViewController.

Code to animate transition in app delegate

- (void)transitionToViewController:(UIViewController *)viewController
                    withTransition:(UIViewAnimationOptions)transition
{
    [UIView transitionFromView:self.window.rootViewController.view
                        toView:viewController.view
                      duration:0.65f
                       options:transition
                    completion:^(BOOL finished){
                        self.window.rootViewController = viewController;
                    }];
}

Example use in a view controller

- (IBAction)flipToNextView
{
    AnotherViewController *anotherVC = [[AnotherVC alloc] init...];
    MyAppDelegate *appDelegate = (MyAppDelegate *)[UIApplication sharedApplication].delegate;
    [appDelegate transitionToViewController:anotherVC
                             withTransition:UIViewAnimationOptionTransitionFlipFromRight];
}

Best Answer

Related Solutions

Iphone – When to use addChildViewController vs pushViewController

Ios – Animate change of view controllers without using navigation controller stack, subviews or modal controllers

Related Topic