I'm curious what the best method is for managing the traversal through several views without burning screen space using a navigation bar.
As an example, assume I have four UIView's with associated UIViewController's:
1: Top level menu (invokes A or B.1)
1.A: Menu selection A (return to 1)
1.B.1: Menu selection B, part 1 (invokes B.2)
1.B.2: Menu selection B, part 2 (return to A)
First, I'm unsure if a navigation controller is appropriate when I am not using a navigation bar. As an alternative, I am considering implementing a custom UIViewController that holds view controllers and acts as a screen manager.
Thoughts?
You can always hide the navigation bar using setNavigationBarHidden:animated:
Other than that it depends on what type of app you are building. Yours sounds like something that could use a Tab Bar, although that doesn't solve your problem of taking up screen space.
XCode's templates offer another way to do it - try looking at a new project that is a "Utility" app. It shows how you can seamlessly switch between a couple of different screens.
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'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.
I'm looking to create a UI similar to that of the Maps application just to try out some odds and ends and brush up on my knowledge of interface builder.
What i'm struggling to discern at the moment is how the Maps application handles the interactions between the toolbar and the navigation controller and which UI elements are needed to mimic the interface. I'm guessing that the Maps app only has one view controller which kind of negates the need for a navigation controller so i'm not sure if i'm using the right application template currently but i'll come back to that one later.
To give you an idea of what I'm looking to copy, if you search for directions between two locations and then hit route, the navigation controller changes from:
[Clear] Directions [Cancel]
to:
[Edit] {car | train | walk} [Start]
That's all fine so far, nothing out of the ordinary from what i'm used to doing. What is confusing me however is the semi transparent view underneath the navigation controller that displays the total distance and time (or other information depending on the search method). What is the UI element? Is it simply a toolbar tacked on to the main view? How would I go about adding this to my app, is it part of the view, or part of the navigation controller?
Also, in a similar vein... Clicking the "Search" segment in the toolbar displays the search field at the top of the app. Is this in the navigation controller, or is the navigation controller hidden whilst the search field is displayed? Again, clicking "Directions" displays the search field but this time with an additional search field and a button to switch the order of the fields. How is this achieved?
I'm not so good with the terminology so excuse me if i've mixed up some terms. I'm just trying to get to grips with the UI elements as i've spent most of my time learning OpenGL so it's all a bit new to me still. If anyone can point out the right UI elements used in the Maps application, that would be greatly appreciated!
Many thanks for reading.
Edit: I've uploaded an image to illustrate the UI elements i'm querying in this question.
I have no inside information, so I'm speculating on how I'd do it.
I'd use a UIToolBar for both the top and bottom bars, not a navigation bar. You can put a tool bar anywhere as they're just a subclass of UIView.
The semi transparent view underneath the navigation controller is likely just a custom view on top of the map view. Again, just a subclass of UIView.
The items in both toolbars would call methods in the view controller that could change the contents of either tool bar or hide or show other views.
For example, the Search button might call a showSearchToolbar: method, while the Directions calls a showDirectionsToolBar: method. Both methods would just change the contents of the top tool bar and hide or show the view beneath the top tool bar.
Check out the UICatalog example code from Apple to see how to dynamically change the contents of the tool bar.
Trying to implement the following behavior on an iPad.
I have a map-centric application which uses a tab-bar interface. The tabs at the bottom allow the user to choose between looking at the various different types of points that are marked on the map (e.g, think of the tab-bar items "food", "lodging" and "gas", where the "food" tab shows a listview of all the restaurants in the area, and so on).
The top half of the screen should always show the map. The bottom half of the screen is what should be controlled by the tab bar. However, there needs to be one tab on the tab bar that will make the map full-screen (not covering the tab bar itself, but covering everything else).
My impulse is that what I need is a map-view which always covers the whole screen, and then a tab-bar-controller that controls a view which sits on top of the map view, and then when the user selects the full-screen-map tab, the content view just gets hidden. But how do I actually do that?
Thanks!
I would go so far to say that this barely possible using a standard UITabBarController. Instead, you should use the UITabBar directly in your interface and then link the actions of the items directly to your root view controller. This controller should then lay out the content area accordingly. This could be done quite easily by giving your nib a structure like this:
- ViewController
- View
- View // place contents here
- TabBar
- Item1 // link action to ViewController
- ...
Depending on how generic you want your solution to be, you could also implement a custom subclass of UITabBarController that does the custom layout. The above solution is the simplest and might require the least code.
Suppose that I want to create and application and that application will have two windows and a menu mechanism. How do I accomplish this on iPhone? I know how to create a single view and have that displayed but what I want is this ability:
a.) Upon loading app, show a navigation mechanism. The choices are Item A or Item B.
b.) If Item A is chosen, view A should be loaded.
c.) It Item B is chosen, view B should be loaded.
Thanks in advance.
To me, what you're describing sounds like three views.
1. Root View
This view has two buttons (or other controls) that allow the user to select where they would like to go.
2. View A
A view with the necessary controls and data.
3. View B
A view with the necessary controls and data.
The actual transition between the views could involve a UINavigationController. If so, the root view would be pushed onto the UINavigationController's stack initially, and clicking the buttons would push either view A or B onto the stack. Otherwise, views A and B could be presented modally when the appropriate button is clicked by calling [rootView.presentModalViewController:animated].
Is that what you're looking for?
Since you mention a "menu", is it possible the user may like to go back and change their selection (A or B) at some stage?
In that case you may like to also investigate if a Tab Bar Controller based application fits your needs (similiar to the built in Clock application)
This would always display two buttons at the bottom of the screen which the user could use at any point in time to switch between the two modes. it would automatically handle the switching of views "A" and "B" within the main part of the screen.
The real answer probably depends upon what your two views need to do, and what kind of UI they present.