I'm trying to develop an app having a tab bar controller with 5 bar items.
All of the items need navigation controllers.
I just wanted to know whether it is possible to reuse the same navigation controller for all the items.
Are there any restrictions or things I need to keep in mind to do this?
Every tab in a UITabBarController should have its own UINavigationController, if you're in need of one that is. You push and pop UIViewControllers onto/off a stack and every UINavigationController has its own stack. Since the UIViewControllers from your other tabs have nothing to do with the navigation flow from the current tab, each tab should have its own UINavigationController.
I think I may have misinterpreted your question originally here... Navigation Controllers actually fine to re-use I think... I'd recommend release and creating a new on when the tab is changed if that makes sense within the application. You could give a reference to it in your appDelegate so it's easily accessible from each view controller.
Original reply follows in case I'm misinterpreting it still :S
The separation is entirely up to you, but for code clarity it's nice to have each viewcontroller separate. As a lot of the code will be found in your controller it's quite nice to separate out as much as possible. You can use the same controller, but change it's view property when each item is clicked, but it doesn't really save much and wil make for harder to maintain code...
Related
Sorry for the vague title!
I am trying to achieve the following functionality: A user is first presented with a UINavigationController containing a UITableView. When the user taps a cell in the table view, I want to push a new view which contains a UITabBarController (that'll stay visible regardless of the currently visible UIViewController) and a UITableView again, that people can again select a cell from and which will then again push to UINavigationController.
If a user selects a tab from the UITabBar, I want the first screen (without the UITabBar) to be the one that users can go back to, not the tab they just came from. Also, if a user selects one of the UITableView items on any of the tabs, I want the back button to go back to the previously displayed screen (as you'd expect with a standard UINavigationController)
I've spent hours trying to find the answer to this and I just can't anywhere! I hope I haven't been too vague or confusing in my explanation.
James.
If your desired UX is confusing to explain here, imagine how your users will feel! I would reconsider the intended design.
From the View Controller Programming Guide:
An application that uses a tab bar controller can also use navigation
controllers in one or more tabs. When combining these two types of
view controller in the same user interface, the tab bar controller
always acts as the wrapper for the navigation controllers. You never
want to push a tab bar controller onto the navigation stack of a
navigation controller. Doing so creates an unusual situation whereby
the tab bar appears only while a specific view controller is at the
top of the navigation stack. Tab bars are designed to be persistent,
and so this transient approach can be confusing to users.
That said, you can probably hack something close to what you are talking about but you'll need to write a bunch of code to handle the navigation using the UITabBarControllerDelegate and UINavigationControllerDelegate methods and keep track of whatever state you need to know where you want to navigate to based on a user action. Odds are you'll end up with something complicated to code, maintain, and worse, use.
I am a little bit confused about navigation controllers. In one navigation controller, a large amount of view controllers are present. I have seen so many examples with one navigation controller. Can we create multiple navigation controllers in iOS and in each navigation controller, can we define a number of view controllers? Is it possible? Please, someone explain this to me and give some real world examples if this is possible. Thanks in advance.
You should look at the sample programs in the Apple documentation. The Navigation controller is a stack which start at the app delegate level. You push view controllers into the stack and pop them out when you are done .... going back to the previous level. You can poptoroot which goes down to the lowest level just above the app delegate.
You have the option to have as many navigation controllers as you have Tabs in a Tab bar. it is not confusing ... Apple has a set of good examples that illustrate them ... Believe the sample about Elements is one.
I've got a UISearchBar in my view, and when the results button is pressed I'd like it to load in a new view. Is this possible without using a navigation controller?
I'm new to iPhone development so not entirely sure if moving between views is solely reliable on a navigation controller or not. From all the examples I've seen using pushViewController, it seems to look that way. Hoping I'm proven wrong.
UINavigationController provides the simplest way to manage a stack of view controllers, but it's not necessary by any means; you can move your views around, and add and remove them from the hierarchy, however you like. Can you elaborate on what you're trying to do, and why you want to avoid using a navigation controller?
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.
Im a budding iphone developer, and doing my best but i have a query regarding the UINavigationController.
I have a tab bar app, with 3 tabs.
The 1st tab has five UIButtons, each loading a different "section" of the app, and each section will have a number of views.
The other tabs simply display some info.
as users select any of the UIButtons on my first tab i am using [self.view addSubview: xxxxx];
and as users navigate away from this view i use [self.view removeFromSuperview];
My question is:
Is this a bad way to do things? should i use a navigation controller? The reason i have not used one is because i wanted a custom looking UI and i understand that the navigation controller forces your design a little.
And on top of that i will be using core data to implement persistent storage.... will my way of implementing this application cause an issue with core data?
Any help regarding thsi would be highly appreciated.
Cheers
Tom
First, if you don't need a navigation controller, then don't use it. You shouldn't feel bad about it. That said, I think UINavigationController doesn't impose a specific UI on you at all. It's very easy to hide the navigation bar and implement any UI you like. The thing that UINavigationController does impose is a modular design: each view is managed by a separate view controller and takes up the full screen. Only you can answer if this design is suitable for your app. If it is and if your app is designed around a hierarchy of views, a navigation controller is probably a good choice.
As you said: when one of the five buttons is tapped the users is navigating to another view and the five buttons disappear. This is what the navigation controller is designed for and helps you manage the memory better than simply adding and removing views (depending on how many views are added/removed it might also be better on performance). As Ole points out the NavigationController is highly customizable and doesn't impose much.
A NavigationController gives you more flexibility down the road: say you want to add another hierarchy level after one of the buttons has been tapped in version 2.0. Then you will find that your MainView will be growing as you keep adding views to it. A UINavigationController keeps your code well structured and lets you extend the navigation later one.
CoreData is very flexible and UI-independent. You shouldn't have to worry about this.