This is more of a philosophical question than anything, so give me your thoughts.
The iPhone SDK documentation specifies that you may have a tab bar controller contain a navigation controller, but you can't have a navigation controller contain a tab bar controller. It seems that there are times when you might want to organize views within a view that is part of a navigation controller stack in a tabular fashion. Is this unreasonable?
I accept what Apple dictates in these areas as gospel as the HIG does provide best practices that seem to reveal the path of least resistance (I'm sure there are exceptions to that). In the tab bar case, however, I'm not sure the design reasoning behind it. Maybe it's obvious to others, but I can't think of a good reason why you wouldn't allow tabs as anything but a root level view controller.
What do you all think/know? What design flaw would this create? How would you solve this problem of wanting a tabular presentation of views within a view? Do I need to re-think the entire design?
Thanks.
I can see where they are coming from, from a design perspective. Tabbars feel anchored, constant, where navbars feel dynamic and mutable. So a tab containing dynamic content makes sense, whereas a single spot in the dynamic hierarchy of a navigation stack containing a tab bar, anchored to the bottom of the screen doesn't feel as right. The Three20 implementation does handle this in a way that makes more sense, anchoring the tabs underneath the nav bar, so that they feel more like they are part of that spot in the navigation stack.
Having said that, Tweetie rolls it's own tab bar, if I remember correctly, without a UITabbarController to circumvent this detail in the UI guidelines, and it totally works from an interaction perspective.
The short answer is it would be confusing to the user to allow UITabBars inside a nav controller. The app would certainly not behave as most users would expect. But, that's just UITabBar, not the design concept of tabs in general. Tabs inside a nav controller, should, in my design opinion, go at the top, not the bottom, as does a UITabBar.
There are a few different ways to do this.
I've done "tabs" inside a navigator view controller by having the first row in a table view have a segmented picker. (See the HangTime app on the app store). I think it works pretty well, but they aren't really "tabs".
Joe Hewitt, the guy who wrote the Facebook app, solved this problem by creating his own "tab bar" view and controller, although it's rendered quite differently than a UITabBar. That element is available through the Three20 framework, and open source library. Check it out:
http://github.com/joehewitt/three20/tree/master
I think the tab bar controller is intended to be the main point of navigation around an app if it's used. If a nav controller contains a tab controller, then the tabs will switch whenever you navigate elsewhere, which may be confusing to users who are used to using them the regular way in other apps. I think its a cool idea however, but apple may not feel the same way.