I have two tabs on my app that handle different flows.
For each tab I want to have a controller that determines (based on info in the app) which view to display.
So you click on tab 1, the app goes through some logic and displays either View B or View C. From there I use a navigation controller to go to other views within that tab.
To handle the initial logic of figuring out which view (B or C) to display I have a view controller (View A) linked to the tab that handles all the logic. My issue is that if I click on tab 1 while I'm already "on" the tab it displays the view for View A, which is a blank page.
Does anyone have an idea of how to architect this or make it so the view for View A is never displayed?
UITabBarControllerDelegate
in your implementation of:
tabBarController:shouldSelectViewController:
you should try to detect if you are already on the first tab or not. if so just return NO and it won't pop to the root controller (in this case A)
The idea behind the MVC model is that such logic is not execute by ViewControllers but by the Model.
You could create a class or method who's purpose is to make the decision between view B or C, call the appropriate method on a button click and display the view depending on the result.
My point is: the way you describe it view A should not exist.
Related
I would like to develop a ipad apps which has a menu at the top of the screen as well as at the bottom.
There are four buttons on the top of the screen, and there are 10+ buttons at the bottom tab bar, which can be scrolled horizontally.
How can I write the root view controller as a framework for this operation?
Should I customize the UIViewController class or UITabBarViewController?
Thanks
EDIT:
Sorry for being unclear. Let me restate my question.
Actually my app will have the following hierarchy.
'Front Page' is simply a page (view controller) for user to choose language. After choosing the language, 'Menu Page' view controller is displayed.
Starting from Menu page and ALL view controllers (VC) in below, the page layout is something like this.
As you can see, there are top menu and bottom menu. Clicking on the buttons the app will quickly jump to the corresponding view controller (3rd level in the tree, VC1,VC2,VC3 etc) . And for every view, there is a BACK button on every page, clicking which will back to the parent view controller.
I was thinking to implement this by using a tab bar view controller and a navigation view controller but I still do not have a clear idea how to implement this.
Or maybe should I just use the navigation view controller and hide the top tool bar except the back button, and display an overlay UIView as menu which is on top of all other UIViews.
Can somebody help me? Thanks.
Since this is the outermost container for my app I hope to do it properly at start..
Sorry for my long question.
If you really want to develop a framework for this logic .You need to create Manager, ViewController, View, DAO ,Model and other classes according to your needs.
I assume you want to add the buttons dynamically to the tabbar (and if it scrollable , it must be a scrollview).You can use Toolbar for upper view but then it won't be in sync with the bottom-view(visually).In that case you will have to create your own customized views to look like a tabbar.
The manager will basically keep a track of all the buttons and different states of events and action on the views and the same information can be accessed via a static method form the viewcontroller.
Well you have not detailed on your needs , so it's difficult to predict the entire architecture.
You need a container view controller to manage selection of VC's 1-4.
clicking which will back to the parent view controller
Parent view controller is used to mean the container vc in a container view controller scheme - I'm not sure that's what you mean in this comment. Where exactly does the back button go?
See this link for more info about container VC's.
https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/CreatingCustomContainerViewControllers/CreatingCustomContainerViewControllers.html
You should be able to embed a tab bar controller in the content view of the container VC. Should be able to but it might be really buggy if there is a lot of communication between the child vc's.
The hard part is the back button. Basically it must be a button that goes back to VC 1-4 depending on which section you are in. The easiest way to do it is to make sure that when you cycle view controllers, pass the back button information as to which VC is the current child so it knows which VC to navigate to when you press it.
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 have an application containing a variety of view controllers linked together in different ways (Welcome > Browse > Preview OR Browse > Preview OR Settings > Splash). The first view controller is presented modally using a navigation controller from a main controller, then the next set of view controllers are added using pop and push.
This works correctly, but I need to be able to define my 'UINavigationBar' and 'UIToolbar' within interface builder, so they still work as expected if they are presented without using a navigation controller. Is this possible? Currently I get this if I try:
alt text http://xs.to/image-CD8B_4B9E739D.jpg
Do it in code.
In the SDK it appears you're using, it is fairly trivial to test whether you need to push onto a nav controller or not, and if you are hide the toolbar and adjust the view size to account for that (a custom init method for the view controller will help with this, and if you're particularly smart with how you do things you could even declare a category on UIViewController)
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.
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.