Introducing Cocoa

As with all application environments, Cocoa presents two faces; it has a runtime aspect and a development aspect. In its runtime aspect, Cocoa applications present the user interface and are tightly integrated with the other visible components of the operating system; in OS X, these include the Finder, the Dock, and other applications from all environments.

But it is the development aspect that is the more interesting one to programmers. Cocoa is an integrated suite of object-oriented software components—classes—that enables you to rapidly create robust, full-featured OS X and iOS applications. These classes are reusable and adaptable software building blocks; you can use them as-is or extend them for your specific requirements. Cocoa classes exist for just about every conceivable development necessity, from user-interface objects to data formatting. Where a development need hasn’t been anticipated, you can easily create a subclass of an existing class that answers that need.

Cocoa has one of the most distinguished pedigrees of any object-oriented development environment. From its introduction as NeXTSTEP in 1989 to the present day, it has been continually refined and tested (see A Bit of History). Its elegant and powerful design is ideally suited for the rapid development of software of all kinds, not only applications but command-line tools, plug-ins, and various types of bundles. Cocoa gives your application much of its behavior and appearance “for free,” freeing up more of your time to work on those features that are distinctive. (For details on what Cocoa offers, see Features of a Cocoa Application.)

You can use several programming languages when developing Cocoa software, but the essential, required language is Objective-C. Objective-C is a superset of ANSI C that has been extended with certain syntactical and semantic features (derived from Smalltalk) to support object-oriented programming. The few added conventions are easy to learn and use. Because Objective-C rests on a foundation of ANSI C, you can freely intermix straight C code with Objective-C code. Moreover, your code can call functions defined in non-Cocoa programmatic interfaces, such as the BSD library interfaces in /usr/include. You can even mix C++ code with your Cocoa code and link the compiled code into the same executable.

The most important Cocoa class libraries come packaged in two core frameworks for each platform: Foundation and AppKit for OS X, and Foundation and UIKit for iOS. As with all frameworks, these contain not only a dynamically sharable library (or sometimes several versions of libraries required for backward compatibility), but header files, API documentation, and related resources. The pairing of Foundation with AppKit or UIKit reflects the division of the Cocoa programmatic interfaces into those classes that are not related to a graphical user interface and those that are. For each platform, its two core frameworks are essential to any Cocoa project whose end product is an application. Both platforms additionally support the Core Data framework, which is as important and useful as the core frameworks.

OS X also ships with several other frameworks that publish Cocoa programmatic interfaces, such as the WebKit and Address Book frameworks; more Cocoa frameworks will be added to the operating system over time. See The Cocoa Frameworks for further information.

How Cocoa Fits into OS X

Architecturally, OS X is a series of software layers going from the foundation of Darwin to the various application frameworks and the user experience they support. The intervening layers represent the system software largely (but not entirely) contained in the two major umbrella frameworks, Core Services and Application Services. A component at one layer generally has dependencies on the layer beneath it. Figure 1-1 situates Cocoa in this architectural setting.

For example, the system component that is largely responsible for rendering the Aqua user interface, Quartz (implemented in the Core Graphics framework), is part of the Application Services layer. And at the base of the architectural stack is Darwin; everything in OS X, including Cocoa, ultimately depends on Darwin to function.

In OS X, Cocoa has two core Objective-C frameworks that are essential to application development for OS X:

• AppKit. AppKit, one of the application frameworks, provides the objects an application displays in its user interface and defines the structure for application behavior, including event handling and drawing. For a description of AppKit, see AppKit (OS X).

• Foundation. This framework, in the Core Services layer, defines the basic behavior of objects, establishes mechanisms for their management, and provides objects for primitive data types, collections, and operating-system services. Foundation is essentially an object-oriented version of the Core Foundation framework; see Foundation for a discussion of the Foundation framework.

AppKit has close, direct dependences on Foundation, which functionally is in the Core Services layer. If you look closer, at individual, or groups, of Cocoa classes and at particular frameworks, you begin to see where Cocoa either has specific dependencies on other parts of OS X or where it exposes underlying technology with its interfaces. Some major underlying frameworks on which Cocoa depends or which it exposes through its classes and methods are Core Foundation, Carbon Core, Core Graphics (Quartz), and Launch Services:

• Core Foundation. Many classes of the Foundation framework are based on equivalent Core Foundation opaque types. This close relationship is what makes “toll-free bridging”—cast-conversion between compatible Core Foundation and Foundation types—possible. Some of the implementation of Core Foundation, in turn, is based on the BSD part of the Darwin layer.

• Carbon Core. AppKit and Foundation tap into the Carbon Core framework for some of the system services it provides. For example, Carbon Core has the File Manager, which Cocoa uses for conversions between various file-system representations.

• Core Graphics. The Cocoa drawing and imaging classes are (quite naturally) closely based on the Core Graphics framework, which implements Quartz and the window server.

• Launch Services. The NSWorkspace class exposes the underlying capabilities of Launch Services. Cocoa also uses the application-registration feature of Launch Services to get the icons associated with applications and documents.

Apple has carefully designed Cocoa so that some of its programmatic interfaces give access to the capabilities of underlying technologies that applications typically need. But if you require some capability that is not exposed through the programmatic interfaces of Cocoa, or if you need some finer control of what happens in your application, you may be able to use an underlying framework directly. (A prime example is Core Graphics; by calling its functions or those of OpenGL, your code can draw more complex and nuanced images than is possible with the Cocoa drawing methods.) Fortunately, using these lower-level frameworks is not a problem because the programmatic interfaces of most dependent frameworks are written in standard ANSI C, of which Objective-C language is a superset.

