views:

364

answers:

2

The root question is "how many UIViewControllers can you push on the navigation stack?"

Suppose I have an application that is basically a database for three entities where each can have a relationship with some other entity, and the relationship is shown on a UIViewController. Users can follow those relationships and each one brings up a new controller - If the entities are A, B and C and A->B->C->B->C->A then each kind of view is on the stack twice. I understand how to push and pop, how to push back to a particular controller, and I think rather than just extend the navigation stack indefinitely it might be best to reuse a view controller in the navigation stack.

To do this, every time I wanted a FirstEntityViewController I could scan the navigation stack to find an object where [self isKindOfClass:[FirstEntityViewController class]]; and then call methods designed to rejig that view for what I currently want to see - just refreshing the data in the same way you do when reusing a UITableViewCell.

This is fine except for the effect it might have on the NavigationController. If I use UINavigationController:popToViewController:animated: I think it is going to discard everything above the view I'm popping to, including the view which the user expects to find on tapping "Back" in the navigation bar. So user taps a relationship, taps back and goes "huh?"

If I remove the matching controller from the navigation stack and then pop it on to the top of the stack the back behavior remains OK as long as the user doesn't go back as far as the instance of FirstEntityViewController that was moved or else again navigation will seem inconsistent.

Is the right solution to remove the controller from the stack, and somehow hold a place in the stack so that when the reused controller is popped it can be replaced back where it came from? Should I maintain my own list of view kind and data display so that when popping I can replace the view below the view about to pop to, staying one step ahead of back navigation?

Or is that just getting too complicated? Is there no need to even worry about this situation because the OS reuses much of the view controllers in the same way as UITableViewCells are reused, and there is no real memory or performance impact in having a 50-deep navigation stack?

+1  A: 

ViewController instances remain in the UINavigationController's stack, but any view except for the top view may be unloaded at any time (the view controller is notified via the viewDidUnload message).

In other words, the views underneath the top view do not hang around and will eventually be unloaded in low-memory conditions, so there's no need for you to attempt to re-use your view controllers.

Darren
What happens to navigation when views are unloaded - link past the missing view and still allow Back or does Back cease to be an option?
Adam Eberbach
No. When it's time for the view to appear again it is re-loaded, via loadView and viewDidLoad messages. You can test this in the simulator by simulating a low memory condition.
Darren
A: 

Last I checked you can't push a viewcontroller that's already on a navcontroller stack back onto it again. You'll have to create a fresh viewcontroller and push it onto the stack and each back button will pop that one off the stack. The best you can do is make a cache of viewcontrollers and dole them out as-needed -- as long as they're popped off the navcontroller stack. But it probably won't buy you much by way of memory savings.

UITableViews are a bit different in that there's only a relatively small number of cells in view at any given time and as soon as the cell goes offscreen it's removed and returned back into the pool. If you can guarantee that the maxdepth of your chain is fixed, then you can pull a similar windowing scheme. If not, you may have to stick with going deep and be vigilant about releasing memory as soon as you can.

Ramin