You are previewing Learning iPhone Programming.

Learning iPhone Programming

Cover of Learning iPhone Programming by Alasdair Allan Published by O'Reilly Media, Inc.
  1. Learning iPhone Programming
    1. SPECIAL OFFER: Upgrade this ebook with O’Reilly
    2. A Note Regarding Supplemental Files
    3. Preface
      1. Who Should Read This Book?
      2. What Should You Already Know?
      3. What Will You Learn?
      4. What’s in This Book?
      5. Conventions Used in This Book
      6. Using Code Examples
      7. How to Contact Us
      8. Safari® Books Online
      9. Acknowledgments
    4. 1. Why Go Native?
      1. The Pros and Cons
      2. The Release Cycle
      3. Build It and They Will Come
    5. 2. Becoming a Developer
      1. Registering As an iPhone Developer
      2. Enrolling in the iPhone Developer Program
      3. The Apple Developer Connection
      4. Installing the iPhone SDK
      5. Preparing Your iPhone or iPod touch
    6. 3. Your First iPhone App
      1. Objective-C Basics
      2. Creating a Project
    7. 4. Coding in Objective-C
      1. Declaring and Defining Classes
      2. Memory Management
      3. Fundamental iPhone Design Patterns
      4. Conclusion
    8. 5. Table-View-Based Applications
      1. Simplifying the Template Classes
      2. Creating a Table View
      3. Building a Model
      4. Connecting the Controller to the Model
      5. Adding Navigation Controls to the Application
      6. Adding a City View
      7. Edit Mode
    9. 6. Other View Controllers
      1. Utility Applications
      2. Tab Bar Applications
      3. Modal View Controllers
      4. The Image Picker View Controller
    10. 7. Connecting to the Network
      1. Detecting Network Status
      2. Embedding a Web Browser in Your App
      3. Sending Email
      4. Getting Data from the Internet
    11. 8. Handling Data
      1. Data Entry
      2. Parsing XML
      3. Parsing JSON
      4. Regular Expressions
      5. Storing Data
    12. 9. Distributing Your Application
      1. Adding Missing Features
      2. Building and Signing
      3. Submitting to the App Store
      4. Reasons for Rejection
    13. 10. Using Sensors
      1. Hardware Support
      2. Using the Camera
      3. The Core Location Framework
      4. Using the Accelerometer
      5. Using the Digital Compass
      6. Accessing the Proximity Sensor
      7. Using Vibration
    14. 11. Geolocation and Mapping
      1. User Location
      2. Annotating Maps
    15. 12. Integrating Your Application
      1. Application Preferences
      2. Custom URL Schemes
      3. Media Playback
      4. Using the Address Book
    16. 13. Other Native Platforms
      1. PhoneGap
      2. MonoTouch
    17. 14. Going Further
      1. Cocoa and Objective-C
      2. Web Applications
      3. Core Data
      4. Push Notifications
      5. In-App Purchase
      6. Core Animation
      7. Game Kit
      8. Writing Games
      9. Look and Feel
      10. Hardware Accessories
    18. Index
    19. About the Author
    20. Colophon
    21. SPECIAL OFFER: Upgrade this ebook with O’Reilly
O'Reilly logo

Fundamental iPhone Design Patterns

When you write code you’re probably already using patterns, although possibly you’re doing so without realizing it. A design pattern is just a reusable solution, a template, for how to approach commonly occurring problems. A pattern is not code, but instead describes how you should model the application in terms of the classes that are used, and how they should structure the interactions and relationships between these classes.

The Cocoa Touch framework underlying your iPhone applications is based on one of the oldest design patterns, the Model-View-Controller (MVC) pattern, which dates from the 1970s. The MVC pattern is used to separate the program logic from the UI, and is the generally accepted way to build iPhone applications. As it is used so extensively inside Apple’s own frameworks, including the UIKit framework, it would be quite hard to write an iPhone application without using this pattern in your implementation. While you could write an iPhone application without referencing the MVC pattern, it is enormously difficult to fight the underlying frameworks; you should instead work with them. Attempting to write iPhone applications while ignoring the underlying MVC patterns is a pointless exercise in make-work.

