I need to have a Tab Bar navigation at the end of a branch in the Navigation Controller, as illustrated basically below. (I am using storyboard for structure, and doing everything else programmatically.)
Is this acceptable and stable? (Xcode seems to have no objections.)
Could I put another Tab Bar nav, inside the initial Tab Bar nav, so there would be 3 tiers:
Nav Controller > Tab Bar > Tab Bar
Thanks for any suggestions and advice.
You can do all of this. Xcode won't object. The various view controllers can all contain each other, and will behave (mostly) as you expect.
You might want to think about whether you should do all of this. The View Controller Catalog makes reference to the fact that tab bars always wrap navigation controllers, not the other way around, and similar statements have appeared in the View Controller Programming Guide.
What's more, the particular view controllers that Apple provides generally have an expected user interface, one that users have grown very accustomed to seeing in other apps. Combining multiple tab bar controllers might break those expectations - hierarchical content like that is generally contained in navigation controllers instead. Consider reading through the Human Interface Guidelines before proceeding with this structure.
I believe you can. Tab bar and Nav controller are both container controller and they can be used to contain any kind of controller: container controller or content controller. Have a look to the ref doc for more info.
Not really AFAIK. But you can use a UITabBar NOT a UITabBarController wherever you want.
See this blog article: http://www.alexmedearis.com/uitabbarcontroller-inside-a-uinavigationcontroller/
Related
I've yet to find an example that does this. A client wants a navigation-based app where two sections (one nav-screen each) need to have a few views, controlled by a tab bar. I'm having difficulty setting up the logic of connecting all of the elements and making sure the flow makes sense (ex. hitting the nav-bar's back button on any of the tabbed views will lead back to the same screen).
I answered a similiar question not long ago (if I understand your question right). This will add a tabbar as a rootcontroller and each tab has its own navigationcontroller.
Right design pattern for tabbed navigation views?
EDIT
From UITabBarController documentation
Because the UITabBarController class inherits from the
UIViewController class, tab bar controllers have their own view that
is accessible through the view property. When deploying a tab bar
interface, you must install this view as the root of your window.
Unlike other view controllers, a tab bar interface should never be
installed as a child of another view controller.
As #Jolly good has mentioned, Apple HIG suggests not to do such implementations.
The only other way I can suggest is to try implementing a custom view controller that looks/behaves like a tabbarcontroller and make use of that.
Another hack I can think of, not sure if it'll work or if its possible, create a tabbarcontrller the usual way and then set the hideBottomBar property, and make the bottom bar visible only when you want it to be visible.
It is possible, despite the documentation that #Jolly good cited.
As a real world example, let me describe a game of mine. It consists of a UITabBarController (UITBC) and UINavigationController (UINC). The "main" window of the game is the Root view of the UINC, and when the game is active, it hides both the tab bar and nav bar to maximize screen real estate (not as necessary for iPad, but still...).
When the game is idle (paused, between rounds, etc.), it pushes the UITBC onto the nav bar. It also tells the UITBC to make a particular VC selected. That allows access to the additional screens (About, Scores, Instructions, Settings, etc.), and the player can navigate using the tab bar. In addition to the additional views on the tab bar is the game controller that simply pops the UITBC from the nav bar to revert to the game view to un-pause, go to next round, etc. (Obviously, the UITBC is cached within the game VC so it can be pushed back when necessary.)
Using this sort of logic, it is possible to mix and match tab bar and nav bar controllers for complex navigation. You can get away with this for games; just make sure that any non-game app follows Apple's HIG so as not to confuse the user.
I hope this helps.
I have the following structure in my app, is this a correct/valid way of doing it?
UINavigationController attached to the window, the rootcontroller in this navigationcontroller is a UIViewController that presents a tableview. When a user taps one of the rows a UITabBarController is pushed on the stack.
This works, however I began to be unsure when I read this:
Because the UITabBarController class
inherits from the UIViewController
class, tab bar controllers have their
own view that is accessible through
the view property. When deploying a
tab bar interface, you must install
this view as the root of your window.
Unlike other view controllers, a tab
bar interface should never be
installed as a child of another view
controller.
This is not recommended, but it should be OK. The aweful Wordpress app also does this. This depends on the design of your app.
I'm not shure about Apple's approval.
The reason why this is not recommended (and thus might not get approved - now or at a later point!) is user confusion.
Users are used to regard the tab bar as top-level navigation. So if dig down using the table and navigation, and then getting a UITabBar, this is horrible for navigation as the user doesn't know what to expect.
The solution here, of course depending on the use case, is a "switch" in the navigation bar or a toolbar. UISegmentedControl would be a natural choice.
hi
I'm new to objective-c
i need to create a view, that has four buttons at the bottom, and a view above them that changes according to which button you press.
now i've been reading a bit of tutorials, and i still have difficulties understanding the different nib files.
But i'm wondering.
i have 'tab bar controllers' in the controllers sections in the library and i have 'tab bar' in the 'windows views and bars' section.
now according to what i've read, and understood...
i have to use tab bar controller and add it to the 'Mainwindow.xib' and implement and link the stuff.
But can't i just add a tab bar in my 'appnameViewController.xib', and manage the tabbar items' click to change views. without relying on the tb controller??
If you want tab bar functionality you really should use UITabBarController. While it is possible to repsond to the the taps on the tap bar and switching views by yourself it is not recommended. Some reasons why:
You would just duplicate code that UITabBarController already does.
UITabBarController will handle things like unloading views not on screen when a memory warning is received.
If you end up changing the amount of tabs in your application it would still just work with a UITabBarController.
There are probably many more better reasons but since an iOS device have limited memory the memory aspect alone would make it a no brainer.
You need to familiarize yourself with the Model-View-Controller design pattern, which Cocoa follows religiously. Controllers deal with the application-specific logic the user interface (the views) provides.
For example, a button is a view but a controller handles the button's click (and setting its enabled/disabled state, etc.) depending on application logic.
I think you are confusing the tab bar view with it's view controller (UITabBarController).
Apple's documentation explains it well:
http://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/TabBarControllers/TabBarControllers.html
I am sure this is very simple, yet I am stuck...
I have created an application and added UITabViewController (dragged in from the library in Interface Builder. My application has 3 different views, clicking on appropriate tab brings the different view. So far so good.
I want to convert one of the views to be a UINavigationController: basically a table with the option to delete rows (so UINavigationController would need to have a button "Edit" on top).
I saw many samples which would do either 1 or 2, but not both.
How would I combine it, keeping in mind that I have used provided UITabViewController and did not added UITabBar directly to the view.
Thanks
If you are using Interface Builder, you should be able to just drag and drop a navigation controller into your tab bar controller as a child controller. The next tab bar item should be generated for it automatically from that.
You can also do this programatically by just creating however many UINavigationControllers you need in an array and assigning that to the uitabbarcontroller appropriately.
I actually don't like this method of combining the UINavigationController and UITabBarController since the tab bar controller must always be visible, which can be really confusing sometimes.
Instead, I recommend you make your own custom UITabBarController (Tab bar controller inside a navigation controller, or sharing a navigation root view) which you add to the navigation controller. I personally don't know why Apple didn't do this; hopefully this is the standard way in 4.0 :)
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.