How Cocoa Fits into iOS

The application-framework layer of iOS is called Cocoa Touch. Although the iOS infrastructure on which Cocoa Touch depends is similar to that for Cocoa in OS X, there are some significant differences. Compare Figure 1-2, which depicts the architectural setting of iOS, to the diagram in Figure 1-1. The iOS diagram also shows the software supporting its platform as a series of layers going from a Core OS foundation to a set of application frameworks, the most critical (for applications) being the UIKit framework. As in the OS X diagram, the iOS diagram has middle layers consisting of core-services frameworks and graphics and media frameworks and libraries. Here also, a component at one layer often has dependencies on the layer beneath it.

Generally, the system libraries and frameworks of iOS that ultimately support UIKit are a subset of the libraries and frameworks in OS X. For example, there is no Carbon application environment in iOS, there is no command-line access (the BSD environment in Darwin), there are no printing frameworks and services, and QuickTime is absent from the platform. However, because of the nature of the devices supported by iOS, there are some frameworks, both public and private, that are specific to iOS.

The following summarizes some of the frameworks found at each layer of the iOS stack, starting from the foundation layer.

• Core OS. This level contains the kernel, the file system, networking infrastructure, security, power management, and a number of device drivers. It also has the libSystem library, which supports the POSIX/BSD 4.4/C99 API specifications and includes system-level APIs for many services.

• Core Services. The frameworks in this layer provide core services, such as string manipulation, collection management, networking, URL utilities, contact management, and preferences. They also provide services based on hardware features of a device, such as the GPS, compass, accelerometer, and gyroscope. Examples of frameworks in this layer are Core Location, Core Motion, and System Configuration.

  This layer includes both Foundation and Core Foundation, frameworks that provide abstractions for common data types such as strings and collections. The Core Frameworks layer also contains Core Data, a framework for object graph management and object persistence.

• Media. The frameworks and services in this layer depend on the Core Services layer and provide graphical and multimedia services to the Cocoa Touch layer. They include Core Graphics, Core Text, OpenGL ES, Core Animation, AVFoundation, Core Audio, and video playback.

• Cocoa Touch. The frameworks in this layer directly support applications based in iOS. They include frameworks such as Game Kit, Map Kit, and iAd.

The Cocoa Touch layer and the Core Services layer each has an Objective-C framework that is especially important for developing applications for iOS. These are the core Cocoa frameworks in iOS:

• UIKit. This framework provides the objects an application displays in its user interface and defines the structure for application behavior, including event handling and drawing. For a description of UIKit, see UIKit (iOS).

• Foundation. This framework defines the basic behavior of objects, establishes mechanisms for their management, and provides objects for primitive data types, collections, and operating-system services. Foundation is essentially an object-oriented version of the Core Foundation framework; see Foundation for a discussion of the Foundation framework.

As with Cocoa in OS X, the programmatic interfaces of Cocoa in iOS give your applications access to the capabilities of underlying technologies. Usually there is a Foundation or UIKit method or function that can tap into a lower-level framework to do what you want. But, as with Cocoa in OS X, if you require some capability that is not exposed through a Cocoa API, or if you need some finer control of what happens in your application, you may choose to use an underlying framework directly. For example, UIKit uses the WebKit to draw text and publishes some methods for drawing text; however, you may decide to use Core Text to draw text because that gives you the control you need for text layout and font management. Again, using these lower-level frameworks is not a problem because the programmatic interfaces of most dependent frameworks are written in standard ANSI C, of which the Objective-C language is a superset.

Platform SDKs

Beginning with Xcode 3.1 and the introduction of iOS, when you create a software project you must choose a platform SDK. The SDK enables you to build an executable that is targeted for a particular release of OS X or iOS.

The platform SDK contains everything that is required for developing software for a given platform and operating-system release. An OS X SDK consists of frameworks, libraries, header files, and system tools. The SDK for iOS has the same components, but includes a platform-specific compiler and other tools. There is also a separate SDK for iOS Simulator (see The iOS Simulator Application). All SDKs include build settings and project templates appropriate to their platform.

Overview of Development Workflows

Application development differs for OS X and iOS, not only in the tools used but in the development workflow.

In OS X, the typical development workflow is the following:

1. In Xcode, create a project using a template from the OS X SDK.

2. Write code and, using Interface Builder, construct your application’s user interface.

3. Define the targets and executable environment for your project.

4. Test and debug the application using the Xcode debugging facilities.

   As part of debugging, you can check the system logs in the Console window.

5. Measure application performance using one or more of the available performance tools.

For iOS development, the workflow when developing an application is a bit more complex. Before you can develop for iOS, you must register as a developer for the platform. Thereafter, building an application that’s ready to deploy requires that you go through the following steps:

1. Configure the remote device.

   This configuration results in the required tools, frameworks, and other components being installed on the device.

2. In Xcode, create a project using a template from the iOS SDK.

3. Write code, and construct your application’s user interface.

4. Define the targets and executable environment for the project.

5. Build the application (locally).

6. Test and debug the application, either in iOS Simulator or remotely in the device. (If remotely, your debug executable is downloaded to the device.)

   As you debug, you can check the system logs for the device in the Console window.

7. Measure application performance using one or more of the available performance tools.