The Model-View-Controller Pattern

The MVC pattern divides your application into three functional pieces:


The model manages the application state (and associated data) and is usually persistent. It is entirely decoupled from the UI or presentation of the application state to the user.


The view is what the user sees, and it displays the model for the user. It allows the user to manipulate it and respond and generate events. In iPhone applications, the view is normally built inside Interface Builder rather than programmatically.


The controller coordinates updates of the view and the model when user interaction with the view makes changes to the model, and vice versa. This is typically where most of the application logic lives.

We implemented our Hello World application from Chapter 3 using this pattern. We created the view using Interface Builder, and the HelloWorldViewController class managed the view. The application was too simple to require an explicit class to manage the application’s state; effectively, the model was embedded in the ViewController class. If we were strictly adhering to the design pattern, we would have implemented a further class that our sayHello: method would have queried to ask what text should have been displayed.

The model class is usually a subclass of NSObject and has a set of instance variables and associated accessor methods, along with custom methods to associate the internal data model.

Views and View Controllers

I’ve talked about both views and view controllers quite a lot, and while so far we’ve built our views in Interface Builder and then handled them using our own view controller code, that isn’t the only way to build a view. You can create views programmatically—in fact, in the early days of iPhone development you had to do things that way.

However, Interface Builder has made things a lot easier, and I recommend that in most cases you build your views using it if you can. When you used Interface Builder to construct your view you edited a NIB file, an XML serialization of the objects in the view. Using Interface Builder to create these objects, and to define the relationship between them and your own code, saves you from writing large amounts of boilerplate code that you would otherwise need to manage the view.

If you want to create your view manually, you should override the loadView: method of your view controller class, as this is the method the view controller calls when the view property is requested but is currently set to nil. Don’t override this method if you’ve created your view using the initWithNibName: method, or set the nibName or nibBundle properties. If you’re creating your view manually and you do override this method, however, you must assign the root view you create to the view property of your view controller class:

-(void) viewDidLoad {
    UIView* view = [[UIView alloc] initWithFrame:CGRectMake(0,0,320,480)];
    self.view = view;
    [view release];

Your implementation of this method should not call [super viewDidLoad], as the default implementation of this method will create a plain UIView if no NIB information is present and will make this the main view.

The Delegates and DataSource Pattern

I talked briefly about delegates in Chapter 3. An object that implements a delegate protocol is one that acts on behalf of another object. To receive notification of an event to which it must respond, the delegate class needs to implement the notification method declared as the delegate protocol associated with that event. The protocol may, and usually does, specify a number of methods that the delegate class must implement.

Data sources are similar to delegates, but instead of delegating control, if an object implements a DataSource protocol it must implement one or more methods to supply data to requesting objects. The delegating object, typically something such as a UITableView, will ask the data source what data it should display; for instance, in the case of a table view, what should be displayed in the next UITableViewCell when it scrolls into the current view.

Declaring that a class is a data source or a delegate flags the object for Interface Builder so that you can connect the relevant UI elements to your code. (We’ll be talking about UITableView in Chapter 5.) To declare that AnObject was both a table view data source and a delegate, we would note this in the @interface declaration:

@interface AnObject: UIViewController <UITableViewDataSource,
                                       UITableViewDelegate> {

This would mean that the AnObject object, a UIViewController, is responsible for both populating the table view with data and responding to events the table view generates. Another way to say this is that this object implements both the UITableViewDataSource and the UITableViewDelegate protocols.

At this point, you would use Interface Builder, and we’ll be doing that in the next chapter when we build a table-view-based application to connect the UITableView in our view to the data source and delegate object in our code.

The best content for your career. Discover unlimited learning on demand for around $1/day.