Chapter 1. Cocoa Touch: The Core iPhone
Cocoa is a collection of tools—libraries, frameworks, and APIs—used to build applications for the Mac OS. Most of the core functionality you would need to develop a rich Mac application is included in Cocoa. There are mechanisms for drawing to display, working with text, saving and opening data files, talking to the operating system, and even talking to other computers across a network. The look and feel of Mac applications is recognizable and relatively consistent in large part because of the breadth and quality of the Cocoa user interface framework.
The Cocoa frameworks include two areas of focus: classes that represent user interface objects and collect user input, and classes that simplify challenges like memory management, networking, filesystem operations, and time management.
Developing applications for the iPhone and iPod Touch is similar in many ways to building applications for Mac OS X. The same tools are used for writing and debugging code, laying out visual interfaces, and profiling performance, but mobile application development requires a supplemental set of software libraries and tools, called the iPhone SDK (software development kit).
Cocoa Touch is a modified version of Cocoa with device-specific libraries for the iPhone and iPod Touch. Cocoa Touch works in conjunction with other layers in the iPhone and iPod Touch operating systems and is the primary focus of this book.
Mac OS X programmers use a framework called
AppKit that supplies all the windows,
buttons, menus, graphics contexts, and event handling mechanisms that have
come to define the OS X experience. The Cocoa Touch equivalent is called
UIKit. In addition to user interface
UIKit provides event handling mechanisms and
handles drawing to the screen.
UIKit is a very rich
framework and is a major focus of user experience programmers. Nearly all
user interface needs are accounted for in
developers can create custom UI elements very easily. Many of the user
experience problems and patterns addressed in this book will focus on
UIKit programming with an emphasis on standard
The second Cocoa Touch framework is the
Foundation framework. You can think of
Foundation as the layer that abstracts many of the
underlying operating system elements such as primitive types, bundle
management, file operations, and networking from the user interface
UIKit. In other words,
Foundation is the gateway to everything not explicitly
part of the user interface. As you’ll see in this book, user experience
programming goes deeper than the user interface controls and includes
things such as latency management, error handling, data caching, and data
The user interface comprises the elements of a device or application that users see, click, and—in the case of Cocoa Touch—tilt, shake, or tap. User interfaces are a big part of user experience. They provide the face of your product, and often a bit more.
For the most part,
UIKit is just a limited
subset of the
AppKit framework for Mac OS X. If you
have experience developing Cocoa apps for the Mac, you will get your
UIKit fairly quickly. The main
differences are that
UIKit is tuned for specific
hardware interfaces and that it provides less functionality than
AppKit. The reduced scope of
is primarily due to the differences in robustness between typical
computers and the iPhone or iPod Touch. Despite the omission of a few
UIKit is a very capable
The core class from which all Cocoa objects inherit basic behavior is
prefix has roots in the non-Apple origins of Cocoa at NeXT. The early
versions of what is now Cocoa were called NextStep. Most Cocoa classes
in Cocoa are subclasses of
NSObject, and many classes
NSObject is the foundation of objects
being passed around. For example, the class
NSArray, which represents a collection
of pointers, requires that any pointer it stores points to an
NSObject subclass. In most cases, any custom class
you create should inherit from
The names of classes in Cocoa are often very descriptive. The
following illustrations give an overview of the classes in
UIKit. The purpose is to provide a view of the entire
collection of classes so that developers of all experience levels can
see the breadth of the frameworks.
UIKit, all classes that respond to user
input inherit from
UIResponder, which is an
NSObject subclass that provides functionality around
handling user input. Figure 1-1 focuses on the
In addition to the
includes a set of classes acting as value objects, logical controllers,
and abstractions of hardware features. Figure 1-2 shows these classes.
The documentation sets that accompany the iPhone SDK, in tandem with the Apple Developer Connection website, cover all the details of the Cocoa and Cocoa Touch framework classes. This book will further elaborate on key classes in the context of interaction design patterns and overall user experience, but the official documentation should remain the primary reference for developers, as each update to the iPhone SDK includes amended or edited documentation packages.
Foundation layer of Cocoa Touch (and Cocoa on the Mac) provides an
object-oriented abstraction to the core elements of the operating
Foundation handles core features of Cocoa
Essential object behavior, such as memory management mechanisms
Inter-object notification mechanisms, such as event dispatching
Access to resource bundles (files bundled with your application)
Internationalization and localization of resources, such as text strings and images
Data management tools (SQLite, filesystem access)
Object wrappers of primitive types, such as
All Cocoa Touch applications must link against
contains the classes that make a Cocoa application work—including many
classes that are integral in the functioning of the user interface
framework. For example, many
UIKit methods use
NSString objects as arguments or return values from
Foundation class tree as supported by Cocoa
Touch is illustrated in Figures 1-3 to 1-9. The class hierarchy diagrams are logically grouped
according to coarse functionality. This conceptual grouping mirrors the
organization used by Apple in the Cocoa Fundamentals
Guide included in the developer documentation. You should
consult the Cocoa Fundamentals Guide and the
class documentation provided by Apple as part of the iPhone SDK install
for updated, in-depth information about the framework classes.
Figure 1-3 shows a subset of
NSObject subclasses that represent value objects.
Value objects are used to represent non-functional
values—primitives, dates, generic binary data—and to provide utility
methods for those values.
Figure 1-4 maps the
NSObject subclasses that focus on XML and string management. The XML classes are particularly useful
when working with web services. Strings are used constantly, and Cocoa
developers spend a lot of time working with
Foundation provides powerful classes for
collection management. These classes are shown in Figure 1-5. Standard collection types such as arrays,
sets, and hash tables are included, along with classes used for
enumerating through collections.
Figure 1-6 illustrates classes that focus on operating system services, file operations, and inter-process communication (IPC).
Figure 1-7 illustrates the portion of
Foundation that provides for URL handling functionality. Hybrid web/Cocoa applications
use URL handling classes heavily.
Figure 1-8 shows the classes used to manage threading in Cocoa applications. Careful thread management can be an important part of optimizing the perception of responsiveness in an application.
Finally, Figure 1-9 shows classes providing notifications, archiving, and core language features such as exceptions.
One notable difference between the iPhone OS and Mac OS X is that
the implementation of
Foundation for Cocoa Touch does
not automatically recover memory when objects are destroyed. This means developers must keep track of the objects they
create and follow certain idioms in order to keep memory usage as low as
The newest version of the Objective-C programming language, version 2.0, added support for automatic resource management, or garbage collection. Developers who have grown accustomed to using garbage collection in Cocoa applications on the Mac may find its omission in the iPhone SDK inconvenient. The performance implications of most garbage collection implementations are important considerations on mobile devices, and this is a key reason it was excluded from the iPhone. Battery life and processing speed are important elements of an elegant user experience, and often act as differentiating factors among competing devices in the consumer marketplace.
The screen on both the iPhone and iPod Touch is an LCD-lit 3.5-inch (diagonal) widescreen Multi-Touch display. The screen resolution is 480×320 pixels at a resolution of 163 pixels per inch. The devices include the following sensors: accelerometer, proximity sensor, and ambient light sensor.
Both the iPhone and iPod Touch devices provide rocker switches for controlling volume, a hardware power button, and a depressible “home” button. These concrete interfaces are outside the scope of Cocoa Touch programming, but are notable in the overall UX (user experience) of the devices.
From the point of view of user experience programmers, the hardware interface elements are separate from the touch interface. Apple doesn’t provide any means of accessing the home button, lock button, volume controls, or the navigation controls included on headsets. This simplifies the domain of UX programming, but comes at a cost: there are certainly cases in which access to the home button or volume rocker could provide enhanced functionality to users.
The iPhone provides a few distinct advantageous features over the iPod Touch, aside from the telephony. For example, the iPhone includes GPS support and a hardware ringer/silence switch. For networking, in addition to 802.11g support, the iPhone 3G includes support for 3G wireless networking, and support for High-Speed Downlink Packet Access (HSDPA). The operating system will, unless told otherwise, automatically switch from 3G to wireless networks with known names. This feature is part of a larger UX pattern that is core to the iPhone: attempting to deliver the best experience possible given the environment, without interruption. We will cover this pattern in Chapter 8.