Xcode

Xcode is the engine that powers Apple’s integrated development environment (IDE) for OS X and iOS. It is also an application that takes care of most project details from inception to deployment. It allows you to:

• Create and manage projects, including specifying platforms, target requirements, dependencies, and build configurations.

• Write source code in editors with features such as syntax coloring and automatic indenting.

• Navigate and search through the components of a project, including header files and documentation.

• Build the project.

• Debug the project locally, in iOS Simulator, or remotely, in a graphical source-level debugger.

Xcode builds projects from source code written in C, C++, Objective-C, and Objective-C++. It generates executables of all types supported in OS X, including command-line tools, frameworks, plug-ins, kernel extensions, bundles, and applications. (For iOS, only application executables are possible.) Xcode permits almost unlimited customization of build and debugging tools, executable packaging (including information property lists and localized bundles), build processes (including copy-file, script-file, and other build phases), and the user interface (including detached and multi-view code editors). Xcode also supports several source-code management systems—namely CVS, Subversion, and Perforce—allowing you to add files to a repository, commit changes, get updated versions, and compare versions.

Figure 1-3 shows an example of a project in Xcode.

Xcode is especially suited for Cocoa development. When you create a project, Xcode sets up your initial development environment using project templates corresponding to Cocoa project types: application, document-based application, Core Data application, tool, bundle, framework, and others. For compiling Cocoa software, Xcode gives you several options:

• GCC—The GNU C compiler (gcc).

• LLVM-GCC—A configuration where GCC is used as the front end for the LLVM (Low Level Virtual Machine) compiler. LLVM offers fast optimization times and high-quality code generation.

  This option is available only for projects built for OS X v10.6 and later.

• Clang—A front end specifically designed for the LLVM compiler. Clang offers fast compile times and excellent diagnostics.

  This option is available only for projects built for OS X v10.6 and later.

For details about these compiler options, see Xcode Build System Guide.

For debugging software, Xcode offers the GNU source-level debugger (gdb) and the Clang Static Analyzer. The Clang Static Analyzer consists of a framework for source-code analysis and a standalone tool that finds bugs in C and Objective-C programs. See http://clang-analyzer.llvm.org/ for more information.

Xcode is well integrated with the other major development application, Interface Builder. See Interface Builder for details.

Interface Builder

The second major development application for Cocoa projects is Interface Builder. As its name suggests, Interface Builder is a graphical tool for creating user interfaces. Interface Builder has been around almost since the inception of Cocoa as NeXTSTEP. Not surprisingly, its integration with Cocoa is airtight.

Interface Builder is centered around four main design elements:

• Nib files. A nib file is a file wrapper (an opaque directory) that contains the objects appearing on a user interface in an archived form. Essentially, the archive is an object graph that contains information about each object, including its size and location, about the connections between objects, and about proxy references for custom classes. When you create and save a user interface in Interface Builder, all information necessary to re-create the interface is stored in the nib file.

  Nib files offer a way to easily localize user interfaces. Interface Builder stores a nib file in a localized directory inside a Cocoa project; when that project is built, the nib file is copied to a corresponding localized directory in the created bundle.

  Interface Builder presents the contents of a nib file in a nib document window (also called a nib file window). The nib document window gives you access to the important objects in a nib file, especially top-level objects such as windows, menus, and controller objects that have no parent in their object graph. (Controller objects mediate between user-interface objects and the model objects that represent application data; they also provide overall management for an application.)

  Figure 1-4 shows a nib file opened in Interface Builder and displayed in a nib document window, along with supporting windows.

  

• Object library. The Library window of Interface Builder contains objects that you can place on a user interface. They range from typical UI objects—for example, windows, controls, menus, text views, and outline views—to controller objects, custom view objects, and framework-specific objects, such as the Image Kit browser view. The Library groups the objects by categories and lets you browse through them and search for specific objects. When an object is dragged from the Library to an interface, Interface Builder instantiates a default instance of that object. You can resize, configure, and connect the object to other objects using the inspector.

• Inspector. Interface Builder has the inspector, a window for configuring the objects of a user interface. The inspector has a number of selectable panes for setting the initial runtime configuration of objects (although size and some attributes can also be set by direct manipulation). The inspector in Figure 1-4 shows the primary attributes for a text field; note that different collapsible sections of the pane reveal attributes at various levels of the inheritance hierarchy (text field, control, and view). In addition to primary attributes and size, the inspector features panes for animation effects, event handlers, and target-action connections between objects; for nib files in OS X projects, there are additional panes for AppleScript and bindings.

• Connections panel. The connections panel is a context-sensitive display that shows the current outlet and action connections for a selected object and lets you manage those connections. To get the connections panel to appear, Control-click the target object. Figure 1-5 shows what the connections panel looks like.

  

Interface Builder uses blue lines that briefly appear to show the compliance of each positioned object, when moved or resized, to the Aqua human interface guidelines. This compliance includes recommended size, alignment, and position relative to other objects on the user interface and to the boundaries of the window.

Interface Builder is tightly integrated with Xcode. It “knows” about the outlets, actions, and bindable properties of your custom classes. When you add, remove, or modify any of these things, Interface Builder detects those changes and updates its presentation of them.

The iOS Simulator Application

For iOS projects, you can select iOS Simulator as the platform SDK for the project. When you build and run the project, Xcode runs Simulator, which presents your application as it would appear on the device (iPhone or iPad) and allows you to manipulate parts of the user interface. You can use Simulator to help you debug the application prior to loading it onto the device.

