Style question: do you set your nav controller for all the child view controllers, even if they're not the top level view that is on the nav stack?

Let's say you have a tab view controller on the navigation controller view stack. (For the sake of argument.) Your tab controller has an array of view controllers for each of its tab views. Your tab controller's navigationController is clearly set to the nav controller (since its view is on the stack.)

But would you set the navigationController for each of your tab views to point to the nav controller? Their views aren't actually on the nav stack (they are subviews to the tab view that is), but it's necessary for them to be able to push a view onto said stack. Is it a bad idea? Should I do this but use a different instance variable?

Or would you just maintain pointers from all the subviews to their parent view controllers all the way up to the navigation controller? That seems clumsy and not that great if you have to go more than one level deep (which I do.)

(I'm not precisely doing this, I have a complex view with dedicated controllers for its subviews, so this is an accessible analogy.)

I find I am more successful when I keep separate navigation controllers for each tab. Then they can operate independently, and keep state when the user switches across tabs. Then there is no confusion about which view controllers are on the stack are below, or visible at a given point in time.

As for keeping pointers among the views and controllers, do not confuse the view hierarchy with the view controller stack, they are only orthogonally related as far as your view controller stack is concerned. There is a natural "ownership" of views by their view controllers, and you shouldn't have to be manipulating those pointers yourself, that should fall out naturally from the loading and creating of views, and view controller stack management API calls.

I agree about the first point, I would use separate navigation controllers for each tab. But what about if you had a complex view where half of it would flip over (to another view with a dedicated view controller)? It clearly falls under the same navigation bar and might need to push views onto the navigation controller.As for your second point, that sounds like I should be going up the view hierarchy by getting the superview's superview's controller's navigation bar?

zekel 2010-08-10 17:12:40

On the first point, I also have done some work where a complex view flips to reveal another complex view. But in that case, I still maintain it with the same view controller, and manipulate the `subviews` array of a parent `UIView` instead of trying to control all view manipulation with push/pop view controller operations. If you limit your thinking to strict pairs of controllers/views, you will limit your animation type, and won't be able to do flips with that method. Not to say this is the only way, it is a pattern that's been working for me.

jbm 2010-08-10 23:33:29

As far as the navigation bar is concerned, it depends on what you want to do with it. Each view controller has its `navigationItem` and `title`, and the navigation controller uses its rules to determine how those are manipulated as your view controllers are pushed and popped on the stack. If you are talking about a single view controller, then you can manipulate the content of the `navigationItem` yourself.

jbm 2010-08-10 23:34:10

Eventually I simplified my view hierarchy greatly (this was a good indication I needed to) but I agree with this answer.

zekel 2010-10-27 22:10:33

ansaurus

tags:

views:

answers:

Style question: do you set your nav controller for all the child view controllers, even if they're not the top level view that is on the nav stack?

related questions