iPhone Developers Cookbook (Building Native Applications for the iPhone)

Praise for The iPhone Developer’s Cookbook

“This book would be a bargain at ten times its price! If you are writing iPhone software,
it will save you weeks of development time. Erica has included dozens of crisp and clear
examples illustrating essential iPhone development techniques and many others that
show special effects going way beyond Apple’s official documentation.”
—Tim Burks, iPhone Software Developer,TootSweet Software
“Erica Sadun’s technical expertise lives up to the Addison-Wesley name. The iPhone
Developer’s Cookbook is a comprehensive walkthrough of iPhone development that will
help anyone out, from beginners to more experienced developers. Code samples and
screenshots help punctuate the numerous tips and tricks in this book.”
—Jacqui Cheng,Associate Editor,Ars Technica
“We make our living writing this stuff and yet I am humbled by Erica’s command of her
subject matter and the way she presents the material: pleasantly informal, then very
appropriately detailed technically.This is a going to be the Petzold book for iPhone
developers.”
—Daniel Pasco, Lead Developer and CEO, Black Pixel Luminance
“The iPhone Developer’s Cookbook: Building Applications with the iPhone SDK should be
the first resource for the beginning iPhone programmer, and is the best supplemental
material to Apple’s own documentation.”
—Alex C. Schaefer, Lead Programmer, ApolloIM, iPhone
Application Development Specialist, MeLLmo, Inc
“Erica’s book is a truly great resource for Cocoa Touch developers.This book goes far
beyond the documentation on Apple’s Web site, and she includes methods that give the
developer a deeper understanding of the iPhone OS, by letting them glimpse at what’s
going on behind the scenes on this incredible mobile platform.”
—John Zorko, Sr. Software Engineer, Mobile Devices

The iPhone™
Developer’s
Cookbook

The iPhone™
Developer’s
Cookbook

Building Applications
with the iPhone SDK

Erica Sadun

Upper Saddle River, NJ  Boston  Indianapolis  San Francisco
New York  Toronto  Montreal  London  Munich  Paris  Madrid
Cape Town  Sydney  Tokyo  Singapore  Mexico City
Many of the designations used by manufacturers and sellers to distinguish their
products are claimed as trademarks. Where those designations appear in this book,
and the publisher was aware of a trademark claim, the designations have been printed
with initial capital letters or in all capitals.
The author and publisher have taken care in the preparation of this book, but make
no expressed or implied warranty of any kind and assume no responsibility for errors
or omissions. No liability is assumed for incidental or consequential damages in
connection with or arising out of the use of the information or programs contained
herein.
The publisher offers excellent discounts on this book when ordered in quantity for bulk
purchases or special sales, which may include electronic versions and/or custom
covers and content particular to your business, training goals, marketing focus, and
branding interests. For more information, please contact:
U.S. Corporate and Government Sales
(800) 382-3419
corpsales@pearsontechgroup.com
For sales outside the United States please contact:
International Sales
international@pearsoned.com
AirPort, Apple, the Apple logo, Aqua, Bonjour, Cocoa, Cover Flow, Dashcode, Finder,
FireWire, iMac, iPhone, iPod, iTunes, the iTunes logo, Mac, Mac logo, Macintosh,
Multi-Touch, Objective-C, QuickTime, QuickTime logo, Safari, Spotlight, and Xcode are
trademarks of Apple, Inc., registered in the U.S. and other countries.
Visit us on the Web: informit.com/aw
Library of Congress Cataloging-in-Publication Data:
Sadun, Erica.
The iPhone developer’s cookbook : building mobile applications with the iPhone SDK
/ Erica Sadun.
p. cm.
ISBN-10: 0-321-55545-7 (pbk. : alk. paper)
ISBN-13: 978-0-321-55545-8 (pbk. : alk. paper) 1. iPhone (Smartphone)–
Programming. 2. Computer software–Development. 3. Mobile computing. I. Title.
QA76.8.I64S33 2009
005.26—dc22
2008030294
Copyright © 2009 Pearson Education, Inc.
All rights reserved. Printed in the United States of America. This publication is
protected by copyright, and permission must be obtained from the publisher prior to
any prohibited reproduction, storage in a retrieval system, or transmission in any form
or by any means, electronic, mechanical, photocopying, recording, or likewise. For
information regarding permissions, write to:
Pearson Education, Inc
Rights and Contracts Department
501 Boylston Street, Suite 900
Boston, MA 02116
Fax (617) 671 3447
ISBN-13: 978-0-321-55545-8
ISBN-10: 0-321-55545-7
Text printed in the United States on recycled paper at RR Donnelley in
Crawfordsville, Indiana.
First printing October 2008

Editor-in-Chief
Karen Gettman
Senior Acquisitions
Editor
Chuck Toporek
Senior
Development
Editor
Chris Zahn
Managing Editor
Kristy Hart
Project Editor
Chelsey Marti
Copy Editor
Keith Cline
Indexers
Cheryl Lenser,
Erika Millen
Proofreader
San Dee Phillips
Technical
Reviewers
Tim Burks, Daniel
Pasco, Alex C.
Schaefer
Publishing
Coordinator
Romny French
Cover Designer
Gary Adair
Composition
Nonie Ratcliff
I dedicate this book with love to my husband,Alberto, who
has put up with too many gadgets and too many SDKs
over the years while remaining both kind and patient at
the end of the day.

Contents

Preface xvii
Acknowledgments xxi
About the Author xxii
1 Introducing the iPhone SDK 1
Apple’s iPhone SDK 1
Assembling iPhone Projects 2
iPhone Application Components 4
Application Folder Hierarchy 4
The Executable 4
The Info.plist File 4
The Icon and Default Images 6
XIB (NIB) files 6
Files Not Found in the Application Bundle 7
Sandboxes 7
Platform Limitations 8
Storage Limits 8
Data Access Limits 8
Memory Limits 8
Interaction Limits 9
Energy Limits 9
Application Limits 9
User Behavior Limits 10
SDK Limitations 10
Programming Paradigms 11
Object-Oriented Programming 11
Model-View-Controller 11
Building an iPhone Application Skeleton 18
The Hello World Application 19
The Classes 19
The Code 20
A Note About Sample Code and Memory
Management 20
x Contents
Building Hello World 23
Create an iPhone Project 23
Running the Skeleton 24
Customize the iPhone Project 24
Editing Identification Information 25
Using the Debugger 26
Apple’s iPhone Developer Program 28
Development Phones 28
Application Identifiers 29
From Xcode to Your iPhone: The Organizer Interface 30
Projects and Sources List 30
Devices List 31
Summary Tab 31
Console Tab 31
Crash Logs Tab 31
Screenshot Tab 32
About Tethering 32
Testing Applications on Your iPhone 32
Compiling for Distribution 33
Using Undocumented API Calls 34
Ad Hoc Distribution 35
Summary 36