You should always perform the final phase of debugging on the device. Simulator does not perfectly simulate the device. For example, you must use the mouse pointer instead of finger touches, and so manipulations of the interface requiring multiple fingers are not possible. In addition, Simulator does not use versions of the OpenGL framework that are specific to iOS, and it uses the OS X versions of the Foundation, Core Foundation, and CFNetwork frameworks, as well as the OS X version of libSystem.

More importantly, you should not assume that the performance of your application on Simulator is the same as it would be on the device. Simulator is essentially running your iOS application as a "guest” Mac app. As such, it has a 4 GB memory partition and swap space available to it as it runs on a processor that is more powerful than the one on the device.

Performance Applications and Tools

Although Xcode and Interface Builder are the major tools you use to develop Cocoa applications, there are dozens of other tools at your disposal. Many of these tools are performance applications.

Instruments

Instruments is an application introduced in Xcode 3.0 that lets you run multiple performance-testing tools simultaneously and view the results in a timeline-based graphical presentation. It can show you CPU usage, disk reads and writes, memory statistics, thread activity, garbage collection, network statistics, directory and file usage, and other measurements—individually or in different combinations—in the form of graphs tied to time. This simultaneous presentation of instrumentation data helps you to discover the relationships between what is being measured. It also displays the specific data behind the graphs.

Foundation

The Foundation framework defines a base layer of classes that can be used for any type of Cocoa program. The criterion separating the classes in Foundation from those in the AppKit is the user interface. If an object doesn’t either appear in a user interface or isn’t exclusively used to support a user interface, then its class belongs in Foundation. You can create Cocoa programs that use Foundation and no other framework; examples of these are command-line tools and Internet servers.

The Foundation framework was designed with certain goals in mind:

• Define basic object behavior and introduce consistent conventions for such things as memory management, object mutability, and notifications.

• Support internationalization and localization with (among other things) bundle technology and Unicode strings.

• Support object persistence.

• Support object distribution.

• Provide some measure of operating-system independence to support portability.

• Provide object wrappers or equivalents for programmatic primitives, such as numeric values, strings, and collections. It also provides utility classes for accessing underlying system entities and services, such as ports, threads, and file systems.

Cocoa applications, which by definition link either against the AppKit framework or UIKit framework, invariably must link against the Foundation framework as well. The class hierarchies share the same root class, NSObject, and many if not most of the AppKit and UIKit methods and functions have Foundation objects as parameters or return values. Some Foundation classes may seem designed for applications—NSUndoManager and NSUserDefaults, to name two—but they are included in Foundation because there can be uses for them that do not involve a user interface.

Foundation Classes

The Foundation class hierarchy is rooted in the NSObject class, which (along with the NSObject and NSCopying protocols) define basic object attributes and behavior. For further information on NSObject and basic object behavior, see The Root Class.

The remainder of the Foundation framework consists of several related groups of classes as well as a few individual classes. There are classes representing basic data types such as strings and byte arrays, collection classes for storing other objects, classes representing system information such as dates, and classes representing system entities such as ports, threads, and processes. The class hierarchy charts in Figure 1-7 (for printing purposes, in three parts) depict the logical groups these classes form as well as their inheritance relationships. Classes in blue-shaded areas are present in both the OS X and iOS versions of Foundation; classes in gray-shaded areas are present only in the OS X version.

These diagrams logically group the classes of the Foundation framework in categories (with other associations pointed out). Of particular importance are the classes whose instances are value objects and collections.

Value Objects

Value objects encapsulate values of various primitive types, including strings, numbers (integers and floating-point values), dates, and even structures and pointers. They mediate access to these values and manipulate them in suitable ways. When you compare two value objects of the same class type, it is their encapsulated values that are compared, not their pointer values. Value objects are frequently the attributes of other objects, including custom objects.

Of course, you may choose to use scalars and other primitive values directly in your program—after all, Objective-C is a superset of ANSI C—and in many cases using scalars is a reasonable thing to do. But in other situations, wrapping these values in objects is either advantageous or required. For example, because value objects are objects, you can, at runtime, find out their class type, determine the messages that can be sent to them, and perform other tasks that can be done with objects. The elements of collection objects such as arrays and dictionaries must be objects. And many if not most methods of the Cocoa frameworks that take and return values such as strings, numbers, and dates require that these values be encapsulated in objects. (With string values, in particular, you should always use NSString objects and not C-strings.)

Some classes for value objects have mutable and immutable variants—for example, there are the NSMutableData and NSData classes. The values encapsulated by immutable objects cannot be modified after they are created, whereas the values encapsulated by mutable objects can be modified. (Object Mutability discusses mutable and immutable objects in detail.)

The following are descriptions of what the more important value objects do:

• Instances of the NSValue class encapsulate a single ANSI C or Objective-C data item—for example, scalar types such as floating-point values as well as pointers and structures

• The NSNumber class (a subclass of NSValue) instantiates objects that contain numeric values such as integers, floats, and doubles.

• Instances of the NSData class provides object-oriented storage for streams of bytes (for example, image data). The class has methods for writing data objects to the file system and reading them back.

• The NSDate class, along with the supporting NSTimeZone, NSCalendar, NSDateComponents, and NSLocale classes, provide objects that represent times, dates, calendar, and locales. They offer methods for calculating date and time differences, for displaying dates and times in many formats, and for adjusting times and dates based on location in the world.

