This post is a follow-up to my earlier post about the life cycle of UIViewController. In this post, we’ll look at the logic behind UIView, another class that every iOS developer will inevitably subclass.
Another Simple Set Up
We’re using the same Interface Builder set up from last time, but with one addition. Scene B has a new UIView. We will be examining what methods are called on that view as the UINavigationController pushes and pops Scene B.
Controller A Pushes to Controller B
When Scene A triggers a ‘show’ segue, these overridden methods are called on Scene B’s view in the following order:
- addConstraint: (can happen multiple times)
- layoutSubviews (can happen multiple times)
In this list, indentation signifies that a method is called during the execution of another method. For example, layerClass is called from within initWithCoder:. The list is meant to give the overall impression of the order of the method calls, but some have been omitted for brevity. An example of one such method is isDescendantOfView:, which is called many times throughout the loading process.
For this transition, it’s worth noting when these calls are happening in the context of the parent UIViewController. Steps 1-5, which collectively represent the view’s initialization, happen inside the controller’s loadView method.
Controller B Pushes to Controller C
Similar to our last transition, Scene B now triggers a ‘show’ segue. The view’s overridden methods are called in the following order:
- didMoveToWindow (steps 4-5 happen multiple times)
I’m not sure why there are hit testing calls happening in the first few steps, but the rest of the calls are pretty straightforward.
Controller C Pops to Controller B
Now we’re coming back to Scene B from Scene C. We get the following calls:
There’s not much to see here. This is the simplest transition so far.
Controller B Pops to Controller A
We’re now done with Scene B, and all views inside of it. Popping it off of the UINavigationController stack gives us the following calls:
Again, this step is fairly simple. There’s a little extra complexity because the view is being removed from the hierarchy and deallocated.
See For Yourself
The code that I used to run this test is up on my github here. Feel free to try it yourself, and insert any other steps you would use in your own controllers.