2 Views 37
UIView and UIWindow 37
Hierarchy 37
Geometry and Traits 39
Gestures 42
Recipe: Adding Stepwise Subviews 42
Reorienting 44
Recipe: Dragging Views 45
UITouch 46
Adding Persistence 48
Recipe: Clipped Views 51
Balancing Touches with Clipping 53
Accessing Pixel-by-Pixel Values 54
xi Contents
Recipe: Detecting Multitouch 56
UIView Animations 59
Building UIView Animation Blocks 59
Recipe: Fading a View In and Out 60
Recipe: Swapping Views 62
Recipe: Flipping Views 64
Recipe: Applying CATransitions to Layers 66
Undocumented Animation Types 67
General Core Animation Calls 68
Recipe: Swiping Views 69
Recipe: Transforming Views 72
Centering Landscape Views 74
Summary 74

3 View Controllers 77
View Management 77
Core Classes 77
Specialized Classes 78
Creating a UIViewController 79
Working with Interface Builder to Build Views for
UIViewControllers 81
Temperature Conversion Example 81
Loading XIB Files Directly 90
Navigation Controllers 91
Setting Up a Navigation Controller 91
Pushing and Popping View Controllers 92
The Navigation Item Class 92
Recipe: Building a Simple Two-Item Menu 93
Recipe: Adding a Segmented Control 95
Recipe: Adding a UIToolbar to a Navigation Bar 97
Recipe: Navigating Between View Controllers 100
Popping Back to the Root 102
Loading a View Controller Array 102
Tab Bars 103
Summary 106
xii Contents

4 Alerting Users 107
Talking Directly to Your User Through Alerts 107
Logging Your Results 108
Building Alerts 109
Displaying the Alert 110
Recipe: Creating Multiline Button Displays 110
Recipe: Autotimed No-Button Alerts 112
Recipe: Soliciting Text Input from the User 113
Recipe: Presenting Simple Menus 115
“Please Wait”: Showing Progress to Your User 117
Recipe: Invoking the Basic Undocumented
UIProgressHUD 117
Recipe: Using UIActivityIndicatorView 119
Recipe: Building a UIProgressView 121
Recipe: Adding Custom, Tappable Overlays 123
Recipe: Building a Scroll-Down Alert 127
Recipe: Adding Status Bar Images 131
Adding Application Badges 132
Recipe: Simple Audio Alerts 134
Vibration 136
Summary 136

5 Basic Tables 139
Introducing UITableView and UITableViewController 139
Creating the Table 140
What the UITableViewController Does 141
Recipe: Creating a Simple List Table 142
Data Source Functions 142
Reusing Cells 143
Font Table Sample 143
Recipe: Creating a Table-Based Selection Sheet 145
Recipe: Loading Images into Table Cells 149
Recipe: Setting a Cell’s Text Traits 151
Removing Cell Selections 152
Recipe: Creating Complex Cells 153
Recipe: Creating Checked Selections 155
xiii Contents
Recipe: Deleting Cells 157
Creating and Displaying Remove Controls 157
Dismissing Remove Controls 158
Handling Delete Requests 158
Swiping Cells 158
Adding Cells 159
Recipe: Reordering Cells 161
Recipe: Working with Disclosures 162
Summary 164

6 Advanced Tables 165
Recipe: Grouping Table Selections 165
Building a Section-Based Data Source 166
Adding Section Headers 170
Recipe: Building a Section Table with an Index 171
Recipe: Custom Cell Backgrounds 172
Customizing the Table View 176
Recipe: Creating Alternate Blue and White Cells 177
Recipe: Framing Tables 179
Recipe: Adding Coupled Cell Controls 180
Recipe: Building a Multiwheel Table 182
Creating the UIPickerView 183
Recipe: Using the UIDatePicker 186
Creating the Date Picker 186
Recipe: Creating Fully Customized Group Tables 189
Creating Grouped Preferences Tables 189
Summary 195

7 Media 197
Recipe: Browsing the Documents Folder
by File Type 197
Locating Documents 198
Loading and Viewing Images 200
Recipe: Displaying Small Images 201
Recipe: Using a UIWebView to Display Images 203
Displaying Web Pages with UIWebView 205
Recipe: Browsing Your Image Library 206
xiv Contents
Recipe: Selecting and Customizing Images from
the Camera Roll 209
Recipe: Snapping Pictures with the iPhone Camera 212
Working with iPhone Audio 214
Recipe: Playing Audio with Celestial 215
Recipe: Using the Media Player for Audio and Video
Playback 217
Recipe: Recording Audio 219
Reading in Text Data 227
Displaying Property Lists 227
Recovering Media from Backup Files 228
Summary 229

8 Controls 231
Recipe: Building Simple Buttons 231
The UIButton class 232
Building Custom Buttons 233
Glass Buttons 236
Recipe: Adding Animated Elements to Buttons 236
Recipe: Animating Button Responses 238
Recipe: Customizing Switches 239
Customizing UIAlertView Buttons 241
Recipe: Adding Custom Slider Thumbs 242
Adding Text to the Slider 246
Recipe: Dismissing a UITextField Keyboard 246
Recipe: Dismissing UITextView Keyboards 248
Recipe: Adding an Undo Button to Text Views 250
Recipe: Creating a Text View–Based HTML Editor 253
Recipe: Building an Interactive Search Bar 255
Recipe: Adding Callout Views 258
Adding a Page Indicator Control 260
Recipe: Customizing Toolbars 263
Toolbar Tips 266
Summary 267

9 People, Places, and Things 269
Address Book Frameworks 269
Address Book UI 269
Address Book 270
xv Contents
Recipe: Accessing Address Book Image Data 271
Recipe: Displaying Address Book Information 273
Recipe: Browsing the Address Book 274
Browsing for (Only) E-Mail Addresses 277
Adding New Contacts 277
Core Location 278
How Core Location Works 278
Recipe: Core Location in a Nutshell 280
Recipe: Reverse Geocoding to an Address 283
Recipe: Accessing Maps Using Core Location Data 286
Recipe: Accessing Core Device Information 288
Recipe: Enabling and Disabling the Proximity
Sensor 289
Recipe: Using Acceleration to Locate “Up” 290
Recipe: Using Acceleration to Move Onscreen
Objects 292
Summary 295

10 Connecting to Services 297
Recipe: Adding Custom Settings Bundles 297
Declaring Application Settings 297
Recipe: Subscribing Applications to Custom URL
Schemes 302
Recipe: Checking Your Network Status 304
Testing the Network Status 304
Recovering a Local IP Address 305
Querying Site IP Addresses 306
Checking Site Availability 307
Recipe: Interacting with iPhone Databases 308
Recipe: Converting XML into Trees 311
Recipe: Storing and Retrieving Keychain Items 313
Storing Multiple Keychain Values 318
Keychain Persistence 319
Sending and Receiving Files 320
Recipe: Building a Simple Web-Based Server 321
Push Notifications 325
Summary 326
xvi Contents