• Objects of the NSString class (commonly referred to as strings) are a type of value object that provides object-oriented storage for a sequence of Unicode characters. Methods of NSString can convert between representations of character strings, such as between UTF-8 and a null-terminated array of bytes in a particular encoding. NSString also offers methods for searching, combining, and comparing strings and for manipulating file-system paths. Similar to NSData, NSString includes methods for writing strings to the file system and reading them back.

  The NSString class also has a few associated classes. You can use an instance of the NSScanner utility class to parse numbers and words from an NSString object. NSCharacterSet represents a set of characters that are used by various NSString and NSScanner methods. Attributed strings, which are instances of the NSAttributedString class, manage ranges of characters that have attributes such as font and kerning associated with them.

Formatter objects—that is, objects derived from NSFormatter and its descendent classes—are not themselves value objects, but they perform an important function related to value objects. They convert value objects such as NSDate and NSNumber instances to and from specific string representations, which are typically presented in the user interface.

Collections

Collections are objects that store other objects in a particular ordering scheme for later retrieval. Foundation defines three major collection classes that are common to both iOS and OS X: NSArray, NSDictionary, and NSSet. As with many of the value classes, these collection classes have immutable and mutable variants. For example, once you create an NSArray object that holds a certain number of elements, you cannot add new elements or remove existing ones; for that purpose you need the NSMutableArray class. (To learn about mutable and immutable objects, see Object Mutability.)

Objects of the major collection classes have some common behavioral characteristics and requirements. The items they contain must be objects, but the objects may be of any type. Collection objects, as with value objects, are essential components of property lists and, like all objects, can be archived and distributed. Moreover, collection objects automatically retain—that is, keep a strong reference to—any object they contain. If you remove an object from a mutable collection, it is released, which results in the object being freed if no other object claims it.

The collection classes provide methods to access specific objects they contain. In addition, there are special enumerator objects (instances of NSEnumerator) and language-level support to iterate through collections and access each element in sequence.

The major collection classes are differentiated by the ordering schemes they use:

• Arrays (NSArray) are ordered collections that use zero-based indexing for accessing the elements of the collection.

• Dictionaries (NSDictionary) are collections managing pairs of keys and values; the key is an object that identifies the value, which is also an object. Because of this key-value scheme, the elements in a dictionary are unordered. Within a dictionary, the keys must be unique. Although they are typically string objects, keys can be any object that can be copied.

• Sets (NSSet) are similar to arrays, but they provide unordered storage of their elements instead of ordered storage. In other words, the order of elements in a set is not important. The items in an NSSet object must be distinct from each other; however, an instance of the NSCountedSet class (a subclass of NSMutableSet) may include the same object more than once.

In OS X, the Foundation framework includes several additional collection classes. NSMapTable is a mutable dictionary-like collection class; however, unlike NSDictionary, it can hold pointers as well as objects and it maintains weak references to its contained objects rather than strong references. NSPointerArray is an array that can hold pointers and NULL values and can maintain either strong or weak references to them. The NSHashTable class is modeled after NSSet but it can store pointers to functions and it provides different options, in particular to support weak relationships in a garbage-collected environment.

For more on collection classes and objects, see Collections Programming Topics.

Other Categories of Foundation Classes

The remaining classes of the Foundation framework fall into various categories, as indicated by the diagram in Figure 1-7. The major categories of classes, shown in Figure 1-7, are described here:

• Operating-system services. Many Foundation classes facilitate access of various lower-level services of the operating system and, at the same time, insulate you from operating-system idiosyncrasies. For example, NSProcessInfo lets you query the environment in which an application runs and NSHost yields the names and addresses of host systems on a network. You can use an NSTimer object to send a message to another object at specific intervals, and NSRunLoop lets you manage the input sources of an application or other type of program. NSUserDefaults provides a programmatic interface to a system database of global (per-host) and per-user default values (preferences).

  • File system and URL. NSFileManager provides a consistent interface for file operations such as creating, renaming, deleting, and moving files. NSFileHandle permits file operations at a lower level (for example, seeking within a file). NSBundle finds resources stored in bundles and can dynamically load some of them (for example, nib files and code). You use NSURL and related NSURL... classes to represent, access, and manage URL sources of data.

  • Concurrency. NSThread lets you create multithreaded programs, and various lock classes offer mechanisms for controlling access to process resources by competing threads. You can use NSOperation and NSOperationQueue to perform multiple operations (concurrent or nonconcurrent) in priority and dependence order. With NSTask, your program can fork off a child process to perform work and monitor its progress.

  • Interprocess communication. Most of the classes in this category represent various kinds of system ports, sockets, and name servers and are useful in implementing low-level IPC. NSPipe represents a BSD pipe, a unidirectional communications channel between processes.

  • Networking. The NSNetService and NSNetServiceBrowser classes support the zero-configuration networking architecture called Bonjour. Bonjour is a powerful system for publishing and browsing for services on an IP network.

• Notifications. See the summary of the notification classes in Foundation Paradigms and Policies.

• Archiving and serialization. The classes in this category make object distribution and persistence possible. NSCoder and its subclasses, along with the NSCoding protocol, represent the data an object contains in an architecture-independent way by allowing class information to be stored along with the data. NSKeyedArchiver and NSKeyedUnarchiver offer methods for encoding objects and scalar values and decoding them in a way that is not dependent on the ordering of encoding messages.

