Home/ Questions/Q 8610047
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T04:02:10+00:00

I’m working with some code that I need to refactor. A view controller is

  • 0

I’m working with some code that I need to refactor. A view controller is acting as a container for two other view controllers, and will swap between them, as shown in the code below.

This may not be the best design. Swapping the view controllers in this way might not be required. I understand that. However, as I work with this code I want to further understand what happens with the addChildViewController call. I haven’t been able to find the answer in Apple’s docs or in related questions, here (probably an indication that the design needs to change).

Specifically – how does the container view controller handle a situation where it is asked to add a child view controller, which it has already added? Does it recognise that it has already added that view controller object?

E.g. if the code below is inside a method – and that method is called twice…

[self addChildViewController:viewControllerB];
[self.view addSubview:viewControllerB.view];
[viewControllerB didMoveToParentViewController:self];

[viewControllerA willMoveToParentViewController:nil];
[viewControllerA.view removeFromSuperview];
[viewControllerA removeFromParentViewController];

Thanks,
Gavin

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In general, their guidelines for view controller “containment”, when one contains another, should be followed to determine whether you will need to implement containment.

    In particular, worrying about adding the same child view controller twice is like worrying about presenting the same view controller twice. If you’ve really thought things through, you shouldn’t need to face that problem. Your hunch is correct.

    I agree that Apple’s docs should be more up-front about what happens with weird parameters or when called out of sequence, but it may also be a case of not wanting to tie themselves to an error-correcting design that will cause trouble down the road. When you work out a design that doesn’t ever call these methods in the wrong way, you solve the problem correctly and make yourself independent of whatever error correction they may or may not have – even more important if you consider that, since it’s not documented, that error correction may work differently in the future, breaking your app.

    Going even a bit further, you’ll notice that Apple’s container view controllers can’t get in an invalid state (at least not easily with public API). With a UITabViewController, switching from one view controller to another is an atomic operation and the tab view controller at any point in time knows exactly what’s going on. The most it ever has to do is remove the active one and show the new one. The only time where it blows everything out of the water is when you tell it “you should blow everything out of the water and start using these view controllers instead”.

    Coding for anything else, like removing all views or all view controllers no matter what may in some cases seem expedient or robust, but it’s quite the opposite since in effect one end of your code doesn’t trust the other end of your code to keep its part of the deal. In any situation where that actually helps you, it means that you’ve let people add view controllers willy-nilly without the control that you should desire, and in that case, that’s the problem you should fix.

    • 0