I have an application that seems best suited for a navigation controller. There are a few places where navigation splits off and is not completely hierarchical but I think I can remedy that just using a modal view at those points.
I want to know if this is the best way to navigate through multiple views or if there is a better way. I want the user to be able to progress through several steps but be able to go back a step or even return to the beginning at certain points.
Additionally, I want to be able to do this using custom buttons. I want to use the entire screen without any navigation bars, etc. I figured I could push and pop the stack with my own custom buttons but I want to know how to make sure the screen is totally usable by me.
As far as I know, Navigation controller is the best way to navigate among views, you can go back and forth between views using navigation controller easily, even you can present navigation controller as modal view. You can specify your own custom navigation items in navigation bar. And if you do not want navigation bar, you can hide navigation bar. pushing and popping is the best way to implement navigation among views.
#gonzobrains
I have been in that situation!
Here's what I'd do:
"Hide the navigation bar" using the setHidden property. At places where you want the navigation bar to be seen, I suggest you use a UIToolbar with custom buttons. (its almost impossible to differentiate)
to go back one step you can popViewController
to go all the way back you can use popToRootViewController (like the top right corner button in the IMDB app)
There is no reason why you should not be able to use a navigation controller without using the navigation bar.
Hope this helps!
Keep the nav controller, but you can hide the nav bar easily enough. It could be a viable solution, but make sure your implementation is solid and clear; otherwise you may be rejected. A possible alternative would be to have pages side by side, as in the weather app…but it's your decision as to which paradigm is best.
Related
I am making an app that has both a bottom bar and a top bar (both are customized) and i want them to stay there the entire length of the app while the middle portion switches between views. But the kicker is at some points in the app, i want to have the top bar and bottom bar slide off the screen and be able to be dragged back on.
What i was thinking was to have one main UIViewController with three UIViews (top bar, middle section, and bottom bar) each running code from their own respective files. Sort of like how a Tab bar works with a nav controller. or do i have that backwards? i dont really know... but any constructive advice helps =)
Im fairly new to xcode and i've been trying to find a way for a few days now, so please dont be too harsh on me. Thanks!
In general, we build one view controller for each 'screenful' of content. So the basic advice for you would be to make the app in a way where each 'section' is it's own view controller. This is especially important to the MVC paradigm, where your business logic should be in the viewControllers, not the views (just display and interaction logic there). If you had just one view controller, it would get convoluted FAST by trying to manage multiple sections.
A good route may be this: Embed the whole hierarchy in a navigation controller, which gives you the top bar. Then make a custom view controller class which knows how to make your bottom bar, and have each section subclass that.
The side effect is that the bottom bar will be uniquely created for each section VC. If that is not desirable for you, you can explore view controller 'containment'. It is basically a technique for building components like the navigation controller, which keep certain elements onscreen for a long time, while exchanging 'content' view controllers for a smaller portion of the screen. It's not the easiest thing to do, and should be considered carefully. However, if you really need to keep the same instance of something on screen while other view controllers come and go, it may be the right way to go. That said, consider the other idea first (each section manages it's own bottom bar). You can accomplish it in a way that promotes code re-use, etc.
My goal is to get a navigation bar like the HBO GO app on iPad. Their nav bar has a larger height and a custom background. It seems like they're using a navigation controller since when you press on a show it takes you to a new screen with a back button.
I'm wondering either
1) Can I use an instance of UINavigationBar without a NavigationController and use the navigation bar delegate to handle pushing and popping my views?
or
2)Is there another way that I can implement this?
I am currently trying to do this with a navigation controller and navigation bar but I am running into difficulties and I think its not the best way to do it. Also Apple docs specifically say not to change the frame of the navigation bar in a navcontroller.
Ideas please? Thanks in advance!
From the looks of it, the HBO Go application uses completely custom navigation controls. A basic UINavigationController-alike class is relatively straightforward to build, but you must be careful to consider that UIViewControllers are not intended to be nested on iOS <= 4 and so you will have to pass through several methods such as view{Will,Did}appear:.
I recommend starting from the ground up, as trying to heavily customize the built-in controls will only lead to further frustrations as you run into issues or limitations in their customizability.
I am working on a project which involves both kind of applications ie Navigation based and Tab based. All things are working perfectly. But what I want is, when I click on a particular tab then a button must be added to the navigation bar at the top to edit the table below it. I am able to draw the button but it is not affecting the tableview below it. When I do this in navigation based application it works perfectly. But it does not work in tab based.
So please tell me the way to add button at navigation bar in UI tab based application which appear only at particular tab.
tell me the sample code or any tutorial for it.
For each tab embed a UINavigationConrtoller, and your own view controllers in them.
This way each tab will have its own navigation bar, and thus can have their own sets of bar items, titles, etc.
You generally never want to embed a UITabBarController in a UINavigationController, always the other way around.
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'm building an iPhone app and I'm sort of confused about which approach should I choose for views and controllers.
I would like to have a tabbar at the bottom with three options. I would also like to have a main view displayed when the app shows (along with the tabbar) but I don't want this view to be part of the tabbar options.
So, when the app begins, the tabbar has no option selected but the main view displayed. When a tabbar options is selected, in its top bar it should display a back button to the main view. When the back button is pressed, the main view display again with no tabbar option selected.
Which approach should I choose?
Hope it makes sense.
Thanks.
I understand what you're trying to do, but you shouldn't do that. I don't like that design at all. You should have one navigation controller for each tab.
You should probably read Apple's Human Interface Guidelines as it's possible they would reject your App if they thought such an implementation with a TabBarController was confusing.
As an alternative, you could possibly have the "main view" as you call it accessible with a button in the Navigation bar at the top and then add that to all three tabs. Not necessarily a better design but you probably wouldn't be breaking the guidelines.
A better alternative might be to use a UIToolBar at the bottom instead of the Tab bar which has the three buttons spawning your views modally which can then be dismissed as you suggest.
Remember though, your App's users have built up a knowledge of how App's are generally supposed to navigate, feel and control so you should think carefully before deciding to go against that.
Firstly, I think you should reconsider giving your Main View it's own tab. That way it's a no-brainer for the user to return to that screen. BUT, if you STILL don't like that idea, read on...
The UITabBarController has the unfortunate side effect of not being able to be removed once created (even if you delay it's creation by instantiating it programmatically).
SO...
Option 1: Make your MainView a modalPresentation sub-view, displaying it ON TOP of one of the views in your tab bar (hiding the tabs until you're ready to show them again).
Option 2: Give a subview of your first tab a...
mySubViewController.hidesBottomBarWhenPushed=YES;
This will make the UITabBarController disappear temporarily (just on that view, until you're ready to show the tabs again).
Both options seem kinda messy to me, but they are possible. Depends on how well you execute them, I suppose.
Hope this helps!
You could add the main view as another tab.
OR
You present the main view modally when the app starts over the tab bar views.
The first option would be used more if the view holds the same kind of content as the tabs, for example if the app was an online store, the tabs would be Categories, Search and Recently Added, with what you call the "main view" being the Home page (showing offers or something). (So all the views/tabs would be showing products on the store)
The second option would be more if the content of the main view is different to the tabs.
Keeping with the online store example, if the tabs were Categories, Search and Recently added and what you call the "main view" being a login/logout screen. (so the tabs would be showing products, but the modal view ("main view") being more admin related, and it's main purpose not being to display products.