• Objective-C language services. NSException and NSAssertionHandler provide an object-oriented way of making assertions and handling exceptions in code. An NSInvocation object is a static representation of an Objective-C message that your program can store and later use to invoke a message in another object; it is used by the undo manager (NSUndoManager) and by the distributed objects system. An NSMethodSignature object records the type information of a method and is used in message forwarding. NSClassDescription is an abstract class for defining and querying the relationships and properties of a class.

• XML processing. Foundation on both platforms has the NSXMLParser class, which is an object-oriented implementation of a streaming parser that enables you to process XML data in an event-driven way.

  Foundation in OS X includes the NSXML classes (so called because the class names begin with “NSXML”). Objects of these classes represent an XML document as a hierarchical tree structure. This approach lets you to query this structure and manipulate its nodes. The NSXML classes support several XML-related technologies and standards, such as XQuery, XPath, XInclude, XSLT, DTD, and XHTML.

• Predicates and expressions. The predicate classes—NSPredicate, NSCompoundPredicate, and NSComparisonPredicate—encapsulate the logical conditions to constrain a fetch or filter object. NSExpression objects represent expressions in a predicate.

The Foundation framework for iOS has a subset of the classes for OS X. The following categories of classes are present only in the OS X version of Foundation:

• Spotlight queries. The NSMetadataItem, NSMetadataQuery and related query classes encapsulate file-system metadata and make it possible to query that metadata.

• Scripting. The classes in this category help to make your program responsive to AppleScript scripts and Apple event commands.

• Distributed objects. You use the distributed object classes for communication between processes on the same computer or on different computers on a network. Two of these classes, NSDistantObject and NSProtocolChecker, have a root class (NSProxy) different from the root class of the rest of Cocoa.

AppKit (OS X)

AppKit is a framework containing all the objects you need to implement your graphical, event-driven user interface in OS X: windows, dialogs, buttons, menus, scrollers, text fields—the list goes on. AppKit handles all the details for you as it efficiently draws on the screen, communicates with hardware devices and screen buffers, clears areas of the screen before drawing, and clips views. The number of classes in AppKit may seem daunting at first. However, most AppKit classes are support classes that you use indirectly. You also have the choice at which level you use AppKit:

• Use Interface Builder to create connections from user-interface objects to your application’s controller objects, which manage the user interface and coordinate the flow of data between the user interface and internal data structures. For this, you might use off-the-shelf controller objects (for Cocoa bindings) or you may need to implement one or more custom controller classes—particularly the action and delegate methods of those classes. For example, you would need to implement a method that is invoked when the user chooses a menu item (unless it has a default implementation that is acceptable).

• Control the user interface programmatically, which requires more familiarity with AppKit classes and protocols. For example, allowing the user to drag an icon from one window to another requires some programming and familiarity with the NSDragging... protocols.

• Implement your own objects by subclassing NSView or other classes. When subclassing NSView, you write your own drawing methods using graphics functions. Subclassing requires a deeper understanding of how AppKit works.

Overview of the AppKit Framework

The AppKit framework consists of more than 125 classes and protocols. All classes ultimately inherit from the Foundation framework’s NSObject class. The diagrams in Figure 1-8 show the inheritance relationships of the AppKit classes.

As you can see, the hierarchy tree of AppKit is broad but fairly shallow; the classes deepest in the hierarchy are a mere five superclasses away from the root class and most classes are much closer than that. Some of the major branches in this hierarchy tree are particularly interesting.

At the root of the largest branch in AppKit is the NSResponder class. This class defines the responder chain, an ordered list of objects that respond to user events. When the user clicks the mouse button or presses a key, an event is generated and passed up the responder chain in search of an object that can respond to it. Any object that handles events must inherit from the NSResponder class. The core AppKit classes—NSApplication, NSWindow, and NSView—inherit from NSResponder.

The second largest branch of classes in AppKit descend from NSCell. The noteworthy thing about this group of classes is that they roughly mirror the classes that inherit from NSControl, which inherits from NSView. For its user-interface objects that respond to user actions, AppKit uses an architecture that divides the labor between control objects and cell objects. The NSControl and NSCell classes, and their subclasses, define a common set of user-interface objects such as buttons, sliders, and browsers that the user can manipulate graphically to control some aspect of your application. Most control objects are associated with one or more cell objects that implement the details of drawing and handling events. For example, a button comprises both an NSButton object and an NSButtonCell object.

Controls and cells implement a mechanism that is based on an important design pattern of the AppKit: the target-action mechanism. A cell can hold information that identifies the message that should be sent to a particular object when the user clicks (or otherwise acts upon) the cell. When a user manipulates a control (by, for example, clicking it), the control extracts the required information from its cell and sends an action message to the target object. Target-action allows you to give meaning to a user action by specifying what the target object and invoked method should be. You typically use Interface Builder to set these targets and actions by Control-dragging from the control object to your application or other object. You can also set targets and actions programmatically.

Another important design pattern–based mechanism of AppKit (and also UIKit) is delegation. Many objects in a user interface, such as text fields and table views, define a delegate. A delegate is an object that acts on behalf of, or in coordination with, the delegating object. It is thus able to impart application-specific logic to the operation of the user interface. For more on delegation, target–action, and other paradigms and mechanisms of AppKit, see Communicating with Objects. For a discussion of the design patterns on which these paradigms and mechanisms are based, see Cocoa Design Patterns.

