Programming starts with a
design
A lot of webpages and articles talk about how to program, but they don’t talk about how to design a program. Good program design separates the weekend programmers from the professionals. Sure, anyone can piece together a working application but a good design allows a power and flexibility of adding new features, for example, without having to recode half of your application.
Here, we’ll talk about handling your initial views when your iPhone application loads. This might be a simple task if your application is simple, but take the case of having a welcome screen followed by a login screen followed by a tabbed view controller. You might set it up so that one activates the other upon being dismissed itself.
Here’s an example of how the process might look:
Program loads AppDelegate
Load Welcome view from AppDelegate
Dismiss Welcome view -> Tell Welcome view to load Login view
Dismiss Login view -> Tell Login view to load Tabbed view
What if you had to add a view or remove one, say if the login was no longer needed if you gave your users the option to save their credentials. You’d have to rewrite two different view controllers at least. And this is just a simple example so you can see how complicated this chain of views would get once your application grows. For most programmers this way is fine, and sadly enough most of the time, this is the way it’s done. But true programmers are lazy. Lazy programmers are good programmers. So be lazy and write good code so that when (not if) you go back and edit your code, it’ll be a snap.
A design starts on paper
Your programs should be conceived on paper. Even with applications that attempt to do this, I still find paper the ultimate programming tool (even though I did the one below on a computer).
Class Diagram
First off, your controllers should be logically separated based on their tasks that they need to accomplish (not based on how the user will view them). So, you should have a controller or controllers to handle logging in and session creation and have appropriate UIViews and UIViewControllers to get and display info to your user. This may not be a one-to-one relationship though. For example, you may not have a UIViewController that’s associated with creating your sessions at all.
Next you will have your application’s business logic view controllers, controllers and all that jazz. The controllers sit independently to the view controllers except, of course, where there’s coupling or interaction. They are not tied directly, or rely upon any particular view. You illustrate those connections on paper (or in this case in the example diagram above). So if your “Add New Event” feature, let’s say, needs access to the session data, draw a line from your SessionController to your EventsController with an arrow pointing in the direction of the flow (from EventsController to SessionController in our case since the Events controller needs to know about the SessionController but not vise versa).
Abstraction solves everything
Since your controller code should be independent of how your views are laid out, you won’t have your AddNewEventViewController (the view that lets the user add an event) handling the actual creation and saving of events but will instead gathering and packaging the information taken from the user and given to an EventsController to handle the manipulation. Who knows, you may have several views that edit an Event in one way or another and if you change something in how the Event is saved, you’ll have to go into the code of each one that touches Event and rewrite code — exactly what we’re trying to avoid.
Abstracting the data in this way is called indirection and “All problems in computer science can be solved by another level of indirection;” — David Wheeler, except as Kevlin Henney says, “…except for the problem of too many layers of indirection.”
Singletons, under used
and under appreciated
So, you should have a session controller that sits somewhere ready to be called by who ever needs to validate a session or login (those views that would need access could be your tabbed views, could be your app delegate when your app starts, or could be in your settings views where you type your login info or when you log out). This is usually accomplished with a singleton class where any controller can access that one (and only) instance of your controller without having to pass around references to that controller. It not only cleans up your code, but also helps data integrity by not allowing multiple objects to edit the same data.
Handling your initial views
You should really have a separate controller handle organizing your views rather than the app delegate since the app delegate should really only be used to initialize your app and handle delegation of your application, not controlling business logic. So the structure should look like:
AppDelegate -> MainViewController -> LoginViewController
I like to have an overall MainViewController that handles all the subviews, be it a tab bar view controller, a table view controller, or whatever your main view is going to be. This level of indirection allows you to easily change what your main view controller is later, should your requirements or ideas change. Having said that, the MainViewController is going to need to get and maintain a reference to the application’s window.
To actually add the views, stack them on top of each other. Add the Tab Bar Controller’s view to the Window’s view first, then if needed, add your login views after that to stack them on top, and then remove them as needed when you’re done with them. By removing them from the top, it reveals the bottom view.
In MainViewController’s implementation file, your viewDidLoad: will look like:
- (void)viewDidLoad
{
[super viewDidLoad];
[mainWindow addSubview: tabBarController.view];
[mainWindow addSubview: loginViewController.view];
[mainWindow addSubview: welcomeViewController.view];
}
Where mainWindow is an IBOutlet to your Window in your MainWindow.xib file (or you could get it programatically if you prefer). Also, loginViewController is a pointer to your view controller that you put on top of the tab bar controller. On top of your login view, put a welcome view displaying any text, graphics or video to show after your application loads; note that this is different from your Default.png initial image. Then when you’re done with your login view, call removeFromSuperview on them to remove them from the view stack. So something like this in your MainViewController (since it handles all manipulation of your main views):
- (void)removeWelcomeView
{
[welcomeViewController.view removeFromSuperview];
// Any other code you need to clean up after your welcome view is removed
}
- (void)removeLoginView
{
[loginViewController.view removeFromSuperview];
// Any other code you need to clean up after your login view is removed
}
Obviously, when you remove the welcome screen view, under it (since you added it on the stack before the welcome view) is your login view. Then, removing the login view will show the tab bar view since that was added first in your view stack:
(Top)
Welcome View
Login View
Tab Bar View
This way we’re loading all of our views at once and stacking them so the one on top hides the one below. This has a slight overhead since you’re adding all your views when your applications starts but you can always delay adding the tab bar controller to the Window’s view until all the initial views are removed, for example. Then, if you’d like, using the MainViewController, you can add views on top of the tab bar view during execution, for example if you need to login again.
There are a few different ways to handle multiple views and each case is different. This is just one idea, with a few general guidelines. Feel free to ask any questions in the comments if anything wasn’t clear enough.
Sample Code
The following sample code is provided as is for educational and demonstration purposes. I threw it together really quickly and is only used to demonstrate the use of a MainViewController. Normally, you’ll want to make your MainViewController a singleton class, but in this example I passed the MainViewController instance to the subviews in order for them to call different methods on MainViewController to change the current views. By using a singleton design, you can avoid passing around this reference since there is only ever one MainViewController.
Also, this code demonstrates how to create a tab bar programmatically. It needs to be the root view of your window, but that doesn’t mean it needs to be the root view controller. We are still allowed to use a MainViewController as our root to handle all subviews and their controllers.
Download sample code (2010-02-11_TabBarTest.zip)