11 One More Thing: Programming Cover Flow 327
The UICoverFlowLayer Class 327
Building a Cover Flow View 329
Building a Cover Flow View Controller 331
Cover Flow Data Source Methods 332
Cover Flow Delegate Methods 333
Summary 336

Index 357
Preface

Few platforms match the iPhone’s unique developer technologies. It combines
OS X-based mobile computing with an innovative multitouch screen, location aware-
ness, an onboard accelerometer, and more.When Apple introduced the iPhone Cocoa
Touch SDK beta in early March 2008, developers responded in numbers that brought
Apple’s servers to its knees.Apple delivered more than one hundred thousand SDK
downloads in less than one week.The iPhone Developer’s Cookbook was written to address
this demand, providing an accessible resource for those new to iPhone programming.

Who This Book Is For
This book is written for new iPhone developers with projects to get done and a new
unfamiliar SDK in their hands.Although each programmer brings different goals and
experiences to the table, most developers end up solving similar tasks in their develop-
ment work:“How do I build a table?”;“How do I create a secure keychain entry?”;
“How do I search the Address Book?”;“How do I move between views?”; and “How do
I use Core Location?”
The iPhone Developer’s Cookbook is aimed squarely at anyone just getting started with
iPhone programming.With its clear, fully documented examples, it will get you up to
speed and working productively. It presents already tested ready-to-use solutions, letting
programmers focus on the specifics of their application rather than on boilerplate tasks.

How This Book Is Structured
This book offers single-task recipes for the most common issues new iPhone developers
face: laying out interface elements, responding to users, accessing local data sources, and
connecting to the Internet.The cookbook approach delivers cut-and-paste convenience.
Programmers can add source recipes into their projects and then customize them to their
needs. Each chapter groups related tasks together. Readers can jump directly to the kind
of solution they’re looking for without having to decide which class or framework best
matches that problem.
Here’s a rundown of what you’ll find in this book’s chapters:

n Chapter 1: Getting Started with the iPhone SDK
Chapter 1 introduces the iPhone SDK and explores the iPhone as a delivery plat-
form, limitations and all. It explains the breakdown of the standard iPhone applica-
tion and enables you to build your first Hello World style samples.
xviii Preface

n Chapter 2: Views
Chapter 2 introduces iPhone views, objects that live on your screen.You see how
to lay out, create, and order your views to create backbones for your iPhone appli-
cations.You read about view hierarchies, geometries, and animations as well as how
users can interact with views through touch.

n Chapter 3: View Controllers
The iPhone paradigm in a nutshell is this: small screen, big virtual worlds. In
Chapter 3, you discover the various UIViewController classes that enable you to
enlarge and order the virtual spaces your users interact with.You learn how to let
these powerful objects perform all the heavy lifting when navigating between
iPhone application screens.

n Chapter 4: Alerting Users
The iPhone offers many ways to provide users with a heads up, from pop-up
dialogs and progress bars to audio pings and status bar updates. Chapter 4 shows
how to build these indications into your applications and expand your user-alert
vocabulary.

n Chapter 5: Basic Tables
Tables provide an interaction class that works particularly well on a small, cramped
device. Many, if not most, apps that ship with the iPhone and iPod touch center
on tables, including Settings,YouTube, Stocks, and Weather. Chapter 5 shows how
iPhone tables work, what kinds of tables are available to you as a developer, and
how you can use table features in your own programs.

n Chapter 6: Advanced Tables
iPhone tables do not begin and end with simple scrolling lists.You can build tables
with titled sections, with multiple scrolling columns, and more.You can add con-
trols such as switches, create translucent cell backgrounds, and include custom
fonts. Chapter 6 starts from where “Basic Tables” left off. It introduces advanced
table recipes for you to use in your iPhone programs.

n Chapter 7: Media
As you’d expect, the iPhone can load and display media from a wide variety of
formats. It does music; it does movies. It handles images and Web pages.You can
present PDF documents and photo albums and more. Chapter 7 shows way after
way that you can import or download data into your program and display that data
using the iPhone’s multitouch interface.

n Chapter 8: Control
The UIControl class provides the basis for many iPhones interactive elements,
including buttons, text fields, sliders, and switches. Chapter 8 introduces controls
and their use, both through well-documented SDK calls and through less-
documented ones.
xix Preface

n Chapter 9: People, Places, and Things
In addition to standard user interface controls and media components that you’d
see on any computer, the iPhone SDK provides a number of tightly focused devel-
oper solutions specific to iPhone and iPod touch delivery. Chapter 9 introduces
the most useful of these, including Address Book access (“people”), core location
(“places”), and sensors (“things”).

n Chapter 10: Connecting to Services
As an Internet-connected device, the iPhone is particularly suited to subscribing to
Web-based services.Apple has lavished the platform with a solid grounding in all
kinds of network computing services and their supporting technologies.The
iPhone SDK handles sockets, password keychains, SQL access, XML processing,
and more. Chapter 10 surveys common techniques for network computing and
offering recipes that simplify day-to-day tasks.

n Chapter 11: One More Thing: Programming Cover Flow
Although Cover Flow is not officially included in the iPhone SDK, it offers one of
the nicest and most beautiful features of the iPhone experience.With Cover Flow,
you can offer your users a gorgeously intense visual selection experience that puts
standard scrolling lists to shame. Chapter 11 introduces Cover Flow and shows
how you can use it in your applications.

Prerequisites
Here are basics you need on hand to begin programming for the iPhone or iPod touch:

