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.
Related
I am coming from a Windows Visual Studio (VS) background, so I'm finding the Xcode environment, well, overly complex for lack of a better description.
I'm planning an app which will need 4 views (what I would call windows in VS).
1) The main (starting) view would have a Toolbar at the bottom which opens any of 3 views.
2) View A would have a Nav bar at the top for "Cancel" and "Done" which would return to Main.
3) View B would have a Nav bar at the top for "Back" which would return to Main
4) View C would have no Nav bar but would return to Main using a DoubleTap.
I'm finding it very confusing to piece this together without a straightforward example.
Where can I find some clear explanations of Views vs Controllers, what they're each used for, and how to use them, preferably with examples/tutorials/etc?
Online is best, books are fine.
I'm using Xcode 4.2, no storyboards (for ios 4.2 compatibility).
Thanks.
The general distinction between view controllers and view is something that you can understand independently of Xcode/Cocoa - it's a design pattern called MVC (Model, View, Controller).
In MVC, your application structure is split into 3 layers:
1) The model is your data layer, such as files, databases, network services, and objects that exist independently of the display such as a user.
2) The view is what you see on screen. A view is often composed of several sub views in a hierarchy, for example a window (which is a type of view) contains a toolbar (another type of view) and some buttons (each a view), labels, text fields, etc. These are all views.
3) The controller, aka view controller is the glue that connects these two together. A user object for example has no idea how to display itself, and a label has no knowledge of a user object, so it is the job of the view controller to tell a particular label to display the name of a particular user. Similarly when you type text into a text field, the text field doesn't know that text is a password, so it's the job of the controller to take that text and store it in the correct place, or submit it to the correct web service, or whatever.
So basically a controller converts your model data into the right format to display within your views, and handles feedback from your views (a button press, a text entry, etc) and modifies your model accordingly.
In cocoa every view controller owns a main view (it's "view" property) and may also manage the subviews of that view such as buttons, labels, etc.
Normally there is one view controller class per screen of your app. Occasionally parts of your screen that have standard behaviours are managed by other view controllers.
So for example the navbar is managed by something called a navigation controller. A navigation controller actually manages a stack of view controllers as well as the navigation bar view itself. When you push or pop a view controller onto the navigation controller stack, it makes sure that the view from the current view controller gets displayed and that the navbar shows the correct title. When you tap the back button in the navbar view, the navigation controller receives that button event and pops the current view controller (and it's associated view) off the stack.
The advantage of this approach (MVC) is that is massively cuts down on the amount of subclassing you need to do. Every button on your screen is probably just an instance of a standard UIButton object. You don't need to subclass each button just to change it's behaviour because the button doesn't need to know anything about what happens when it is pressed, it just delegates that press to the view controller to manage.
Generally, you rarely need to create custom view subclasses. Almost all of your application can be built by arranging standard views on a screen and managing them with a custom view controller subclass.
Nibs/xibs are particularly useful for this because they let you visually lay out your views and visually bind their actions (e.g. button taps) to methods on your view controller using drag a drop. This saves you filling up your view controller with pointless layout code (create a button with these coordinates and this colour and attach it to this subview, etc). Unfortunately nibs can be confusing for new developers because they hide a lot of what is going on behind the scenes.
For multi-screen apps, iOS provides a set of so-called container controllers, which are controllers that manage multiple sub-controllers. UITabBarController and UINavigationController are the main examples. UITabBarController is good if you have several screens that you want to tab between, UINavigationController is good if you have a hierarchy of screens that the user can go back and forth between like a browser.
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 am making code for iPhone. My first screen has only one button with text Menu. When user will click on this button next screen is coming with multiple navigation bar.Each Navigation bar has their own Text information which are being selected after clicking on any Navigation bar.
How i should to design it for iPhone ? Please give me concept. Should i take multiple views ? If i have multiple views how will i hide and show on button click event ?
Thanks in advance.
You will have to adapt your user interface to comply to how Apple wants an app to work, look, and feel - or make your own custom viewcontrollers. Even then, you might not get the exact behavior you want.
My hottest tip is to look at similar apps on appstore and see how they are navigated.
I don't get a picture in my mind from your description, but it seems you want what is called "drill down". This is best done with tableViews.
You can't have multiple navigation controllers on the same "screen"; it doesn't work like that on the iPhone. Instead, what you have is one single Navigation controller, that controls the pushing of views. You decide which sub-view to push depending on which selection the user makes, and the Navigation controller handles the rest of the interaction with the user to let him or her navigate between the views.
Example structure:
Window-based app
+-MainWindow.xib
| +-First view with button
| +-UINavigationController
+-tableview1.xib
+-tableview2.xib
+-any more views you need.
Make the app delegate a <UINavigationControllerDelegate> and declare navCt *UINavigationController, and connect it in Interface Builder. You can then write a pushVC method, which takes as argument a UIViewController *vc. It does a [navCt pushViewController:vc animated:YES];
Connect the button to an IBAction, which then calls the method in the app delegate, [PushVC myVC], where myVC refers to any viewcontroller in your app, in this case table view 1.
In this table, on didSelectRow... event you can use the same method to push the sub-view table view 2.
I think this is minimum code if you are unsure about iPhone app design. Either way, I hope it gives some ideas.
You should read about UINavigationController, UITabBarController, UIViewController.
http://developer.apple.com/library/ios/#documentation/uikit/reference/UIViewController_Class/Reference/Reference.html
You almost always make one view pr. viewcontroller.
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.
I am using a UITabBarController as well as a UINavigationController on my app.
In my UITabBarController I am using more than 5 items so I automatically get the 'More' item.
I've managed to add a saving procedure so the order of those items will be kept in case somebody changes the order etc.
With 'More' active I get the More navigation controller with the 'Edit' item positioned under my UINavigationController. Both navigation controller are visible. When I click on 'Edit though the More navigation controller disappears and seem to be hiding under my UINavigationController and therefore I can't see/use the 'Done' function to save my new order
What did I miss?
Cheers
It sounds like you have a UINavigationController as the main VC of your app, and a UITabBarController as one of the VC's on its stack.
I believe Apple actively discourages people from doing this in their apps, and so do I. It is never done in the iOS itself, and I have never seen it in any third-party apps either, so users will probably be confused.
I think you should embed the UINavigationController inside the UITabBarController instead of the other way around, or you could just choose to use another way of showing what you want to show.
I believe iOS does use both navigation controller and tab controller at the same time in their iPod app. The navigation controller takes you to the playing song and back and at the same time you have the tab controller when you select songs/albums/playlists etc. However, the navigation controller (or tab bar controller) seems to be custom made as it handles the More->Edit case by hiding the navigation bar underneath the Edit bar, which is not what the default UITabBarController does.
All in all, I see Apple is rather "creative" when it comes to UI design. For example, in the email app, "New" button is in the lower right corner (bottom bar) while in the SMS app the "New" button is in the upper right corner (navigation bar). I think they pretty much make custom UI to fit the individual needs of the app instead or rigidly following some consistent design.