• Choose a category
• All
• Classic-Fiction

@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.

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.

Figure 27.5 MVC flow with user input

It’s critical not to underestimate the division of responsibilities