Cocoa is an application environment for both the Mac OS X operating system and iPhone OS, the operating system used on multi-touch devices such as iPhone and iPod touch. It consists of a suite of object-oriented software libraries, a runtime, and an integrated development environment
The Cocoa Environment
Cocoa is a set of object-oriented frameworks that provides a runtime environment for applications running on Mac OS X and iPhone OS. It is also part of a development environment that helps you efficiently bring these applications from design stage to deployment. Cocoa is the preeminent application environment for Mac OS X and the only application environment for iPhone OS. (Carbon is an alternative environment on Mac
OS X, but it is a compatibility framework with procedural programmatic interface intended to support existing Mac OS X code bases.) Most of the applications you see on Mac OS X and iPhone OS, including Mail and Safari, are Cocoa applications. An integrated development environment called Xcode supports application development for both platforms. The combination of this development environment and Cocoa makes it easy to create a well-factored, full-featured application.
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 inter face and are tightly integrated with the other visible portions of the operating system; on Mac 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 Mac OS X 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-inter face objects to data formatting, and where a need hasn’t been anticipated, you can easily create a subclass of an existing class that answers that need.
Cocoa history
Cocoa is the continuation of several frameworks (primarily the App Kit and Foundation Kit) from the NeXTSTEP and OPENSTEP programming environments developed by NeXT in the 1980s and 1990s. Apple acquired NeXT in December 1996, and subsequently went to work on the Rhapsody operating system that was supposed to be the direct successor of OPENSTEP. It was to have had an emulation base for Mac OS applications, called Blue Box. The OPENSTEP base of libraries and binary support was termed Yellow Box. Rhapsody evolved into Mac OS X, and the Yellow Box became Cocoa. As a result, Cocoa classes begin with the acronym "NS" (standing either for the NeXT-Sun creation of OPENSTEP, or for the
original proprietary term for the OPENSTEP framework, NeXTSTEP): NSString, NSArray, etc. Much of the work that went into developing OPENSTEP was applied to the development of Mac OS X, Cocoa being the most visible part. There are, however, some differences. For example, NeXTSTEP and OPENSTEP used Display PostScript for on-screen display of text and graphics, while Cocoa depends on Apple's Quartz (which uses the PDF imaging model). Cocoa also has a level of Internet support, including the NSURL and WebKit HTML classes, and others, while under OPENSTEP there was only rudimentary support for managed network connections through NSFileHandle classes and Berkeley sockets.
Prior to its current use, the "Cocoa" trademark was the name of an application that allowed children to create multimedia projects. It was originally known as KidSim, and is now licensed to a third party and marketed as Stagecast Creator. The program was discontinued in one of the rationalizations that followed Steve Jobs' return to Apple. The name was re-used to avoid the delay while registering a new trademark, with Stagecast agreeing to market the older Cocoa under a new name.
How Cocoa Fits into Mac OS X
Figure1-1shows a simplified diagram of the Mac OS X system architecture.
Figure1-1 Mac OS X architecture—simplified perspective
This diagram is simple for a purpose: to depict unambiguously to those unfamiliar with Mac OS X some of its major components and dependencies. But in its simplicity it omits important details and blurs others. These details fill in an important part of the picture showing how Cocoa fits into the rest of Mac OS X.
Figure 1-2 situates Cocoa more accurately in an architectural setting. This diagram shows Mac OS X as a series of software layers going from the foundation of Darwin to the various application environments; the intervening layers represent the system software contained in the two major umbrella frameworks, Core Services and Application Services. The diagram suggests that a component at one layer generally has dependencies on the layer beneath it.
Figure1-2 Cocoa in the architecture of Mac OSX
Features of a Cocoa Application
It is possible to create a Cocoa application without adding a single line of code. Make a new Cocoa application project using Xcode and then build the project. That’s it. Of course, this application won’t do much, or at least much that’s interesting. But this extremely simple application still launches when double-clicked, displays its icon in the Dock, displays its main menu and window (entitled “Window”), hides itself on command, behaves nicely with other running applications, and quits on command. You can move, resize, minimize, and close the window. You can even print the emptiness contained by the window.
· Basic application framework—Cocoa provides the infrastructure for event-driven behavior and for application-, window-, and workspace-management. In most cases, you won’t have to handle events directly or send any drawing commands to a rendering library.
· User-interface objects—Cocoa offers a rich collection of ready-made objects for your application’s user interface. Most of these objects are available on palettes of Interface Builder, a development application for creating user interfaces; you simply drag an object from a palette onto the surface of your interface, configure its attributes, and connect it to other objects. (And, of course, you can always instantiate, configure, and connect these objects programmatically.) Here is a sampling of Cocoa user-interface objects:.
In addition, Cocoa features technologies that support user interfaces, including those that promote accessibility, perform validation, and facilitate the connections between objects in the user interface and custom objects.
· Drawing and imaging—Cocoa enables efficient drawing of custom views with a framework for locking graphical focus and marking views (or portions of views) as “dirty.” It includes programmatic tools for drawing Bezier paths, performing affine transforms, compositing images, and creating various representations of images.
· System interaction—Cocoa gives your application ways to interact with (and use the services of) the file system, the workspace, and other applications.
· Data exchange—Cocoa simplifies the exchange of data within an application and between applications using the copy-paste and drag-and-drop models and through the Services menu.
· Performance—To enhance the performance of your application, Cocoa provides programmatic support for multithreading, idle-time processing, lazy loading of resources, memory management, and run-loop manipulation.
· Document-based applications—Cocoa specifies an architecture for applications composed of a potentially unlimited number of documents, with each contained in its own window (a word processor, for example). Indeed, if you choose the “Document-based application” project type, many of the components of this sort of application are created for you.
· Scripting—Through application scriptability information and a suite of supporting Cocoa classes, you can make your application scriptable; that is, it can respond to commands emitted by AppleScript scripts. Applications can also execute scripts or use individual Apple events to send commands to, and receive data from, other applications. As a result, every scriptable application can supply services to both users and other applications.
· Internationalization—Cocoa uses an approach to internationalization and localization that has been refined over many years. This approach, based on users’ lists of preferred languages, puts localized resources in bundles of the application. It also provides tools and programmatic interfaces for generating and accessing localized strings. Moreover, text manipulation in Cocoa is based on Unicode by default, and is thus an asset for internationalization.
· Undo management—You can register user actions that occur with an undo manager, and it will take care of undoing them (and redoing them) when users choose the appropriate menu items. The manager maintains undo and redo operations on separate stacks.
· Text—Cocoa provides a sophisticated text system that allows you to do things with text ranging from the simple (for example, displaying a text view with editable text) to the more complex, such as control of kerning and ligatures, spell checking, and embedding images.
· Printing—In a fashion similar to the text system, the printing architecture lets you print documents and other application content along a range of control and sophistication. At the simplest level, you can print the contents of any view by default. At a more complicated level, you can define the content and format of printed content, control how a print job is performed, and add an accessory view to the print panel.
· Preferences—The user defaults system is based on a system-wide database in which you can store global and application-specific preferences.
· Networking—Cocoa includes a Distributed Objects architecture that allows one Cocoa process to communicate with another process on the same computer or on a different one. It also offers programmatic interfaces for incorporating Bonjour capabilities in your application.
· Multimedia—Cocoa provides support for QuickTime video and basic audio capabilities.
CHAPTER 2: COCOA FRAMEWORKS
What makes a program a Cocoa program? It’s not re
ally 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.
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.
2.1 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:
· Object retention and object disposal. The Objective-C runtime and Foundation give Cocoa programs two ways to ensure that objects persist when they’re needed and are freed when they are no longer needed. Garbage collection, which was introduced in Objective-C 2.0, automatically tracks and disposes of objects that your program no longer needs, thus freeing up memory. Foundation also still offers the traditional approach of memory management. It institutes a policy of object ownership that specifies that objects are responsible for releasing other objects that they have created, copied, or explicitly retained. NSObject (class and protocol) defines methods for retaining and releasing objects. Autorelease pools (defined in the NSAutoreleasePool class) implement a delayed-release mechanism and enable Cocoa programs to have a consistent convention for returning objects for which the caller is not responsible.
· Mutable class variants. Many value and container classes in Foundation have a mutable variant of an immutable class, with the mutable class always being a subclass of the immutable one. If you need to dynamically change the encapsulated value or membership of such an object, you create an instance of the mutable class. Because it inherits from the immutable class, you can pass the mutable instance in methods that take the immutable type.
· Class clusters. A class cluster is an abstract class and a set of private concrete subclasses for which the abstract class acts as an umbrella interface. Depending on the context (particularly the method you use to create an object), an instance of the appropriate optimized class is returned to you. NSString and NSMutableString, for example, act as brokers for instances of various private subclasses optimized for different kinds of storage needs. Over the years the set of concrete classes has changed several times without breaking applications.
· Notifications. Notification is a major design pattern in Cocoa. It is based on a broadcast mechanism that allows objects (called observers) to be kept informed of what another object is doing or is encountering in the way of user or system events. The object originating the notification can be unaware of the existence or identity of the observers of the notification. There are several types of notifications: synchronous, asynchronous, and distributed. The NSNotification, NSNotificationCenter, NSNotificationQueue, and NSDistributedNotificationCenter classes implement the Foundation notification mechanism.
2.2 Foundation Classes
The Foundation class hierarchy is rooted in the NSObject classes, which (along with the NSObject and NSCopying protocols) define basic object attributes and behavior. 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-8 (for printing purposes, in three parts) depict the logical groups these classes form as well as their inheritance relationships.
These diagrams logically group the classes of the Foundation framework in the following categories (with other associations pointed out):
· Value objects. Value objects encapsulate data of various types, giving access to the data and offering various manipulations of it. Because they are objects, they (and their contained values) can be archived and distributed. NSData provides object-oriented storage for streams of bytes whereas NSValue and NSNumber provide object-oriented storage for arrays of simple scalar values. The NSDate, NSCalendarDate, 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.
· Strings. NSString is another type of value object that provides object-oriented storage for a null-terminated array of bytes in a particular encoding. It includes support for converting string encodings among UTF-16, UTF-8, MacRoman, and many other encodings. NSString also offers methods for searching, combining, and comparing strings and for manipulating file-system paths. You can use an NSScanner object to parse numbers and words from an NSString object. NSCharacterSet (shown as a collection class in the diagram) represents a set of characters that are used by various NSString and NSScanner methods.
· Collections. Collections are objects that store and vend other (usually value) objects in a particular ordering scheme. NSArray uses zero-based indexing, NSDictionary uses key-value pairs, and NSSet provides unordered storage of objects (NSCountedSet “uniques” the collection). With an NSEnumerator object, you can access in sequence the elements of a collection. Collection objects are essential components of property lists and, like all objects, can be archived and distributed.
· 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 NSURLHandle to represent, access, and manage URL sources of data.
§ 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.
§ Multithreading, operations, and subtasks. 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.
· 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.
· Expressions and predicates . 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.
· Spotlight queries . The NSMetadataItem, NSMetadataQuery and related query classes encapsulate file-system metadata and make it possible to query that metadata.
· 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.
· 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.
· 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.
2.3 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:
· 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 Application Kit 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 the Application Kit works.
2.4 General User-Interface Classes
For the overall functioning of a user interface, the Application Kit provides the following classes:
· The global application object. Every application uses a singleton instance of NSApplication to control the main event loop, keep track of the application’s windows and menus, distribute events to the appropriate objects (that is, itself or one of its windows), set up top-level autorelease pools, and receive notification of application-level events. An NSApplication object has a delegate (an object that you assign) that is notified when the application starts or terminates, is hidden or activated, should open a file selected by the user, and so forth. By setting the NSApplication object’s delegate and implementing the delegate methods, you customize the behavior of your application without having to subclass NSApplication.
· Windows and views. The window and view classes, NSWindow and NSView, also inherit from NSResponder, and so are designed to respond to user actions. An NSApplication object maintains a list of NSWindow objects—one for each window belonging to the application—and each NSWindow object maintains a hierarchy of NSView objects. The view hierarchy is used for drawing and handling events within a window. An NSWindow object handles window-level events, distributes other events to its views, and provides a drawing area for its views. An NSWindow object also has a delegate allowing you to customize its behavior. Beginning with Mac OS X version 10.5, the window and view classes of the Application Kit support enhanced animation features.
NSView is the superclass for all objects displayed in a window. All subclasses implement a drawing method using graphics functions; drawRect: is the primary method you override when creating a new NSView.
.
· Panels (dialogs). The NSPanel class is a subclass of NSWindow that you use to display transient, global, or pressing information. For example, you would use an instance of NSPanel, rather than an instance of NSWindow, to display error messages or to query the user for a response to remarkable or unusual circumstances. The Application Kit implements some common dialogs for you such as the Save, Open and Print dialogs, used to save, open, and print documents. Using these dialogs gives the user a consistent look and feel across applications for common operations.
· Menus and cursors. The NSMenu, NSMenuItem, and NSCursor classes define the look and behavior of the menus and cursors that your application displays to the user.
· Grouping and scrolling views. The NSBox, NSScrollView, and NSSplitView classes provide graphic “accessories” to other view objects or collections of views in windows. With the NSBox class, you can group elements in windows and draw a border around the entire group. The NSSplitView class lets you append views vertically or horizontally, apportioning to each view some amount of a common territory; a sliding control bar lets the user redistribute the territory among views. The NSScrollView class and its helper class, NSClipView, provide a scrolling mechanism as well as the graphic objects that let the user initiate and control a scroll. The NSRulerView class allows you to add a ruler and markers to a scroll view.
· Table views and outline views. The NSTableView class displays data in rows and columns. NSTableView is ideal for, but not limited to, displaying database records, where rows correspond to each record and columns contain record attributes. The user can edit individual cells and rearrange the columns. You control the behavior and content of an NSTableView object by setting its delegate and data source objects. Outline views (instances of NSOutlineView, a subclass of NSTableView) offer another approach to displaying tabular data. With the NSBrowser class you can create an object with which users can display and navigate hierarchical data.
2.5 Text and Fonts
The Cocoa text system is based on the Core Text framework, which was introduced in Mac OS X version 10.5. The Core Text framework provides a modern, low-level, high-performance technology for laying out text. If you use the Cocoa text system, you should rarely have reason to use Core Text directly.
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.
2.6 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.
2.7 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.
2.9 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.
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.)
2.10 Operating-System Services
The following Application Kit classes provide operating-system support to your application:
· Sharing data with other applications. The NSPasteboard class defines the pasteboard, a repository for data that’s copied from your application, making this data available to any application that cares to use it. NSPasteboard implements the familiar cut-copy-paste operation. The NSServicesRequest protocol uses the pasteboard to communicate data that’s passed between applications by a registered service. (The pasteboard is implemented as the Clipboard in the user interface.)
· Dragging. With very little programming on your part, custom view objects can be dragged and dropped anywhere. Objects become part of this dragging mechanism by conforming to NSDragging... protocols; draggable objects conform to the NSDraggingSource protocol, and destination objects (receivers of a drop) conform to the NSDraggingDestination protocol. The Application Kit hides all the details of tracking the cursor and displaying the dragged image.
· Spell checking. The NSSpellServer class lets you define a spell-checking service and provide it as a service to other applications. To connect your application to a spell-checking service, you use the NSSpellChecker class. The NSIgnoreMisspelledWords and NSChangeSpelling protocols support the spell-checking mechanism.
2.11 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.
CHAPTER 3: ADDING BEHAVIOUR TO A COCOA PROGRAM
3.1 Starting Up
Using a framework of Objective-C classes and their methods differs from using a library of C functions. In the latter case, you can pretty much pick and choose which functions to use and when to use them, depending on the program you’re trying to write. But a framework, on the other hand, imposes a design on your program, or at least on a certain problem space your program is trying to address. With a procedural program, you call library functions as necessary to get the work of the program done. Using an object-oriented framework is similar in that you must invoke methods of the framework to do much of the work of the program.
What Happens in the main Function
Objective-C programs begin executing where C programs do, in the main function. In a complex Objective-C program, the job of main is fairly simple. It consists of two steps:
1. Set up a core group of objects.
2. Turn program control over to those objects.
Objects in the core group might create other objects as the program runs, and those objects might create still other objects. From time to time, the program might also load classes, unarchive instances, connect to remote objects, and find other resources as they’re needed. However, all that’s required at the outset is enough structure—enough of the object network—to handle the program’s initial tasks. The main function puts this initial structure in place and gets it ready for the task ahead.
Typically, one of the core objects has the responsibility for overseeing the program or controlling its input. When the core structure is ready, main sets this overseer object to work. If the program is a command-line tool or a background server, what this entails might be as simple as passing command-line arguments or opening a remote connection. But for the most common type of Cocoa program, an application, what happens is a bit more involved.
For an application, the core group of objects that main sets up must include some objects that draw the user interface. This interface, or at least part of it (such as an application’s menu), must appear on the screen when the user launches the application. Once the initial user interface is on the screen, the application is thereafter driven by external events, the most important of which are those originated by users: clicking a button, choosing a menu item, dragging an icon, typing something in a field, and so on. Each such event is reported to the application along with a good deal of information about the circumstances of the user action—for example, which key was pressed, whether the mouse button was pressed or released, where the cursor was located, and which window was affected.
An application gets an event, looks at it, responds to it—often by drawing a part of the user interface—then waits for the next event. It keeps getting events, one after another, as long as the user or some other source (such as a timer) initiates them. From the time it’s launched to the time it terminates, almost everything the application does is driven by user actions in the form of events.
The mechanism for getting and responding to events is the main event loop (called “main” because an application can set up subordinate events loops for brief periods.) An event loop is essentially a run loop with one or more input sources attached to it. One object in the core group is responsible for running the main event loop—getting an event, dispatching the event to the object or objects that can best handle it, then getting the next event. In a Cocoa application, this coordinating object is the global application object, an instance of NSApplication. Figure 3-1 illustrates the main event loop.
The main function in almost all Cocoa applications is extremely simple, as it consists of only one function call (see Listing 3-1). The NSApplicationMain function creates the application object, sets up an autorelease pool, loads the initial user interface from the main nib file, and runs the application, thereby requesting it to begin handling events received on the main event loop.
Listing 3-1 The main function in a Cocoa application
#import <AppKit/AppKit.h> |
int main(int argc, const char *argv[]) { |
return NSApplicationMain(argc, argv); |
} |
“The Core Application Architecture” describes the main event loop, the global NSApplication instance, and other core application objects in greater detail.
3.2 Using a Cocoa Framework
Library functions impose few restrictions on the programs that use them; you can call them whenever you need to. The methods in an object-oriented library or framework, on the other hand, are tied to class definitions and can’t be invoked unless you create or obtain an object that has access to those definitions. Moreover, in most programs the object must be connected to at least one other object so that it can operate in the program network. A class defines a program component; to access its services, you need to craft it into the structure of your application.
That being said, some framework classes generate instances that behave pretty much as a set of library functions. You simply create an instance, initialize it, and either send it a message to accomplish a task, or you insert it into a waiting slot in your application. For example, you can use the NSFileManager class to perform various file-system operations, such as moving, copying, and deleting files. If you need to display an alert dialog, you would create an instance of the NSAlert class and send it the appropriate message.
In general, however, environments such as Cocoa are more than a grab bag of individual classes that offer their services. They consist of object-oriented frameworks, collections of classes that structure a problem space and present an integrated solution to it. Instead of providing discrete services that you can use as needed (as with function libraries), a framework maps out and implements an entire program structure—or model—that your own code must adapt to. Because this program model is generic, you can specialize it to meet the requirements of your particular program. Rather than design a program that you plug library functions into, you plug your own code into the design provided by the framework.
To use a framework, you must accept the program model it defines and employ and customize as many of its classes as necessary to mold your particular program to that model. The classes are mutually dependent and come as a group, not individually. At first glance, the need to adapt your code to a framework’s program model might seem restrictive. But the reality is quite the opposite. A framework offers you many ways in which you can alter and extend its generic behavior. It simply requires you to accept that all Cocoa programs behave in the same fundamental ways because they are all based on the same program model.
Kinds of Framework Classes
The classes in a Cocoa framework deliver their services in four ways:
· Off the shelf. Some classes define off-the-shelf objects, ready to be used. You simply create instances of the class and initialize them as needed. Subclasses of NSControl, such as NSTextField, NSButton, and NSTableView (along with their associated NSCell classes), fall into this category. You typically create and initialize off-the-shelf objects using Interface Builder, although you can create and initialize them programmatically.
· Behind the scenes. As a program runs, Cocoa creates some framework objects for it “behind the scenes.” You don’t need to explicitly allocate and initialize these objects; it’s done for you. Often the classes are private, but they are necessary to implement the desired behavior.
· Generic. Some framework classes are generic. A framework might provide some concrete subclasses of the generic class that you can use unchanged. Yet you can—and must in some circumstances—define your own subclasses and override the implementations of certain methods. NSView, NSDocument, and NSFormatter are examples of this kind of class.
· Delegator and notifier. Many framework objects keep other objects informed of their actions and even delegate certain responsibilities to those other objects. The mechanisms for delivering this information are delegation and notification. A delegating object publishes an interface known as an informal protocol. Client objects must first register as delegates and then implement one or more methods of this interface. A notifying object publishes the list of notifications it broadcasts, and any client is free to observe one or more of them. Some of the delegator classes are NSApplication, NSText, and NSWindow. Many framework classes broadcast notifications.
Some classes provide more than one of these general kinds of services. For example, you can drag a ready-made NSWindow object from an Interface Builder palette and use it with only minor initializations. Thus the NSWindow class provides off-the-shelf instances. But an NSWindow object also sends messages to its delegate and posts a variety of notifications. You can even subclass NSWindow if, for example, you want to have round windows.
It is the Cocoa classes in the last two categories—generic and delegator/notifier—that offer the most possibilities for integrating your program-specific code into the structure provided by the frameworks.
3.3 Cocoa API Conventions
When you start using the classes, methods, and other API of the Cocoa frameworks, you should be aware of a few conventions that are intended to ensure efficiency and consistency in usage.
· Methods that return objects typically return nil to indicate “failure to create” or “no object to return”. They do not return a status code.The convention of returning nil is often used to indicate a runtime error or other non-exceptional condition. The Cocoa frameworks deal with errors such as “array index out of bounds” or “method selector not recognized” by raising an exception (which is handled by a top-level handler) and, if the method signature so requires, returning nil.
· Some of these same methods that might return nil include a final parameter for returning error information by reference. This final parameter takes a pointer to an NSError object; upon return from a method call that fails (that is, returns nil), you can inspect the returned error object to determine the cause of the error or you can display the error to the user in a dialog.
As an example, here’s a method from the NSDocument class:
- (id)initWithType:(NSString *)typeName error:(NSError **)outError;
|
· In a similar fashion, methods that perform some system operation (such as reading or writing a file) often return a Boolean value to indicate success or failure.These methods might also include a pointer to an NSError object as a final by-reference parameter. For example, there’s this method from the NSData class:
(BOOL)writeToFile:(NSString *)path options:(unsigned)writeOptionsMask error:(NSError **)errorPtr;
|
· Empty container objects are used to indicate a default value or no value—nil is usually not a valid object argument. Many objects encapsulate values or collections of objects, for example, instances of NSString, NSDate, NSArray, and NSDictionary. Methods that take these objects as parameters may accept an “empty” object (for example, @"") to indicate “no value” or “default value”. For example, the following message sets the represented filename for a window to “no value” by specifying an empty string:
[aWindow setRepresentedFilename:@""];
|
· The Cocoa frameworks expect that global string constants rather than string literals are used for dictionary keys, notification and exception names, and some method parameters that take strings. You should always prefer string constants over string literals when you have a choice. By using string constants, you enlist the help of the compiler to check your spelling and thus avoid runtime errors.
· The Cocoa frameworks use types consistently, giving higher impedance matching across their API sets.For example, the frameworks use float for coordinate values, CGFloat for both graphical and coordinate values, NSPoint (consisting of two CGFloat values) for a location in a coordinate system, NSString objects for string values, NSRange for ranges (start and offset), and NSInteger and NSUInteger for, respectively, signed and unsigned integral values. When you design your own APIs, you should strive for similar type consistency.
A substantial subset of Cocoa API conventions concerns the naming of classes, methods, functions, constants, and other symbols. You should be aware of these conventions when you begin designing your own programmatic interfaces. Some of the more important of these naming conventions are the following:
· Use prefixes for class names and for symbols associated with the class, such as functions and typedef’s.A prefix protects against collisions and helps to differentiate functional areas. The prefix convention is two or three unique uppercase letters, for example, the “AC” in ACCircle.
· With API names, it’s better to be clear than brief.For example, it’s easy to understand what removeObjectAtIndex: does but remove: is ambiguous.
· Avoid ambiguous names.For example, displayName is ambiguous because it’s unclear whether it displays the name or returns the display name.
· Use verbs in the names of methods or functions that represent actions.
· If a method returns an attribute or computed value, the name of the method is the name of the attribute.These methods are known as “getter” accessor methods. For example, if the attribute is background color, the getter method should be named backgroundColor. Getter methods that return a Boolean value are of a slight variation, using an “is” or “has” prefix—for example, hasColor.
· If a method sets the value of an attribute—that is, a “setter” accessor method—it begins with “set” followed by the attribute name.The first letter of the attribute name is in uppercase—for example, setBackgroundColor:.
· Do not abbreviate parts of API names unless the abbreviation is well known (for example, HTML or TIFF).
A general, overarching API convention regards object ownership. Briefly stated, the convention is that a client owns an object if it creates the object (by allocation then initialization), copies it, or retains it (by sending it retain). An owner of an object is responsible for its disposal by sending release or autorelease to the object when it no longer needs it.
3.4 Inheriting From a Cocoa Class
A framework such as the Application Kit defines a program model that, because it is generic, many different types of applications can share. Since the model is generic, it is not surprising that some framework classes are abstract or intentionally incomplete. A class often does much of its work in low-level and common code, but leaves significant portions of the work either undone or completed in a safe but generic “default” fashion.
An application often needs to create a subclass that fills in these gaps in its superclass, supplying the pieces the framework class is missing. A subclass is the primary way to add application-specific behavior to a framework. An instance of your custom subclass takes its place in the network of objects the framework defines. It inherits the ability to work with other objects from the framework. For example, if you create a subclass of NSCell, instances of this new class are able to appear in an NSMatrix object, just as NSButtonCell, NSTextFieldCell, and other framework-defined cell objects can.
When you make a subclass, one of your primary tasks is to implement a specific set of methods declared by a superclass (or in a protocol adopted by a superclass). Re-implementing an inherited method is known as overriding that method.
When to Override a Method
Most methods defined in a framework class are fully implemented; they exist so you can invoke them to obtain the services the class provides. You rarely need to override such methods and shouldn’t attempt to. The framework depends on them doing just what they do—nothing more and nothing less. In other cases, you can override a method, but there’s no real reason to do so. The framework’s version of the method does an adequate job. But just as you might implement your own version of a string-comparison function rather than use strcmp, you can choose to override the framework method if you wish.
Some framework methods, however, are intended to be overridden; they exist to let you add program-specific behavior to the framework. Often the method, as implemented by the framework, does little or nothing that’s of value to your application, but is invoked in messages initiated by other framework methods. To give content to these kinds of methods, an application must implement its own version.
Invoke or Override?
The framework methods you override in a subclass generally won’t be ones that you’ll invoke yourself, at least directly. You simply re-implement the method and leave the rest up to the framework. In fact, the more likely you are to write an application-specific version of a method, the less likely you are to invoke it in your own code. There’s a good reason for this. In a general sense, a framework class declares public methods so that you, the developer, can do one of two things:
· Invoke them to avail yourself of the services the class provide
· Override them to introduce your own code into the program model defined by the framework
Sometimes a method falls into both these categories; it renders a valuable service upon invocation, and it can be strategically overridden. But generally, if a method is one that you can invoke, it’s fully defined by the framework and doesn’t need to be redefined in your code. If the method is one that you need to re-implement in a subclass, the framework has a particular job for it to do and so will invoke the method itself at the appropriate times. Figure 3-2 illustrates the two general types of framework methods.
Much of the work of object-oriented programming with a Cocoa framework is implementing methods that your program uses only indirectly, through messages arranged by the framework.
Types of Overridden Methods
You may choose to define several different types of methods in a subclass:
· Some framework methods are fully implemented and are meant to be invoked by other framework methods. In other words, even though you may re-implement these methods, you often don’t invoke them elsewhere in your code. They provide some service—data or behavior—required by some other code at some point during program execution. These methods exist in the public interface for just one reason—so that you can override them if you want to. They give you an opportunity either to substitute your own algorithm for the one used by the framework or to modify or extend the framework algorithm.An example of this type of method is trackWithEvent:, defined in the NSMenuView class. NSMenuView implements this method to satisfy the immediate requirement—handling menu tracking and item selection—but you may override it if you want different behavior.
· Another type of method is one that makes an object-specific decision, such as whether an attribute is turned on or whether a certain policy is in effect. The framework implements a default version of this method that makes the decision one way, and you must implement your own version if you want a different decision. In most cases, implementation is simply a matter of returning YES or NO, or of calculating a value other than the default.The NSResponder acceptsFirstResponder method is typical of this kind. Views are sent acceptsFirstResponder messages asking, among other things, if they respond to key strokes or mouse clicks. By default, NSView objects return NO for this method—most views don’t accept typed input. But some do, and they should override acceptsFirstResponder to return YES.
· Overriding a method does not have to be a formidable task. You can often make significant change in superclass behavior by a careful re-implementation of the method that entails no more than one or two lines of code. And you are not entirely on your own when you implement your own version of a method. You can draw on the classes, methods, functions, and types already provided by the Cocoa frameworks.
When to Make a Subclass
Just as important as knowing which methods of a class to override—and indeed preceding that decision—is identifying those classes to inherit from. Sometimes these decisions can be obvious, and sometimes they can be far from simple. A few design considerations can guide your choices.
First, know the framework. You should become familiar with the purpose and capabilities of each framework class. Maybe there is a class that already does what you want to do. And if you find a class that does almost what you want done, you’re in luck. That class is a promising superclass for your custom class. Subclassing is a process of reusing an existing class and specializing it for your needs. Sometimes all a subclass needs to do is override a single inherited method and have the method do something slightly different from the original behavior. Other subclasses might add one or two attributes to their superclass (as instance variables), and then define the methods that access and operate on these attributes, integrating them into the superclass behavior.
There are other considerations that can help you decide where your subclass best fits into the class hierarchy. What is the nature of the application, or of the part of the application you’re trying to craft? Some Cocoa architectures impose their own subclassing requirements. For example, if yours is a multiple-document application, the document-based architecture of Cocoa requires you to subclass NSDocument and perhaps other classes as well. To make your application scriptable (that is, responsive to AppleScript commands), you might have to subclass one of the scripting class, such as NSScriptCommand.
Another factor is the role that instances of the subclass will play in the application. The Model-View-Control design pattern, a major one in Cocoa, assigns roles to objects: they’re view objects that appear on the user interface; model objects holding application data (and the algorithms that act on that data); or controller objects, which mediate between view and model objects. (For details, see “The Model-View-Controller Design Pattern”.) Knowing what role an object plays can narrow the decision for which superclass to use. If instances of your class are view objects that do their own custom drawing and event-handling, your class should probably inherit from NSView. If your application needs a controller object, you can either use one of the off-the-shelf controller classes (such as NSObjectController) or, if you want a different behavior, subclass NSController or NSObject. If your class is a typical model class—say, one whose objects represent rows of corporate data in a spreadsheet—you probably should subclass NSObject or use the Core Data framework.
Yet subclassing is sometimes not the best way to solve a problem. There may be a better approach you could take. If you just want to add a few convenience methods to a class, you might create a category instead of a subclass. Or you could employ one of the many other design-pattern based resources of the Cocoa development “tool box,” such as delegation, notification, and target-action (described in “Communicating With Objects”). When deciding on a candidate superclass, scan the header file of the class (or the reference documentation) to see if there is a delegation method, a notification, or some other mechanism that will enable you to do what you want without subclassing.
In a similar vein, you can also examine the header files or documentation for the framework’s protocols. By adopting a protocol, you might be able to accomplish your goal while avoiding the difficulties of a complex subclass. For example, if you want to manage the enabled states of menu items, you can adopt the NSMenuValidation protocol in a custom controller class; you don’t have to subclass NSMenuItem or NSMenu to get this behavior.
Just as some framework methods are not intended to be overridden, some framework classes (such as NSFileManager, NSFontPanel, and NSLayoutManager) are not intended to be subclassed. If you do attempt such a subclass, you should proceed with caution. The implementations of certain framework classes are complicated and tightly integrated into the implementations of other classes and even different parts of the operating system. Often it is difficult to duplicate correctly what a framework method does or to anticipate interdependencies or effects the method might have. Changes that you make in some method implementations could have far-reaching, unforeseen, and unpleasant consequences.
In some cases, you can get around these difficulties by using object composition, a general technique of assembling objects in a “host” object, which manages them to get complex and highly customized behavior (see Figure 3-3). Instead of inheriting directly from a complex framework superclass, you might create a custom class that holds an instance of that superclass as an instance variable. The custom class itself could be fairly simple, perhaps inheriting directly from the root class, NSObject; although simple in terms of inheritance, the class manipulates, extends, and augments the embedded instance. To client objects it can appear in some respects to be a subclass of the complex superclass, although it probably won’t share the interface of the superclass. The Foundation framework class NSAttributedString gives an example of object composition. NSAttributedString holds an NSString object as an instance variable, and exposes it through the string method. NSString is a class with complex behaviors, including string encoding, string searching, and path manipulation. NSAttributedString augments these behaviors with the capability for attaching attributes such as font, color, alignment, and paragraph style to a range of characters. And it does so without subclassing NSString.
Sometimes what seems to be the most obvious candidate for your superclass is not the best choice. As you might know, NSView objects are what Cocoa uses for drawing in most cases. But if you are designing a drawing or CAD program with potentially hundreds or thousands of graphic elements, you should think about designing and using your own custom graphic-element classes that do not inherit from NSView. In terms of object size, an NSView object carries around a lot of instance data. The graphic-element instances of your custom classes can be "lightweight" and yet contain all the information a single NSView object needs to draw them.
CHAPTER 4: COCOA DESIGN PATTERNS
What Is a Design Pattern?
A design pattern is a template for a design that solves a general, recurring problem in a particular context. It is a tool of abstraction that is useful in fields like architecture and engineering as well as software development. The following sections summarize what design patterns are, explains why they’re important for object-oriented design, and looks at a sample design pattern.
4.1 How Cocoa Adapts Design Patterns
You can find adaptations of design patterns throughout Cocoa. Mechanisms and architectures based on patterns are common in Cocoa frameworks and in the Objective-C runtime and language. Cocoa often puts its own distinctive spin on a pattern, its designs being influenced by factors such as language capabilities or existing architectures.
Implementations of design patterns in Cocoa come in various forms. Some of the designs described in the following sections—such as protocols and categories—are features of the Objective-C language. In other cases, the “instance of a pattern” is implemented in one class or a group of related classes (for example, class clusters and singleton classes). And in other cases the pattern adaptation is a major framework architecture, such as the responder chain. Some of the pattern-based mechanisms you get almost “for free” while others require some work on your part. And even if Cocoa does not implement a pattern, you are encouraged to do so yourself when the situation warrants it; for example, object composition (Decorator pattern) is often a better technique than subclassing for extending class behavior.
· Abstract Factory: Provide an interface for creating families of related or dependent objects without specifying their concrete classes. The client is decoupled from any of the specifics of the concrete object obtained from the factory.
· Class Cluster: A class cluster is an architecture that groups a number of private, concrete subclasses under a public, abstract superclass. The abstract superclass declares methods for creating instances of its private subclasses. The superclass dispenses an object of the proper concrete subclass based on the creation method invoked. Each object returned may belong to different private concrete subclass.
· Adapter: Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. It decouples the client from the class of the targeted object.
· Protocols: A protocol is a language-level (Objective-C) feature that makes it possible to define interfaces that are instances of the Adapter pattern. (In Java, “interface” is synonymous with “protocol.”) If you want a client object to communicate with another object, but their incompatible interfaces make that difficult, you can define a protocol, which is essentially a series of method declarations unassociated with a class. The class of the other object then formally adopts the protocol and “conforms” to it by implementing all of the methods of the protocol. The client object can then send messages to the other object through the protocol interface. Protocols make a set of method declarations independent of the class hierarchy. They make it possible to group objects on the basis of conformance to a protocol as well as class inheritance.
· Chain of Responsibility: Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. Each object either handles the request or passes it to the next object in the chain.
· Responder Chain: The Application Kit framework includes an architecture known as the responder chain. This chain consists of a series of responder objects (that is, objects inheriting from NSResponder) along which an event (for example, a mouse click) or action message is passed and (usually) eventually handled. If a given responder object doesn’t handle a particular message, it passes the message to the next responder in the chain. The view hierarchy, generally determines the order of responder objects in the chain with the progression from lower-level to higher-level responders in the hierarchy, culminating in the window object that manages the view hierarchy or the delegate of the window object or the global application object. The exact paths of events and action messages up the responder chain are different. An application can have as many responder chains as it has windows (or even local hierarchies of views); but only one responder chain can be active at a time—the one associated with the currently active window. A similar chain of responders exists for error handling in an application. The design of the view hierarchy, which is closely related to the responder chain, adapts the Composite pattern (“Composite”). Action messages—messages originating from control objects—are based on the target-action mechanism, which is an instance of the Command pattern (“Command”).
· Command: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. The request object binds together one or more actions on a specific receiver. The Command pattern separates an object making a request from the objects that receive and execute that request.
· Target-Action: The target-action mechanism enables a control object—that is, an object such as a button, slider, or text field—to send a message to another object that can interpret the message and handle it as an application-specific instruction. The receiving object, or the target, is usually a custom controller object. A selector, a unique runtime identifier of a method, determines the message—named an action message—. The cell object that a control owns typically encapsulates the target and action; the control sends the message when the user clicks or otherwise activates it. (A menu item also encapsulates target and action, and sends an action message when the user chooses it.) The target-action mechanism can work on the basis of a selector (and not a method signature) because the signature of an action method by convention is always the same.
· Composite: Compose related objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. The Composite pattern is part of the Model-View-Controller aggregate pattern.
· Decorator: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. As does subclassing, adaptation of the Decorator pattern allows you to incorporate new behavior without modifying existing code. Decorators wrap an object of the class whose behavior they extend. They implement the same interface as the object they wrap and add their own behavior either before or after delegating a task to the wrapped object. The Decorator pattern expresses the design principle that classes should be open to extension but closed to modification.
· Façade: Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use by reducing complexity and hiding the communication and dependencies between subsystems.
· Iterator: Provide a way to access the elements of an aggregate object (that is, a collection) sequentially without exposing its underlying representation. The Iterator pattern transfers the responsibility for accessing and traversing the elements of a collection from the collection itself to an Iterator object. The Iterator defines an interface for accessing collection elements and keeps track of the current element. Different iterators can carry out different traversal policies.
· Mediator: Define an object that encapsulates how a set of objects interacts. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. These objects can thus remain more reusable. A Mediator object centralizes complex communication and control logic between objects in a system. These objects tell a Mediator object when their state changes and, in turn, respond to requests from Mediator.
· Memento: Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later. The Memento pattern keeps the important state of a key object external from that object to maintain cohesion.
· Observer: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. The Observer pattern is essentially a publish-and-subscribe model in which the subject and its observers are loosely coupled. Communication can take place between the observing and observed objects without either needing to know much about the other.
· Proxy: Provide a surrogate or placeholder for another object to control access to it. You use this pattern to create a representative object that controls access to another object, which may be remote, expensive to create, or in need of securing. This pattern is structurally similar to the Decorator pattern but it serves a different purpose; Decorator adds behavior to an object whereas Proxy controls access to an object.
· Singleton: Ensure a class only has one instance, and provide a global point of access to it. The class keeps track of its sole instance and ensures that no other instance can be created. Singleton classes are appropriate for situations where it makes sense for a single object to provide access to a global resource.
· Template Method: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. The Template Method pattern lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.
CHAPTER 5: SAMPLE PROGRAM
This Xcode project builds a command line tool that when launched dumps out all HID devices and their properties optionally including all device elements and their properties.
#pragma mark -
#pragma mark * complation directives *
//----------------------------------------------------
#ifndef FALSE
#define FALSE 0
#define TRUE !FALSE
#endif
//****************************************************
#pragma mark -
#pragma mark * includes & imports *
//----------------------------------------------------
#include <CoreFoundation/CoreFoundation.h>
#include <Carbon/Carbon.h>
//#include <IOKit/hid/IOHIDLib.h>
#include "HID_Utilities_External.h"
//****************************************************
#pragma mark -
#pragma mark * typedef's, struct's, enums, defines, etc. *
int main ( int argc, const char * argv[] )
{
#pragma unused ( argc, argv )
Boolean dumpElements = false;
if ( argc >= 2) {
char elements_param[] = "-elements";
if (0 == strncmp(argv[1], elements_param, strlen(elements_param))) {
dumpElements = true;
} else {
printf("usage: %s [-elements]\n", argv[0]);
return -1;
}
}
IOHIDManagerRef tIOHIDManagerRef = IOHIDManagerCreate( kCFAllocatorDefault, kIOHIDOptionsTypeNone );
require( tIOHIDManagerRef, Oops );
IOHIDManagerSetDeviceMatching( tIOHIDManagerRef, NULL );
IOReturn tIOReturn = IOHIDManagerOpen( tIOHIDManagerRef, kIOHIDOptionsTypeNone );
require_noerr( tIOReturn, Oops );
CFSetRef deviceCFSetRef = IOHIDManagerCopyDevices( tIOHIDManagerRef );
require( deviceCFSetRef, Oops );
CFIndex deviceIndex, deviceCount = CFSetGetCount( deviceCFSetRef );
IOHIDDeviceRef * tIOHIDDeviceRefs = malloc( sizeof( IOHIDDeviceRef ) * deviceCount );
require( tIOHIDDeviceRefs, Oops );
CFSetGetValues( deviceCFSetRef, ( const void ** )tIOHIDDeviceRefs );
for ( deviceIndex = 0; deviceIndex < deviceCount; deviceIndex++ ) {
//open it
tIOReturn = IOHIDDeviceOpen( tIOHIDDeviceRefs[deviceIndex], kIOHIDOptionsTypeNone );
require_noerr( tIOReturn, next_device );
HIDDumpDeviceInfo( tIOHIDDeviceRefs[deviceIndex] );
if (dumpElements) {
//and copy all the elements
CFArrayRef elementCFArrayRef = IOHIDDeviceCopyMatchingElements( tIOHIDDeviceRefs[deviceIndex],
NULL /* matchingCFDictRef */,
kIOHIDOptionsTypeNone );
require( elementCFArrayRef, next_device );
//iterate over all the elements
CFIndex elementIndex, elementCount = CFArrayGetCount( elementCFArrayRef );
for ( elementIndex = 0; elementIndex < elementCount; elementIndex++ ) {
IOHIDElementRef tIOHIDElementRef = ( IOHIDElementRef )CFArrayGetValueAtIndex( elementCFArrayRef, elementIndex );
require( tIOHIDElementRef, next_element );
HIDDumpElementInfo( tIOHIDElementRef );
next_element: ;
continue;
}
CFRelease( elementCFArrayRef );
}
next_device: ;
( void )IOHIDDeviceClose( tIOHIDDeviceRefs[deviceIndex], kIOHIDOptionsTypeNone );
continue;
}
if ( tIOHIDManagerRef ) {
CFRelease( tIOHIDManagerRef );
}
Oops: ;
return 0;
}
CONCLUSION
Cocoa is one of Apple Inc.'s native object-oriented application program environments for the Mac OS X operating system. It is one of five major APIs available for Mac OS X; the others are Carbon, POSIX (for the BSD environment), X11 and Java.
Cocoa applications are typically developed using the development tools provided by Apple, specifically Xcode (formerly Project Builder) and Interface Builder, using the Objective-C language. However, the Cocoa-programming environment can be accessed using other tools, such as Object Pascal, Python, Perl and Ruby, with the aid of bridging mechanisms such as PasCocoa, PyObjC, CamelBones and RubyCocoa, respectively. Also, under development by Apple, is an implementation of the Ruby language, called MacRuby, which does away with the requirement for a bridging mechanism. It is also possible to write Objective-C Cocoa programs in a simple text editor and build it manually with GCC or GNUstep's makefile scripts. For end-users, Cocoa applications are considered to be those written using the Cocoa-programming environment. Such applications usually have a distinctive feel, since the Cocoa-programming environment automates many aspects of an application to comply with Apple's human interface guidelines.
No comments:
Post a Comment
leave your opinion