One of the general features of OS X v10.5 and later system versions is resolution independence: The resolution of the screen is decoupled from the drawing done by code. The system automatically scales content for rendering on the screen. The AppKit classes support resolution independence in their user-interface objects. However, for your own applications to take advantage of resolution independence, you might have to supply images at a higher resolution or make minor adjustments in your drawing code that take the current scaling factor into account.

The following sections briefly describe some of the capabilities and architectural aspects of the AppKit framework and its classes and protocols. It groups classes according to the class hierarchy diagrams shown in Figure 1-8.

UIKit (iOS)

The UIKit framework in iOS is the sister framework of the AppKit framework in OS X. Its purpose is essentially the same: to provide all the classes that an application needs to construct and manage its user interface. However, there are significant differences in how the frameworks realize this purpose.

One of the greatest differences is that, in iOS, the objects that appear in the user interface of a Cocoa application look and behave in a way that is different from the way their counterparts in a Cocoa application running in OS X look and behave. Some common examples are text views, table views, and buttons. In addition, the event-handling and drawing models for Cocoa applications on the two platforms are significantly different. The following sections explain the reasons for these and other differences.

You can add UIKit objects to your application’s user interface in three ways:

• Use the Interface Builder development application to drag windows, views, and other objects from an object library.

• Create, position, and configure framework objects programmatically.

• Implement custom user-interface objects by subclassing UIView or classes that inherit from UIView.

Overview of UIKit Classes

As with AppKit, the classes of the UIKit framework ultimately inherit from NSObject. Figure 1-9 presents the classes of the UIKit framework in their inheritance relationship.

As with AppKit, a base responder class is at the root of the largest branch of UIKit classes. UIResponder also defines the interface and default behavior (if any) for event-handling methods and for the responder chain, which is a chain of objects that are potential event handlers. When the user scrolls a table view with his or her finger or types characters in a virtual keyboard, UIKit generates an event and that event is passed up the responder chain until an object handles it. The corresponding core objects—application (UIApplication), window (UIWindow), and view (UIView)—all directly or indirectly inherit from UIResponder.

Unlike the AppKit, UIKit does not make use of cells. Controls in UIKit—that is, all objects that inherit from UIControl—do not require cells to carry out their primary role: sending action messages to a target object. Yet the way UIKit implements the target-action mechanism is different from the way it is implemented in AppKit. The UIControl class defines a set of event types for controls; if, for example, you want a button (UIButton) to send an action message to a target object, you call UIControl methods to associate the action and target with one or more of the control event types. When one of those events happens, the control sends the action message.

The UIKit framework makes considerable use of delegation, another design pattern of AppKit. Yet the UIKit implementation of delegation is different. Instead of using informal protocols, UIKit uses formal protocols with possibly some protocol methods marked optional.

General User-Interface Classes

Objects on an iOS user interface are visibly different than objects on an OS X user interface. Because of the nature of the device—specifically the smaller screen size and the use of fingers instead of the mouse and keyboard for input—user-interface objects in iOS must typically be larger (to be an adequate target for touches) while at the same time make as efficient use of screen real estate as possible. These objects are sometimes based on visual and tactile analogs of an entirely different sort. As an example, consider the date picker object, which is instantiated from a class that both the UIKit and AppKit frameworks define. In OS X, the date picker looks like this:

This style of date picker has a two tiny areas for incrementing date components, and thus is suited to manipulation by a mouse pointer. Contrast this with the date picker seen in iOS applications:

This style of date picker is more suited for finger touches as an input source; users can swipe a month, day, or year column to spin it to a new value.

As with AppKit classes, many of UIKit classes fall into functional groups:

• Controls. The subclasses of UIControl instantiate objects that let users communicate their intent to an application. In addition to the standard button object (UIButton) and slider object (UISlider), there is a control that simulates off/on switches (UISwitch), a spinning-wheel control for selecting from multidimensional sets of values (UIPickerView), a control for paging through documents (UIPageControl), and other controls.

• Modal views. The two classes inheriting from UIModalView are for displaying messages to users either in the form of “sheets” attached to specific views or windows (UIActionSheet) or as unattached alert dialogs (UIAlertView). On iPad, an application can uses popover views (UIPopoverController) instead of action sheets.

• Scroll views. The UIScrollView class enables instances of its subclasses to respond to touches for scrolling within large views. As users scroll, the scroll view displays transient indicators of position within the document. The subclasses of UIScrollView implement table views, text views, and web views.

• Toolbars, navigation bars, split views, and view controllers. The UIViewController class is a base class for managing a view. A view controller provides methods for creating and observing views, overlaying views, handling view rotation, and responding to low-memory warnings. UIKit includes concrete subclasses of UIViewController for managing toolbars, navigation bars, and image pickers.

  Applications use both toolbars and navigation bars to manage behavior related to the “main” view on the screen; typically, toolbars are placed beneath the main view and navigation bars above it. You use toolbar (UIToolbar) objects to switch between modes or views of an application; you can also use them to display a set of functions that perform some action related to the current main view. You use navigation bars (UINavigationBar) to manage sequences of windows or views in an application and, in effect, to “drill down” a hierarchy of objects defined by the application; the Mail application, for example, uses a navigation bar to navigate from accounts to mailbox folders and from there to individual email messages. On iPad, applications can use a UISplitViewController object to present a master-detail interface.

Comparing AppKit and UIKit Classes

