Objects in iTahDoodle

- (void)addTask:(id)sender;

@property (strong, nonatomic) UIWindow *window;

@end

Notice that you declare docPath() above the class declaration. That’s because even though docPath() is declared in the file BNRAppDelegate.h, it is not part of the BNRAppDelegate class. In fact, this function could have its own pair of files in the iTahDoodle project. However, because there is just one of these helper functions in iTahDoodle, we’re putting it the app delegate’s class files to keep things simple.

Now open BNRAppDelegate.m and implement your helper function. Again, because docPath() is not part of the class, implement it after the #import but before the @implementation line (which is where the implementation of the class begins).

#import "BNRAppDelegate.h"

// Helper function to fetch the path to our to-do data stored on disk NSString *docPath()

{

NSArray *pathList = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);

return [[pathList objectAtIndex:0] stringByAppendingPathComponent:@"data.td"];

}

@implementation

The docPath() function calls another C function, NSSearchPathForDirectoriesInDomains(). This function searches for directories that match specific criteria and returns an array of them. Don’t worry about what the arguments are; in nearly all iOS applications you will ever write, you’ll pass in the exact same three arguments and get back an array with exactly one item. (If you’re curious about how it works, you’ll find NSSearchPathForDirectoriesInDomains() in the Foundation Functions Reference in the developer documentation.)

Objects in iTahDoodle

Now we can get back to our objects. You already know about the five objects that make up the iTahDoodle application. There’s the instance of BNRAppDelegate, and this object has pointers to four others: instances of UITableView, UITextField, UIButton, and NSMutableArray.

181

Chapter 27 Your First iOS Application

Figure 27.4 Object diagram for iTahDoodle

Before we continue configuring and connecting these objects, let’s look at some theory about objects and their relationships.

Model-View-Controller

Model-View-Controller, or MVC, is a design pattern that centers on the idea that any class that you create should fall into one of three job categories: model, view, or controller. Here’s a breakdown of the division of labor:

•Models are responsible for storing data and making it available to other objects. Models have no knowledge of the user interface or how to draw themselves on the screen; their sole purpose is holding and managing data. NSString, NSDate, and NSArray are traditional model objects. In

iTahDoodle, your one model object so far is the NSMutableArray where tasks are stored. However, each individual task will be described an instance of NSString, and these will also be model objects.

•Views are the visual elements of an application. Views know how to draw themselves on the screen and how to respond to user input. Views have no knowledge of the actual data that they display or how it is structured and stored. UIView and its various subclasses, including UIWindow, are common examples of view objects. In iTahDoodle, your view objects are the instances of UITableView, UITextView, and UIButton. A simple rule of thumb is that if you can see it, it’s a view.

•Controllers perform the logic necessary to connect and drive the different parts of your application.

They process events and coordinate the other objects in your application. Controllers are the real workhorses of any application. While BNRAppDelegate is the only controller in iTahDoodle, a complex application will have many different controllers that coordinate model and view objects as well as other controllers.

Figure 27.5 shows the flow of control between objects in response to a user event, like a button tap. Notice that models and views do not talk to each other directly; controllers sit squarely in the middle of everything, receiving messages from some objects and dispatching instructions to others.

182

The application delegate

Figure 27.5 MVC flow with user input

It’s critical not to underestimate the division of responsibilities denoted by the MVC pattern. Most of the Cocoa and Cocoa Touch APIs are written with MVC in mind, and your own code should be, too. Now let’s return to our controller, the instance of BNRAppDelegate.

The application delegate

When an iOS application first launches, there is a lot of behind-the-scenes setting up. During this phase, an instance of UIApplication is created to control your application’s state and act as liaison to the operating system. An instance of BNRAppDelegate is also created and set as the delegate of the UIApplication instance (which explains the name “app delegate”).

While the application is being launched, it is not ready for work or input. When this changes, the UIApplication instance sends its delegate the message

application:didFinishLaunchingWithOptions:. This method is very important. It’s where you put everything that needs to happen or needs to be in place before the user interacts with the application.

In iTahDoodle, one of the things we need to do in this method is find the property list and load it into an array. In BNRAppDelegate.m, notice that there is already a stub for the

application:didFinishLaunchingWithOptions: method. Find it and replace the code between its braces with the following:

#pragma mark - Application delegate callbacks

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

{

// Attempt to load an existing to-do dataset from an array stored to disk. NSArray *plist = [NSArray arrayWithContentsOfFile:docPath()];

if (plist) {

// If there was a dataset available, copy it into our instance variable. tasks = [plist mutableCopy];

} else {

183