Object Life Cycle: UIView


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:

  1. initWithCoder:
    1. layerClass
    2. setNeedsDisplay
    3. addConstraints:
      1. addConstraint: (can happen multiple times)
  2. willMoveToSuperview:
  3. invalidateIntrinsicContentSize
  4. didMoveToSuperview
  5. awakeFromNib
  6. willMoveToWindow:
  7. needsUpdateConstraints
  8. didMoveToWindow
  9. setNeedsLayout
  10. updateConstraints
    1. intrinsicContentSize
  11. layoutSubviews (can happen multiple times)
  12. drawRect:

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:

  1. convertPoint:fromView:
  2. hitTest:withEvent:
    1. pointInside:withEvent:
  3. convertPoint:fromView:
  4. willMoveToWindow:
  5. 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:

  1. willMoveToWindow:
  2. didMoveToWindow

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:

  1. willMoveToWindow:
  2. didMoveToWindow
  3. removeFromSuperview
    1. willMoveToSuperview:
    2. didMoveToSuperview
  4. dealloc

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.

4 thoughts on “Object Life Cycle: UIView

  1. I think that for the “Controller B Pushes to Controller C” step, the “hit testing calls” are called to detect if the user tapped inside the view or not, and the view could override that method to stop even bubbling.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s