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.