< Previous PageNext Page >

The Cocoa Frameworks

What makes a program a Cocoa program? It’s not really the language, because you can use a variety of languages in Cocoa development. It’s not the development tools, because you could create a Cocoa application from the command line (although that would be a complex, time-consuming task). No, what all Cocoa programs have in common—what makes them distinctive—is that they are composed of objects that inherit ultimately from the root class, NSObject, and that are ultimately based upon the Objective-C runtime. This statement is also true of all Cocoa frameworks.

Note: That statement also needs to be qualified a bit. First, Cocoa supplies another root class, NSProxy; however, NSProxy is rarely used in Cocoa programming. Second, you could create your own root class, but this would be a lot of work (entailing the writing of code that interacts with the Objective-C runtime) and probably not worth your time.

Mac OS X includes several Cocoa frameworks, and Apple and third-party vendors are releasing more frameworks all the time. Despite this abundance of Cocoa frameworks, two of them stand out from all the others. Foundation and Application Kit are the core Cocoa frameworks. You cannot develop a Cocoa application unless you link against (and use the classes of) the Application Kit. And you cannot develop Cocoa software of any type unless you link against and use the classes of the Foundation framework. (Linking against these frameworks happens automatically when you link against the Cocoa umbrella framework). The Foundation and Application Kit frameworks are essential to Cocoa development, and all other frameworks are secondary and elective.

The following sections surveys the features and classes of the two core Cocoa frameworks and briefly describes some of the secondary frameworks. To make these large frameworks more approachable, the introductions to the Foundation and Application Kit frameworks break down the dozens of classes in each hierarchy into functional groupings. Although these groupings have a strong logical basis, one can plausibly group classes in other ways.

In this section:

Foundation
Application Kit
Other Frameworks With Cocoa API


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 Application Kit 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:

Cocoa applications, which by definition link against the Application Kit, 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 Application Kit 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 Paradigms and Policies

Foundation introduces several paradigms and policies to Cocoa programming to ensure consistent behavior and expectations among the objects of a program in certain situations. These include:

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-6, Figure 1-7, and Figure 1-8 depict the logical groups these classes form as well as their inheritance relationships.


Figure 1-6  The Foundation class hierarchy—Objective-C (part one)

The Foundation class hierarchy—Objective-C (part one)


Figure 1-7  Foundation class hierarchy—Objective-C (part two)

Foundation class hierarchy—Objective-C (part two)


Figure 1-8  Foundation class hierarchy—Objective-C (part three)

Foundation class hierarchy—Objective-C (part three)

These diagrams logically group the classes of the Foundation framework in the following categories (with other associations pointed out):

Application Kit

The Application Kit is a framework containing all the objects you need to implement your graphical, event-driven user interface: windows, dialogs, buttons, menus, scrollers, text fields—the list goes on. The Application Kit 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 the Application Kit may seem daunting at first. However, most Application Kit classes are support classes that you use indirectly. You also have the choice at which level you use the Application Kit:

Overview of the Application Kit

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


Figure 1-9  Application Kit class hierarchy—Objective-C (part one)

Application Kit class hierarchy—Objective-C (part one)


Figure 1-10  Application Kit class hierarchy—Objective-C (part two)

Application Kit class hierarchy—Objective-C (part two)

As you can see, the hierarchy tree of the Application Kit 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 the Application Kit 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 Application Kit classes—NSApplication, NSWindow, and NSView—inherit from NSResponder. You can find out more about these responder classes by reading “The Core Application Architecture”.

The second largest branch of classes in the Application Kit 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, the Application Kit 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. See “Control and Cell Architecture” for further information

Controls and cells implement a mechanism that is based on an important design pattern of the Application Kit:. 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 the mouse pointer over 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 the Application Kit 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 the Application Kit, see “Communicating With Objects”. For a discussion of the design patterns on which these paradigms and mechanisms are based, see “Cocoa Design Patterns”.

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

General User-Interface Classes

For the overall functioning of a user interface, the Application Kit provides the following classes:

Text and Fonts

The NSTextField class implements a simple editable text-input field, and the NSTextView class provides more comprehensive editing features for larger text bodies.

