What does the "Back" button in the UINavigationBar in iOS do to a view?

Question

When clicking the "Back" button in the UINavigationBar (on the left hand side), I am wondering that, what happens to the view, it will go back to?

Is it "reloaded" or is it "re-initialized"?

I am asking this because I notice when hitting the "Back" button the view frame gets cut off (I can't scroll all the way to the bottom).

But when I go to another view via the TabBar and return to that view, it doesn't.

I am also using storyboard and the issue is only happening for 3.5 inch devices.

Answer 1

If you refer to WWDC 2013 video Custom Transitions Using View Controllers it walks you through the process at a high level. Clearly, they're doing this as part of a discussion of how you can customize these transitions in iOS 7, but it provides some interesting background.

In short, during a pop, the previous view controller's view will not be reloaded (e.g. you won't see viewDidLoad called), as it was already loaded when it was first presented. (There is a situation in iOS versions prior to 6.0 where it could have been unloaded due to memory pressure, but we probably don't need to go into that here). The view is not "reinitialized" either. The view was simply removed from the view hierarchy when you pushed away from it, but it is retained by the view controller, so when you pop back, it's just added back into the view hierarchy.

So, upon a pop, it adds the previous view controller's view back into the view hierarchy (viewWillAppear and various layout-related methods for the view we're popping to; viewWillDisappear for the view we're popping from), performs the desired animation, and completes the transition by removing the popped view (viewDidDisappear for view we popped from, viewDidAppear for view we're popping to) from the the view hierarchy, and then removes the popped view controller from the view controller hierarchy.

Rather than worrying about which methods might theoretically be called, it's probably better to empirically validate this by adding breakpoints or NSLog statements in your relevant methods, and you'll see which is called when. If you're having problems, edit your question to include the code for all of your view appearance/layout related methods you implemented, and we can take a look at that.

To diagnose what's going on in your case, I'd also suggest you run your app in the simulator, do what you need to do to get the screen in its undesirable state, hit the "pause" button () in the debugger, and then at the (lldb) prompt, type

po [[UIWindow keyWindow] recursiveDescription]

That will provide a list of all of the views currently within the view hierarchy and their frames. If you're using auto layout, you can also enter the following at the (lldb) prompt:

po [[UIWindow keyWindow] _autolayoutTrace]

That will show you all of the auto layout constraints that are in place (and whether there are any problems with them).

You'll have to do some of this diagnostic work and then show us some screen snapshots, tell us whether you're using auto layout or not, share relevant code samples (notably if you're adding any of the views programmatically or changing any frames or constraints programmatically), if using auto layout, describe what constraints you've set up, if you're not using auto layout, describe what autosizing masks (e.g. what springs-and-struts) you have in place, etc.

To me, it sounds a bit like ambiguous constraints in auto layout, but we won't know until you dig in a little and then share your findings with us.

Answer 2

add something like NSLog(@"%s", __PRETTY_FUNCTION__) to all methods like viewDid/viewWill and see call chain that happens while navigation, is should help you understand what going wrong

Answer 3

If you're using bog-standard view controllers, then touching Back simply pops the top view controller off the navigation stack. The previous view controller is still resident in memory. That allows the application to be speedy and responsive.