AppKit and UIKit are Cocoa application frameworks that are designed for different platforms, one for OS X and the other for iOS. Because of this affinity, it is not surprising that many of the classes in each framework have similar names; in most cases, the prefix (“NS” versus “UI”) is the only name difference. These similarly named classes fulfill mostly similar roles, but there are differences. These differences can be a matter of scope, of inheritance, or of design. Generally, UIKit classes have fewer methods than their AppKit counterparts.

Table 1-1 describes the differences between the major classes in each framework.

Among the minor classes you can find some differences too. For example, UIKit has the UITextField and UILabel classes, the former for editable text fields and the latter for noneditable text fields used as labels; with the NSTextField class you can create both kinds of text fields simply by setting text-field attributes. Similarly, the NSProgressIndicator class can create objects in styles that correspond to instances of the UIProgressIndicator and UIProgressBar classes.

Core Data

Core Data is a Cocoa framework that provides an infrastructure for managing object graphs, including support for persistent storage in a variety of file formats. Object-graph management includes features such as undo and redo, validation, and ensuring the integrity of object relationships. Object persistence means that Core Data saves model objects to a persistent store and fetches them when required. The persistent store of a Core Data application—that is, the ultimate form in which object data is archived—can range from XML files to SQL databases. Core Data is ideally suited for applications that act as front ends for relational databases, but any Cocoa application can take advantage of its capabilities.

The central concept of Core Data is the managed object. A managed object is simply a model object that is managed by Core Data, but it must be an instance of the NSManagedObject class or a subclass of that class. You describe the managed objects of your Core Data application using a schema called a managed object model. (The Xcode application includes a data modeling tool to assist you in creating these schemas.) A managed object model contains descriptions of an application’s managed objects (also referred to as entities). Each description specifies the attributes of an entity, its relationships with other entities, and metadata such as the names of the entity and the representing class.

In a running Core Data application, an object known as a managed object context is responsible for a graph of managed objects. All managed objects in the graph must be registered with a managed object context. The context allows an application to add objects to the graph and remove them from it. It also tracks changes made to those objects, and thus can provide undo and redo support. When you’re ready to save changes made to managed objects, the managed object context ensures that those objects are in a valid state. When a Core Data application wants to retrieve data from its external data store, it sends a fetch request—an object that specifies a set of criteria—to a managed object context. The managed object context returns the objects from the store that match the request after automatically registering them.

A managed object context also functions as a gateway to an underlying collection of Core Data objects called the persistence stack. The persistence stack mediates between the objects in your application and external data stores. The stack consists of two different types of objects, persistent stores and persistent store coordinators. Persistent stores are at the bottom of the stack. They map between data in an external store—for example, an XML file—and corresponding objects in a managed object context. They don't interact directly with managed object contexts, however. Above a persistence store in the stack is a persistent store coordinator, which presents a facade to one or more managed object contexts so that multiple persistence stores below it appear as a single aggregate store. Figure 1-10 shows the relationships between objects in the Core Data architecture.

Core Data includes the NSPersistentDocument class, a subclass of NSDocument that helps to integrate Core Data and the document architecture. A persistent-document object creates its own persistence stack and managed object context, mapping the document to an external data store. An NSPersistentDocument object provides default implementations of the NSDocument methods for reading and writing document data.

Other Frameworks with a Cocoa API

As part of a standard installation, Apple includes, in addition to the core frameworks for both platforms, several frameworks that vend Cocoa programmatic interfaces. You can use these secondary frameworks to give your application capabilities that are desirable, if not essential. Some notable secondary frameworks include:

• Sync Services—(OS X only) Using Sync Services you can sync existing contacts, calendars and bookmarks schemas as well as your own application data. You can also extend existing schemas. See Sync Services Programming Guide for more information.

• Address Book—This framework implements a centralized database for contact and other personal information. Applications that use the Address Book framework can share this contact information with other applications, including Apple’s Mail and iChat. See Address Book Programming Guide for Mac for more information.

• Preference Panes—(OS X only) With this framework you can create plug-ins that your application dynamically loads to obtain a user interface for recording user preferences, either for the application itself or systemwide. See Preference Pane Programming Guide for more information.

• Screen Saver—(OS X only) The Screen Saver framework helps you create Screen Effects modules, which can be loaded and run via System Preferences. See Screen Saver Framework Reference for more information.

• WebKit—(not public in iOS) The WebKit framework provides a set of core classes to display web content in windows, and by default, implements features such as following links clicked by the user. See WebKit Objective-C Programming Guide for more information.

• iAd—(iOS only) This framework allows your application to earn revenue by displaying advertisements to the user.

• Map Kit—(iOS only) This framework lets an application embed maps into its own windows and views. It also supports map annotation, overlays, and reverse-geocoding lookups.

• Event Kit—(iOS only) With the Event Kit framework, an application can access event information from a user’s Calendar database and enable users to create and edit events for their calendars. The framework also supports efficient fetching of event records, notifications of event changes, and automatic syncing with appropriate calendar databases.

• Core Motion—(iOS only) The Core Motion processes low-level data received from a device’s accelerometer and gyroscope (if available) and presents that to applications for handling.

• Core Location—(iOS only) Core Location lets an application determine the current location or heading associated with a device. With it an application can also define geographic regions and monitor when the user crosses the boundaries of those regions.

• Media Player—(iOS only) This framework enables an application to play movies, music, audio podcasts, and audio book files. It also gives your application access to the iPod library.