NSTextView, a subclass of the abstract NSText class, defines the interface to the extended text system. NSTextView supports rich text, attachments (graphics, file, and other), input management and key binding, and marked text attributes. NSTextView works with the Fonts window and Font menu, rulers and paragraph styles, the Services facility, and the pasteboard (Clipboard). NSTextView also allows customizing through delegation and notifications—you rarely need to subclass NSTextView. You rarely create instances of NSTextView programmatically either, since objects on Interface Builder’s palettes, such as NSTextField, NSForm, and NSScrollView, already contain NSTextView objects.

It is also possible to do more powerful and more creative text manipulation (such as displaying text in a circle) using NSTextStorage, NSLayoutManager, NSTextContainer, and related classes. The Cocoa text system also supports lists, tables, and non-contiguous selections.

The NSFont and NSFontManager classes encapsulate and manage font families, sizes, and variations. The NSFont class defines a single object for each distinct font; for efficiency, these objects, which can represent a lot of data, are shared by all the objects in your application. The NSFontPanel class defines the Fonts window that’s presented to the user.

Graphics and Colors

The classes NSImage and NSImageRep encapsulate graphics data, allowing you to easily and efficiently access images stored in files on the disk and displayed on the screen. NSImageRep subclasses each know how to draw an image from a particular kind of source data. The NSImage class provides multiple representations of the same image, and also provides behaviors such as caching. The imaging and drawing capabilities of Cocoa are integrated with the Core Image framework.

Color is supported by the classes NSColor, NSColorSpace, NSColorPanel, NSColorList, NSColorPicker, and NSColorWell. NSColor and NSColorSpace support a rich set of color formats and representations, including custom ones. The other classes are mostly interface classes: They define and present panels and views that allow the user to select and apply colors. For example, the user can drag colors from the Color window to any color well. The NSColorPicking protocol lets you extend the standard Color window.

The NSGraphicsContext, NSBezierPath, and NSAffineTransform classes help you with vector drawing and support graphical transformations such as scaling, rotation, and translation.

Printing and Faxing

The NSPrinter, NSPrintPanel, NSPageLayout, and NSPrintInfo classes work together to provide the means for printing and faxing the information that your application displays in its windows and views. You can also create a PDF representation of an NSView.

Document and File-System Support

Use the NSFileWrapper class to create objects that correspond to files or directories on disk. NSFileWrapper holds the contents of the file in memory so that it can be displayed, changed, or transmitted to another application. It also provides an icon for dragging the file or representing it as an attachment. Or use the NSFileManager class in the Foundation framework to access and enumerate file and directory contents. The NSOpenPanel and NSSavePanel classes also provide a convenient and familiar user interface to the file system.

The NSDocumentController, NSDocument, and NSWindowController classes define an architecture for creating document-based applications. (The NSWindowController class is shown in the User Interface group of classes in the class hierarchy charts). Such applications can generate identically contained but uniquely composed sets of data that can be stored in files. They have built-in or easily acquired capabilities for saving, opening, reverting, closing, and managing these documents.

Internationalization and Character Input Support

If an application is to be used in more than one part of the world, its resources may need to be customized, or localized, for language, country, or cultural region. For example, an application may need to have separate Japanese, English, French, and German versions of character strings, icons, nib files, or context help. Resource files specific to a particular language are grouped together in a subdirectory of the bundle directory (the directories with the .lproj extension). Usually you set up localization resource files using Interface Builder. See “Nib Files and Other Application Resources” for more information on the Cocoa internationalization facilities.

The NSInputServer and NSInputManager classes, along with the NSTextInput protocol, give your application access to the text input management system. This system interprets keystrokes generated by various international keyboards and delivers the appropriate text characters or Control-key events to text view objects. (Typically the text classes deal with these classes and you won’t have to.)

Operating-System Services

The following Application Kit classes provide operating-system support to your application:

Interface Builder Support

The abstract NSNibConnector class and its two concrete subclasses, NSNibControlConnector and NSNibOutletConnector, represent connections in Interface Builder. NSNibControlConnector manages an action connection in Interface Builder and NSNibOutletConnector manages an outlet connection.

Other Frameworks With Cocoa API

As part of a standard Mac OS X installation, Apple includes (in addition to Foundation and Application Kit) several frameworks that vend Cocoa programmatic interfaces. (They may vend Carbon or other kinds of programmatic interfaces as well.) You can use these secondary frameworks to give your application capabilities that are desirable, if not essential. Some notable secondary frameworks include:



< Previous PageNext Page >


© 2006 Apple Computer, Inc. All Rights Reserved. (Last updated: 2006-12-20)


Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.