n A copy of Apple’s iPhone SDK. Download your copy of the iPhone SDK
from Apple’s iPhone Dev Center (http://developer.apple.com/iphone/).You must
join Apple’s (free) developer program before you download.

n An iPhone or iPod touch. Although Apple supplies a simulator as part of its
SDK, you really do need to have an actual unit to test on if you’re going to develop
any serious software.You’ll be able to use the cable that shipped with your iPhone
or iPod touch to tether your unit to the computer and install the software you’ve
built.

n An Apple iPhone Developer License. You will not be able to test your soft-
ware on an actual iPhone or iPod touch until you join Apple’s iPhone Developer
program (http://developer.apple.com/iphone/program). Members receive a
certificate that allows them to sign their applications and download them to the
platforms in question for testing and debugging.The program costs $99/year for
individuals and companies, $299/year for in-house enterprise development.

n An Intel-based Macintosh running Leopard. The SDK requires a Macintosh
running Leopard OS X 10.5.3 or later.Apple requires an Intel-based computer in
32-bit mode. Many features do not work properly on PPC-based Macs or Intel
Macs in 64-bit mode. Reserve plenty of disk space and at least 1GB of RAM.
xx Contents

n At least one available USB 2.0 port. This enables you to tether your develop-
ment iPhone or iPod touch to your computer for file transfer and testing.

n An Internet connection. This connection enables you to test your programs
with a live WiFi connection as well as with EDGE.

n Familiarity with Objective-C. The SDK is built around Objective-C 2.0.The
language is based on standard C with object-oriented extensions. If you have any
object-oriented and C background, making the move to Objective-C is both
quick and simple. Consult any Objective-C/Cocoa reference book to get up to
speed.
Note
Although the SDK supports development for the iPhone and iPod touch, as well as possible
yet-to-be-announced platforms, this book refers to the target platform as iPhone for the
sake of simplicity. When developing for the touch, most material is applicable. This
excludes certain obvious features such as telephony and onboard speakers. This book
attempts to note such exceptions in the manuscript.

Contacting the Author
If you have any comments or questions about this book, please drop me an e-mail
message at erica@ericasadun.com or stop by www.ericasadun.com. My Web site hosts
many of the applications discussed in this book. Please feel free to visit, download
software, read documentation, and leave your comments.
Acknowledgments

This book would not exist without the efforts of Chuck Toporek, Romny French, Chris
Zahn, and the entire AW production team (specifically Gary Adair, Keith Cline, Kristy
Hart, Cheryl Lenser, Chelsey Marti, Jake McFarland, and Erika Millen).
Thanks go as well to Neil Salkind, my agent of many years, to the tech reviewers
who helped keep this book in the realm of sanity rather than wishful thinking, and to all
my colleagues at TUAW and the Digital Media/Inside iPhone blog.
I am deeply indebted to the wide community of iPhone developers, including Alex
Schaefer, Nick Penree, James Cuff, Jay Freeman, Mark Montecalvo,August Joki, Max
Weisel, Optimo, Kevin Brosius, Planetbeing, Pytey, Roxfan, UnterPerro,Youssef Francis,
Bryan Henry, Daniel Peebles, ChronicProductions, Greg Hartstein, Emanuele Vulcano,
np101137, and Sean Heber, among many others too numerous to name individually.
Their techniques, suggestions, and feedback helped make this book possible.
Special thanks go out to my family and friends, who supported me through month
after month of new beta releases and who patiently put up with my unexplained
absences and frequent howls of despair. I appreciate you all hanging in there with me.
And thanks to my children for their steadfastness, even as they learned that a hunched
back and the sound of clicking keys is a pale substitute for a proper mother.
About the Author

Erica Sadun has written, coauthored, and contributed to about three dozen books
about technology, particularly in the areas of programming, digital video, and digital
photography.An unrepentant geek, Sadun has never met a gadget she didn’t need. Her
checkered past includes run-ins with NeXT, Newton, iPhone, and myriad successful and
unsuccessful technologies.When not writing, she and her geek husband parent three
adorable geeks-in-training, who regard their parents with restrained bemusement.
1

Introducing the iPhone SDK

The iPhone and iPod touch introduce innovative mobile platforms that are a joy to
program.They are the first members of Apple’s new family of pocket-based computing
devices. Despite their diminutive proportions, they run a first-class version of OS X with
a rich and varied SDK that enables you to design, implement, and realize a wide range
of applications. For your projects, you can take advantage of the iPhone’s multitouch
interface and fabulous onboard features using Xcode. In this chapter, you discover how
the SDK is put together and learn to build your first iPhone-based Hello World
applications.

Apple’s iPhone SDK
Are you ready to start programming for the iPhone? You’ll need Apple’s iPhone Software
Developer Kit (SDK), which is free and available to members of Apple’s online (free)
developer program. Download your copy of the iPhone SDK from Apple’s site at
http://developer.apple.com/iphone. It consists of several components that form the
basis of the iPhone development environment.These components include the following
software:

n Xcode. Xcode is the most important tool in the iPhone development
arsenal. It provides a comprehensive project development and management envi-
ronment, complete with source editing, comprehensive documentation, and a
graphical debugger. Xcode is built around several open source GNU tools, namely
gcc (compiler) and gdb (debugger).

n Instruments. Instruments profiles how iPhone applications work under the
hood. It samples memory usage and monitors performance.This lets you identify
and target problem areas in your applications and work on their efficiency.
Instruments offers graphical time-based performance plots that show where your
applications are using the most resources. Instruments is build around the open
source DTrace package developed by Sun Microsystems. Instruments plays a critical
role in tracking down memory leaks and making sure your applications run effi-
ciently on the iPhone platform.
n Dashcode. Dashcode creates stand-alone Web-based applications that run outside
of a traditional browser environment. Conceptually, the iPhone version works just
like the desktop version, complete with layout and debugging tools. Dashboard
provides a Web-based development approach rather than native application compi-
lation and is not covered in this book.

n Simulator. The iPhone Simulator runs on the Macintosh and enables you to create
and test applications on your desktop.You can do this without connecting to an
actual iPhone or iPod touch.The Simulator offers the same API used on the
iPhone and provides a preview of how your concept designs will look.When
working with the Simulator, Xcode compiles Intel x86 code that runs natively on
the Macintosh rather than ARM-based code used on the iPhone.

n Interface Builder. Interface Builder (IB) provides a rapid prototyping tool that
enables you to lay out user interfaces graphically and link to those prebuilt inter-
faces from your Xcode source code.With IB, you draw out your interface using
visual design tools and then connect those onscreen elements to objects and
method calls in your application.
Together, the components of this iPhone SDK suite enable you to develop both tra-
ditional and Web-based applications. From a native application developer’s point of view,
the most important components are Xcode and the Simulator, with Instruments provid-
ing an essential tuning tool. In addition to these tools, there’s an important piece not on
this list.This piece ships with the SDK but is easy to overlook. I refer to Cocoa Touch.
Cocoa Touch is the library of classes provided by Apple for rapid iPhone application
development.This library, which takes the form of a number of framework libraries,
enables you to build graphical event-driven applications using user interface elements
such as windows, text, and tables. Cocoa Touch on the iPhone is analogous to AppKit on
Mac OS X and supports creating rich, reusable interfaces on the iPhone.
Many developers are surprised by the size of iPhone applications; they’re tiny. Cocoa
Touch’s library support is the big reason for this. By letting Cocoa Touch handle all the
heavy UI lifting, your applications can focus on getting their individual tasks done.The
result is compact, focused code that does a single job at a time.

Assembling iPhone Projects
iPhone Xcode projects contain varied standard and custom components. Figure 1-1
shows a typical project. Project elements include source code, linked frameworks, and
media such as image and audio files. Xcode compiles your source, links it to the frame-
works, and builds an application bundle suitable for iPhone installation. It adds your
media to this application bundle, enabling your program to access that media as the
application runs on the iPhone.
iPhone code is normally written in Objective-C 2.0.This is an object-oriented
superset of ANSI C, which was developed from a mix of C and Smalltalk. If you’re
unfamiliar with the language,Apple provides several excellent online tutorials at its

2 Chapter 1 Introducing the iPhone SDK
iPhone developer site.Among these are an introduction to object-oriented programming
with Objective-C and an Objective-C 2.0 reference.These will quickly get you up to
speed with the language.
Frameworks are software libraries provided by Apple that supply the reusable class
definitions for Cocoa Touch.Add frameworks to Xcode by dragging them onto your
project’s Frameworks folder.After including the appropriate header files (such as
UIKit/UIKit.h or QuartzCore/QuartzCore.h), you call their routines from your
program.
Associated media might include audio, image, and video files to be bundled with the
package as well as text-based files that help define your application to the iPhone operat-
ing system. Drop media files into your project and reference them from your code.
The project shown in Figure 1-1 is an especially simple one. It consists of a single
source file (main.m) along with the default iPhone project frameworks (UIKit,
Foundation, and Core Graphics) and a few supporting files (helloworld.png, Default.png,
Icon.png, Info.plist).Together these items form all the materials needed to create a basic
Hello World–style application.
Note
The HelloWorld_Prefix.pch file is created automatically by Xcode. It contains precompiled
header files. NIB and XIB files (.nib, .xib) refer to files created in Interface Builder. These
user interface definition files are linked to your application and called by your app at
runtime.

3 Assembling iPhone Projects

Figure 1-1 Xcode projects bring source code, frameworks, and media
together to form the basis for iPhone applications.
iPhone Application Components
Like their Macintosh cousins, iPhone applications live in application bundles.Application
bundles are just folders named with an .app extension.Your program’s contents and
resources reside in this folder, including the compiled executable, supporting media (such
as images and audio), and a few special files that describe the application to the OS.The
folder is treated by the operating system as a single bundle.

Application Folder Hierarchy
Unlike the Mac, iPhone bundles do not use Contents and Resources folders to store
data or a MacOS folder for the executable.All materials appear at the top level of the
folder. For example, instead of putting a language support .lproj folder into
Contents/Resources/, Xcode places it directly into the top .app folder.You can still use
subfolders to organize your project, but these are ad hoc user-defined folders and do not
follow any standard.
The iPhone SDK’s core OS support includes the NSBundle class.This class makes it
easy to locate your application’s root folder and to navigate down to your custom sub-
folders to point to and load resources.
Note
As on a Macintosh, user domains mirror system ones. Official Apple-distributed applications
reside in the primary /Applications folder. Third-party applications live in /var/mobile/
Applications instead. For the most part, the underlying UNIX file system is obscured by the
iPhone’s sandbox, which is discussed later in this section.

The Executable
The executable file of your application resides at the top-level folder of the application
bundle. It must carry executable permissions to run properly and must be authenticated
by SpringBoard, the iPhone’s version of Finder. Starting with firmware 1.2, which was
released only to developers, SpringBoard instituted a watchdog feature to prevent arbitrary
code execution.This feature put a damper on the use of command-line utilities that you
find on other UNIX platforms. SpringBoard’s watchdog feature also added memory
utilization limits.The system shuts down any process that uses too many system resources.

The Info.plist File
As on a Macintosh, the iPhone application folder contains that all-important Info.plist
file. Info.plist files are XML property lists that describe the application to the operating
system. Property lists store key-value pairs for many different purposes and can be saved
in readable text-based or compressed binary formats. In an Info.plist file, you specify the
application’s executable (CFBundleExecutable) and identifier (CFBundleIdentifier).
This identifier is critical to proper behavior and execution.

4 Chapter 1 Introducing the iPhone SDK
Use the standard Apple domain naming formats (for example, com.sadun.appname) in
your applications by editing your project’s settings in Xcode (see Figure 1-2). Specify
your personal domain and let Xcode append the product identifier.To change identifiers,
right-click your project file in Xcode and choose Get Info from the pop-up. Use the
Search field to find Product_Name and then edit that value as needed.

5 iPhone Application Components

Figure 1-2 Customize your application’s bundle identifier by editing the Info.plist
file. The PRODUCT_NAME identifier is specified in your project’s settings.

The product identifier enables you to communicate with other applications and to
properly register your application with SpringBoard, the “Finder” of the iPhone.
SpringBoard runs the home screen from which you launch your applications.The prod-
uct identifier also forms the basis for the built-in preferences system, the user defaults.
Applications preferences are automatically stored in the user Library (in /var/mobile/
Library/Preferences) using the application’s identifier.This identifier is appended with
the .plist extension (for example, com.sadun.appname.plist), and the preferences are
stored using a binary plist format.You can read a binary plist by transferring it to a
Macintosh. Use Apple’s plutil utility to convert from binary to a text-based XML format:
plutil –convert xml1 plistfile.Apple uses binary plists to lower storage require-
ments and increase system performance.
As with the Macintosh, Info.plist files offer further flexibility and are highly customiz-
able.With them, you can set SpringBoard variables (for example, SBUsesNetwork) or
specify how your icon should display (for example, UIPrerenderedIcon). Some
SpringBoard variables enable you to define multiple roles for a single application.
For example, the Photos and Camera utilities are actually the same application,
MobileSlideShow, playing separate “roles.”You can also specify whether the application is
hidden from view.
Other standard Info.plist keys include UIStatusBarStyle for setting the look and
color of the status bar and UIStatusBarHidden for hiding it altogether.
UIInterfaceOrientation lets you override the accelerometer to create a landscape-
only (UIInterfaceOrientationLandscapeRight) presentation. Register your
custom application URL schemes (for example, myCustomApp://) by setting
CFBundleURLTypes. See Chapter 10,“Connecting to Services,” for more information
about URL schemes.

The Icon and Default Images
Icon.png and Default.png are two key image files. Icon.png acts as your application’s
icon, the image used to represent the application on the SpringBoard home screen.
Default.png (officially known as your “launch image”) provides the splash screen dis-
played during application launch. Unlike Default.png, the icon filename is arbitrary. If
you’d rather not use “icon.png,” set the CFBundleIconFile key in your Info.plist file to
whatever filename you want to use.
Apple recommends matching Default.png to your application’s background. Many
developers use Default.png launch images for a logo splash or for a “Please wait” message.
These go against Apple’s human interface guidelines (launch images should provide visual
continuity, not advertising or excuses for delays) but are perfectly understandable uses.
The “official” application icon size is 57-by-57 pixels. SpringBoard automatically
scales larger art. Provide flat (not glossy) art with squared corners. SpringBoard smoothes
and rounds those corners and adds an automatic gloss and shine effect. If for some com-
pelling reason you need to use prerendered art, set UIPrerenderedIcon to <true/> in
your Info.plist file.
Note
If you plan to submit your application to App Store, you need to create a high-resolution
(512-by-512 pixel) version of your icon. Although you can up sample your 57-by-57 icon.png
art, it won’t look good. Going the other way allows you to maintain high-quality art that you
can compress to your icon as needed.

XIB (NIB) files
Interface Builder creates XIB (also called NIB on the Macintosh) files that store precooked
addressable user interface classes.These files appear at the top level of your application
bundle and are called directly from your program.At the time of this writing, the
Interface Builder filename has not yet stabilized, although the .xib (Xcode Interface
Builder) extension seems to be winning out for iPhone.
Note
When you develop programs that do not use XIB or NIB Interface-Builder bundles, remove
theNSMainNibFile key from Info.plist and discard the automatically generated
MainWindow.xib file from to your project.

6 Chapter 1 Introducing the iPhone SDK
Files Not Found in the Application Bundle
As with the Macintosh, things you do not find inside the application bundle include
preferences files (generally stored in the application sandbox in Library/Preferences),
application plug-ins (stored in /System/Library at this time and not available for general
development), and documents (stored in the sandbox in Documents).
Another thing that seems to be missing (at least from the Macintosh programmer
point of view) is Application Support folders. Copy support data, which more rightfully
would be placed into an Application Support structure, to your Documents or Library
folders.

Sandboxes
The iPhone OS restricts all SDK development to application “sandboxes” for the sake of
security.The iPhone sandbox limits your application’s access to the file system to a mini-
mal set of folders, network resources, and hardware. It’s like attending an overly restric-
tive school with a paranoid principal:

n Your application can play in its own sandbox, but it can’t visit anyone else’s sandbox.

n You cannot share toys.You cannot share data.You cannot mess in the administrative
offices.Your files must stay in the folders provided to you by the sandbox, and you
cannot copy files to or from other application folders.

n Your application owns its own Library, Documents, and /tmp folders.These mimic
the standard folders you’d use on a less-restrictive platform but specifically limits
your ability to write and access this data.
In addition to these limitations, your application must be signed digitally and authen-
ticate itself to the operating system with a coded application identifier, which you must
create at Apple’s developer program site. On the bright side, sandboxing ensures that all
program data gets synced whenever your device is plugged into its home computer. On
the downside, at this time Apple has not clarified how that synced data can be accessed
from a Windows- or Macintosh-based desktop application. (Chapter 7,“Media,” discusses
recovering data from the mdbackup files created by iTunes and its Mobile Devices
framework.)
Note
Sandbox specification files (using the .sb extension) are stored in /var/mobile/Applications
along with the actual sandbox folders. These files control privileges such as read-and-write
access to various bits of the file system. If such a possibility should present itself, do not
edit this file directly. You will render your application unusable. An exemplar sandbox file
usually appears in /usr/share/sandbox.

7 iPhone Application Components
Platform Limitations
When talking about mobile platforms like the iPhone, several concerns always arise, such
as storage, interaction limits, and battery life. Mobile platforms can’t offer the same disk
space their desktop counterparts do.And along with storage limits, constrained interfaces
and energy consumption place very real restrictions on what you as a developer can
accomplish.
With the iPhone, you can’t design for a big screen, for a mouse, for a physical keyboard,
or even for a physical always-on A/C power supply. Instead, platform realities must shape
and guide your development. Fortunately,Apple has done an incredible job designing a
new platform that somehow leverages flexibility from its set of limited storage, limited
interaction controls, and limited battery life.

Storage Limits
The iPhone hosts a powerful yet compact OS X installation.Although the entire iPhone
OS fills no more than a few hundred megabytes of space—almost nothing in today’s cul-
ture of large operating system installations—it provides an extensive framework library.
These frameworks of precompiled routines enable iPhone users to run a diverse range of
compact applications, from telephony to audio playback, from e-mail to Web browsing.
The iPhone provides just enough programming support to create flexible interfaces
while keeping system files trimmed down to fit neatly within tight storage limits.

Data Access Limits
Every iPhone application is sandboxed.That is, it lives in strictly regulated portion of
the file system.Your program cannot access from other applications and from certain
cordoned-off folders including the onboard iTunes library. It can, however, access any data
that is freely available over the Internet when the iPhone is connected to a network.

Memory Limits
On the iPhone, memory management is critical.The iPhone does not support disk-swap-
based virtual memory.When your run out of memory, the iPhone reboots—as Apple puts
it, random reboots are probably not the user experience you were hoping for.With no
swap file, you must carefully manage your memory demands and be prepared for the
iPhone OS to terminate your application if it starts swallowing too much memory at
once.You must also take care as to what resources your applications use.Too many high-
resolution images or audio files can bring your application into the autoterminate zone.
Note
Xcode automatically optimizes your PNG images using the pngcrush utility shipped with
the SDK. (You’ll find the program in the iPhoneOS platform folders in /Developer. Run it
from the command line with the –iphone switch to convert standard PNG files to iPhone-
formatted ones.) For this reason, use PNG images in your iPhone apps where possible as
your preferred image format.

8 Chapter 1 Introducing the iPhone SDK
Interaction Limits
Losing physical input devices and working with a tiny screen doesn’t mean you lose
interaction flexibility.With multitouch, you can build user interfaces that defy the rules.
The iPhone’s touch technology means you can design applications complete with text
input and pointer control using a virtual screen that’s much larger than the actual physical
reality held in your palm.
A smart autocorrecting onscreen keyboard and an accelerometer that detects orienta-
tion provide just two of the key technologies that separate the iPhone from the rest of
the mobile computing pack.What this means, however, is that you need to cut back on
things such as text input and scrolling windows.
Focus your design efforts on easy-to-tap interfaces rather than on desktop-like mimicry.
Remember, you can use just one window at a time—unlike desktop applications that are
free to use multiwindow displays.
Note
The iPhone screen supports up to five touches at a time, although it’s rare to find any
application that uses more than two at once.

Energy Limits
For mobile platforms, you cannot ignore energy limitations.That being said,Apple’s
SDK features help to design your applications to limit CPU use and avoid running
down the battery.A smart use of technology (for example, like properly suspending
programs) lets your applications play nicely on the iPhone and keeps your software from
burning holes in users’ pockets (sometimes almost literally). Some programs when left
running produce such high levels of waste heat that the phone becomes hot to the touch
and the battery quickly runs down.The Camera application is one notable example.

Application Limits
Apple has instituted a strong “one-application-at-a-time” policy.That means as a third-
party developer you cannot develop applications that run in the background like Apple’s
Mail and Phone utilities. Each time your program runs, it must clean up and metaphori-
cally get out of Dodge before passing control on to the next application selected by the
user.You can’t leave a daemon running that checks for new messages or that sends out
periodic updates.An “Open SDK” created by hobbyists exists that bypasses this limitation,
but applications built with those tools cannot be added to and sold through the iPhone
App Store.
On the other hand,Apple does support push data from Web services. Registered services
can push badge numbers and messages to users, letting them know that data is waiting
on those servers.

9 Platform Limitations
Note
According to the iPhone Terms of Service, you may not create external frameworks for your
iPhone application or use Cocoa’s plug-in architecture for applications submitted to the App
Store.

User Behavior Limits
Although it’s not a physical device-based limitation, get used to the fact that iPhone
users approach phone-based applications sporadically.They enter a program, use it quickly,
and then leave just as quickly.The handheld nature of the device means you must design
your applications around short interaction periods and prepare for your application to be
cut off as a user sticks the phone back into a pocket. Save your application state between
sessions and relaunch quickly to approximate the same task your user was performing the
last time the program was run.

SDK Limitations
As you might expect, building applications for the iPhone is similar to building applica-
tions for the Macintosh.You use Objective-C 2.0.You compile by linking to an assort-
ment of frameworks. In other ways, the iPhone SDK is limited. Here are some key
points to keep in mind:

n Garbage Collection is MIA and probably always will be. Apple insiders
suggest that platform limitations simply do not allow for garbage collection to be
implemented in any sane and useful manner.You are responsible for retaining and
releasing objects in memory.

n Many libraries are only partly implemented. Core Animation is partially
available through the Quartz Core framework, but many classes and methods
remain missing in action.The lesson here is that you’re working in early-release
software.Work around the missing pieces and make sure to submit your bug
reports to Apple so that it (we hope) fixes the parts that need to be used. Be aware
that Apple has deliberately cut access to some proprietary classes.

n The public SDK frameworks are not as varied as the private ones. In the
original iPhone open SDK jailbreak world, you used to be able to call on the
iTunes Store frameworks to search the mobile store and the Celestial framework
for easy QuickTime-like audio/video playback.With the debut of the official
SDK, these are no longer publicly available, and Apple has limited third-party
development strictly to a public framework subset.

10 Chapter 1 Introducing the iPhone SDK
Programming Paradigms
iPhone programming centers on two important paradigms: objected-oriented program-
ming and the Model-View-Controller (MVC) design pattern.The iPhone SDK is
designed around supporting these concepts in the programs you build.To do this, it has
introduced delegation (controller) and data source methods (model) and customized
view classes (view). Here is a quick rundown of some important iPhone/Cocoa Touch
design vocabulary used through this book.

Object-Oriented Programming
Objective-C is heavily based on Smalltalk, one of the most historically important object-
oriented languages. Object-oriented programming uses the concepts of encapsulation
and inheritance to build reusable classes with published external interfaces and private
internal implementation.You build your applications out of concrete classes that can be
stacked together like Lego toys, because it’s always made clear which pieces fit together
through class declarations.
Multiple inheritance is an important feature of Objective-C’s approach to object-
oriented programming. iPhone classes can inherit behaviors and data types from more
than one parent.Take the class UITextView, for example. It’s both text and a view. Like
other view classes, it can appear onscreen. It has set boundaries and a given opacity.At
the same time, it inherits text-specific behavior.You can easily change its display font,
color, or text size. Objective-C and Cocoa Touch combine these behaviors into a single
easy-to-use class.

Model-View-Controller
MVC separates the way an onscreen object looks from the way it behaves.An onscreen
button (the view) has no intrinsic meaning. It’s just a button that users can push.That
view’s controller acts as an intermediary. It connects user interactions such as button taps
to targeted methods in your application, which is the model.The application supplies
and stores meaningful data and responds to interactions such as these button taps by
producing some sort of useful result.
Each MVC element works separately.You might swap out a push button with, for
example, a toggle switch without changing your model or controller.The program con-
tinues to work as before, but the GUI now has a different look.Alternatively, you might
leave the interface as is and change your application where a button triggers a different
kind of response in your model. Separating these elements enables you to build main-
tainable program components that can be updated independently.
The MVC paradigm on the iPhone breaks down into the following categories:

n View. View components are provided by children of the UIView class and by its
associated (and somewhat misnamed) UIViewController class.

11 Model-View-Controller
n Controller. The controller behavior is implemented through three key technolo-
gies: delegation, target-action, and notification.

n Model. Model methods supply data through protocols such as data sourcing and
meaning by implementing callback methods triggered by the controller.
Together these three elements form the backbone of the MVC programming para-
digm. Let’s look at each of these elements of the iPhone MVC design pattern in a bit
more detail.The following sections introduce each element and its supporting classes.
View Classes
The iPhone builds its views based on two important classes: UIView and
UIViewController.These two classes are responsible for defining and placing all
onscreen elements.
As views draw things on your screen, UIView represents the most abstract view class.
Nearly all user interface classes descend from UIView and its parent UIResponder.Views
provide all the visual application elements that make up your application. Important
UIView classes include UITextViews,UIImageViews,UIAlertViews, and so forth.The
UIWindow class, a kind of UIView, provides a viewport into your application and provides
the root for your display.
Because of their onscreen nature, all views establish a frame of some sort.This is an
onscreen rectangle that defines the space each view occupies.The rectangle is established
by the view’s origin and extent.
Views are hierarchical and are built with trees of subviews.You can display a view by
setting it as your main window’s content view, or you can add it to another view by
using the addSubview method to assign a child to a parent.You can think about views
as attaching bits of transparent film to a screen, each of which has some kind of drawing
on it.Views added last are the ones you see right away.Views added earlier may be
obscured by other views sitting on top of them.
Despite the name, the UIViewController class does not act strictly as controllers in
the MVC sense.They’re responsible for laying items out on the screen and obscuring
many of the more intricate layout details.Apple terminology does not always match the
MVC paradigm taught in computer science classes.
First and foremost, view controllers are there to make your life easier.They take
responsibility for rotating the display when a user reorients his or her iPhone.They resize
views to fit within the boundaries when using a navigation bar or a toolbar.They handle
all the interface’s fussy bits and hide the complexity involved in directly managing inter-
action elements.You can design and build iPhone applications without ever using a
UIViewController or one of its subclasses, but why bother? The class offers so much
convenience it’s hardly worth writing an application without them.
In addition to the base controller’s orientation and view resizing support, two special
controllers, the UINavigationController and UITabBarController, magically handle
view shifting for you.The navigation version enables you to drill down between views,
smoothly sliding your display between one view and the next. Navigation controllers

12 Chapter 1 Introducing the iPhone SDK
remember which views came first and provide a full breadcrumb trail of “back” buttons
to return to previous views without any additional programming.
The tabbed view controller lets you easily switch between view controller instances
using a tabbed display. So if your application has a top ten list, a game play window, and
a help sheet, you can add a three-buttoned tab bar that instantly switches between these
views without any additional programming to speak of.
Every UIViewController subclass implements its own loadView method.This is
the method that lays out the controller’s subviews and sets up all the triggers, callbacks,
and delegates. So in that sense alone, the UIViewController does act as a controller by
providing these links between the way things look and how interactions are interpreted.
And, because you almost always send the callbacks to the UIViewController itself, it
often acts as your model in addition to its primary role as a controller for whatever
views you create and want to display. It’s not especially MVC, but it is convenient and
easy to program.
Controller
When Apple designs interactive elements such as sliders and tables, they have no idea
how you’ll use them.The classes are deliberately general.With MVC, there’s no pro-
grammatic meaning associated with row selection or button presses. It’s up to you as a
developer to provide the model that adds meaning.The iPhone provides several ways in
which prebuilt Cocoa Touch classes can talk to your custom ones. Here are the three
most important: delegation, target-action, and notifications.
Delegation
Many UIKit classes use delegation to hand off responsibility for responding to user
interactions.When you set an object’s delegate, you tell it to pass along any interaction
messages and let that delegate take responsibility for them. UITableViews are a good
example of this.When a user taps on a table row, the UITableView has no built-in way
of responding to that tap. Instead, it consults its delegate—usually a view controller class
or your main application delegate—and passes along the selection change through a
delegate method.
The UITableView delegate method tableView: didSelectRowAtIndexPath:
is a typical example.Your model takes control of this method and implements how it
should react to the row change.You might display a menu or navigate to a subview or
place a check mark next to the current selection.The response depends entirely on how
you implement the delegated selection change method.
To set an object’s delegate, use some variation on the setDelegate: method.This
instructs your application to redirect interaction callbacks to the delegate.You let Xcode
know that your object implements delegate calls by adding a mention of the delegate
protocol it implements in the class declaration.This appears in angle brackets, to the
right of the class inheritance. Listing 1-1 shows a kind of UIViewController that
implements delegate methods for UITableView views.The MergedTableController
class is, therefore, responsible for implementing all required table delegate methods.

13 Model-View-Controller
Delegation isn’t limited to Apple’s classes. It’s simple to add your own protocol decla-
rations to your classes and use them to define callback vocabularies. Listing 1-1 creates
the FTPHostDelegate protocol, which declares the ftpHost instance variable.When
used, that object must implement all three methods declared in the protocol.
Note
If your application is built around a central table view, use UITableViewController
instances to simplify table creation and use.

Listing 1-1 Defining and Adding Delegate Protocols Declarations to a Class Definition
@protocol FTPHostDelegate <NSObject>
- (void) percentDone: (NSString *) percent;
- (void) downloadDone: (id) sender;
- (void) uploadDone: (id) sender;
@end
@interface MergedTableController : UIViewController <UITableViewDelegate,
UITableViewDataSource>
{
UIView *contentView;
UITableView *subView;
UIButton *button;
id <FTPHostDelegate> *ftpHost;
SEL finishedAction;
} @end

Target-Action
Target-actions are a lower-level way of redirecting user interactions.You’ll encounter
these almost exclusively for children of the UIControl class.With target-action, you tell
the control to contact a given object when a specific user event takes place. For example,
you’d specify which object to contact when users press a button.
Listing 1-2 shows a typical example.This snippet defines a UIBarButtonItem
instance, a typical button-like control used in iPhone toolbars. It sets the item’s target to
self and the action to @selector(setHelvetica:).When tapped, it triggers a call to
the defining object sending the setHelvetica: message.

Listing 1-2 Using Target-Actions for Adding Responses to Controls
UIBarButtonItem *helvItem = [[[UIBarButtonItem alloc]
initWithTitle:@"Helvetica" style:UIBarButtonItemStyleBordered
target:self action:@selector(setHelvetica:)] autorelease];

14 Chapter 1 Introducing the iPhone SDK
As you can see, the name of the method (setHelvetica:) is completely arbitrary.
Target-actions do not rely on an established method vocabulary the way delegates do.
In use, however, they work exactly the same way.The user does something, in this case
presses a button, and the target implements the selector to provide a meaningful
response.
Whichever object defines this UIBarButtonItem instance must implement a
setHelvetica: method. If it does not, the program will crash at runtime with an
undefined method call error.
Standard target-action pairs always pass a single argument, the interaction object. In
this case, this is the UIBarButtonItem instance that was pressed.This self-reference,
where the triggered object is included with the call, enables you to build more general
action code. Instead of building separate methods for setHelvetica:, setGeneva:,
and setCourier:, you could create a single setFontFace: method to update a font
based on which button the user pressed.
To build target-action into your own classes, add a target variable of type id (any
object class) and an action variable of type SEL (method selector).
Notifications
In addition to delegates and target-actions, the iPhone uses yet another way to commu-
nicate about user interactions between your model and your view—and about other
events, for that matter.Notifications enable objects in your application to talk among
themselves, as well as to talk to other applications on your system. By broadcasting infor-
mation, notifications enable objects to send state messages:“I’ve changed,”“I’ve started
doing something,”or “I’ve finished.”
Other objects might be listening to these broadcasts, or they might not. For your
objects to “hear” a notification, they must register with a notification center and start lis-
tening for messages.The iPhone implements at least four kinds of notification centers:

n NSNotificationCenter. This is the gold standard for in-application notification.
You can subscribe to any or all notifications with this kind of notification center
and listen as your objects talk to each other.The notifications are fully implemented
and can carry data as well as the notification name.This name + data implementation
offers great flexibility, and you can use this center to perform complex messaging.

n NSDistributedNotificationCenter. This center is meant for interapplication
notification. It is not fully implemented on the iPhone and should be avoided.

n DarwinNotificationCenter. The iPhone relies on Darwin notification centers
for interapplication messaging. It’s limited in that it enables you to only broadcast
announcements and will not let you send data with those announcements. So you
can announce that something has changed, but you can’t send along information
about which item has changed. Despite this limitation, Darwin notification is reli-
able and robust. Messages arrive dependably. Darwin notification is built using
standard BSD notification (for example, notify_post(),notify_register_
mach_port(), and so on).

15 Model-View-Controller
n TelephonyNotificationCenter. Telephony notifications are private and
unpublished. Unfortunately,Apple did not open up this center, but if you sneak
your way into listening to this special-purpose center, you’ll know when phone
calls and SMS messages arrive.
It’s easy to subscribe to a notification center.Add your application delegate or, more
typically, your UIViewController as a registered observer.You supply an arbitrary selec-
tor to be called when a notification arrives, in this case trackNotifications:.The
method takes one argument, an NSNotification. Ensure that your callback method will
hear all application notifications by setting the name and object arguments to nil.
All notifications contain three data elements: the notification name, an associated
object, and a user information dictionary. If you’re unsure what notifications UIKit
objects in your application produce, have your callback print out the name from all the
notifications it receives—for example, NSLog(@"%@", [notification name]).Apple
does not document notification protocols with the same love and care that it documents
delegate and data source protocols.
The kinds of notification vary by the task you are performing. For example,
notifications when rotating an application include
UIApplicationWillChangeStatusBarOrientationNotification and
UIDeviceOrientationDidChangeNotification. In some cases, these correspond
strongly with existing delegate methods. In other cases, they don’t, so you’d be wise to
monitor notifications while writing programs to find any gaps in Apple’s delegate proto-
col implementations. Here’s how you listen:
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(trackNotifications:) name:nil object:nil];