| < Previous PageNext Page > |
To say that Cocoa has its own development environment wouldn’t quite be an accurate statement. For one thing, programmers can use Apple’s major development applications, Xcode and Interface Builder, to develop software for other Mac OS X application environments, such as Carbon. Moreover, it is possible to develop Cocoa applications without using Xcode and Interface Builder at all. For instance, you can use Metrowerks’ CodeWarrior to manage, compile, and debug Cocoa projects. And, if you want to be really hard-core, you can write code using a text editor such as Emacs, build the application from the command line using make files, and debug the application from the command line using the gdb debugger.
But Xcode and Interface Builder are the preferred applications to use for developing Cocoa software. Their origins coincide with the origins of Cocoa itself, and consequently there is a high degree of compatibility between tools and frameworks. Together, Xcode and Interface Builder make it extraordinarily easy to design, manage, build, and debug Cocoa software projects. There is also AppleScript Studio, which extends those capabilities to allow you to create both scriptable Cocoa applications and applications that use AppleScript to control other applications.
Xcode
Interface Builder
AppleScript Studio
Other Development Tools
Xcode is the engine that powers Apple’s integrated development environment (IDE) for Mac OS X. It is an application that takes care of most project details from inception to deployment. It allows you to
create and manage projects, including specifying target requirements, dependencies, and build styles
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 in a graphical source-level debugger
Xcode builds projects from source code written in C, C++, Objective-C, Objective-C++, and Java. It generates executables of all supported types on Mac OS X, including command-line tools, frameworks, plug-ins, kernel extensions, bundles, and applications. 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).It also supports several source-code management systems (among them CVS and Perforce), allowing you to add files to a repository, commit changes, get updated versions, and compare versions.
Figure 1-4 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 (Objective-C or Java), document-based application (Objective-C or Java), tool, bundle, and framework. For compiling Cocoa software, Xcode uses the GNU C compiler (gcc), and for debugging that software, it uses the GNU source-level debugger (gdb). Both gcc and gdb have been used in Cocoa development since Cocoa was NeXTSTEP (see “A Bit of History”), and over the years have been refined, extended, and tuned to support the compilation and debugging of Cocoa binaries.
Xcode also has a class-browsing feature that lets you view the classes of all imported Cocoa frameworks plus any of your custom classes in their inheritance relationships; from the class browser you can request documentation on any class. It also includes design tools, including one for designing the attributes and relationships of entities used in Core Data applications.
Xcode is well integrated with the other major development application, Interface Builder. In Interface Builder you can define a class (superclass, outlets, and actions) and generate skeleton header and source files for each class in your project. In Xcode, you can add outlets and actions to your custom class, and have Interface Builder import these entities into nib files.
Note: Briefly, an outlet is an archived connection between one object and another object (and is specified as an instance variable of one object). An action is a method invoked in an object (usually a custom object) called the target when another object such as a button or slider is manipulated; Interface Builder also archives the connection between the target and the other object (called a control). For more on outlets, targets, and actions, see “Outlets” and “The Target-Action Mechanism”.
Further Reading: The Xcode Quick Tour Guide gives an overview of Xcode and provides links to additional development-tools documentation.
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. Since then, it has received widespread recognition as being one of the best applications of its kind. Not surprisingly, its integration with Cocoa is airtight. Moreover, you can also use it to create user interfaces for Carbon applications.
Interface Builder is centered around three main design elements:
Nib files. A nib file is actually a file wrapper (an opaque directory) that contains the objects appearing on a user interface in an archived form. Essentially, this archive is an object graph that contains information on each object, including its size and location on the screen (if a window) or within a window. Nib files in Cocoa applications also include proxy references for custom classes and information on the connections between objects, including those made using the Cocoa bindings technology. 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. A nib file can include image and sound files used in the interface.
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. (Thus nib files offer a way to easily localize user interfaces.) A Cocoa application by default—that is, as created by Xcode—has a main nib file, which it automatically loads and displays when it is launched. The main nib file contains the application’s main menu and perhaps one or more windows. Your application can load, upon demand, secondary nib files such as document and preference windows.
Interface Builder presents the contents of a nib file in a nib file window. The nib file window also lets you define custom classes and examine the connections between objects.
Palettes. Interface Builder’s Palette window contains multiple panes, or “palettes,” each containing a collection of related user-interface objects. You create a user interface by dragging objects from palettes onto appropriate surfaces, whether those surfaces be the screen, a window, a view of some sort, or the main menu. (Palette objects don’t have to be visible themselves, but they must affect the interface in some way.) When an object is dragged from a palette, Interface Builder instantiates a default instance of that object; it is a real Cocoa object, and not some proxy object standing in for an instance that will be created at runtime. If you wish, you can put your own custom objects on Interface Builder palettes.
Inspector. Interface Builder has an inspector (designated the Info window) for objects on a user interface. The Info window consists of a series of selectable panes for setting the initial attributes and sizes of objects (although size and many attributes can be set by direct manipulation). Two of the panes enable you to establish connections between objects, one using outlets and actions, the other using bindings. Another allows you to substitute a custom class for an Application Kit superclass. Still other, more specialized, panes allow you to associate help tags, and AppleScript event handlers with user-interface objects.
Figure 1-5 shows a nib file opened in Interface Builder, along with supporting windows.
The general sequence for creating a user interface in Interface Builder is straightforward:
Drag a window or panel object onto the screen (a panel is the same thing as a dialog or secondary window).
Set the window’s initial (or permanent) location, size, and attributes.
Drag objects such as text fields, buttons, table views, and pop-up lists onto the window, or onto previously placed views.
Set the initial (or permanent) location, size, and attributes of these objects.
Define your application’s custom classes.
You can do this in Interface Builder itself or by loading into Interface Builder previously created header files. When you define a custom class, Interface Builder lets you specify its outlets and actions.
Establish bindings or connections between objects. This can take one of two forms:
Save and test the interface.
Interface Builder has a feature that lets you test an interface (excluding custom behavior) at each stage of design.
Create the header file and source file for each custom class defined; these files appear in the associated Xcode project.
Interface Builder includes a feature that shows with momentary blue lines 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.
Further Reading: For further information on this user-interface development tool, see Interface Builder. In addition, “Nib Files” gives more information about nib files and their use in an application. Also refer to “Communicating With Objects” for overviews of outlets, the target-action mechanism, and the Cocoa bindings technology.
A defining feature of the Mac OS for years has been the capability for users to control applications with scripts written in the AppleScript language. Many users find this feature indispensable, for it allows them to string together complicated series of related operations involving multiple applications. AppleScript capabilities have been carried forward into Mac OS X. AppleScript Studio is a development technology for creating Cocoa applications that use AppleScript scripts to control complex user interfaces.
AppleScript Studio combines elements from AppleScript, Xcode, Interface Builder, and Cocoa to provide a sophisticated environment for creating AppleScript solutions. It allows you to build applications that can do the following:
execute AppleScript scripts
control the user interface of the application
control scriptable applications or scriptable parts of the operating system
Because AppleScript Studio integrates AppleScript with Xcode, Interface Builder, and Cocoa, scripters can take advantage of their particular strengths and capabilities. They can drag a rich set of user-interface objects off Interface Builder palettes and customize them to their liking. They get built-in support for the Aqua human interface guidelines. And they are able to build and maintain complex projects with multiple targets and build steps.
The development environment makes possible scripting capabilities that go well beyond those available in the Script Editor application traditionally used for creating AppleScript scripts. These include:
creation of arbitrarily large scripts
search and replace in scripts
single-step script debugging with variable execution
easy access to handlers and properties in scripts
a flexible dictionary viewer for working with application scripting terminologies
Further Reading: For more information, see the AppleScript Studio Programming Guide.
Although Xcode and Interface Builder are the major tools you use to develop Cocoa applications, there are dozens of other tools at your disposal. You might find many of these secondary applications and command-line tools helpful during some phase of application development.
This section reviews the secondary development applications and briefly discusses some of the command-line tools. However, the latter are so numerous that even a condensed summary of them is outside the scope of this document. Your best bet is to consult the manual pages (man pages) for the tools located in /usr/bin and /usr/sbin. To do this, type man followed by the name of the tool in a Terminal shell. There are also some Apple-developed command-line tools in /Developer/Tools.
The following applications are used in measuring and analyzing aspects of a program’s performance. They are located in /Developer/Applications.
Sampler analyzes a program’s running behavior and its allocation of memory. As its name indicates, Sampler periodically samples the program’s function call stack. When the sampling session ends, it shows you the functions or methods that it most frequently encountered. This information can help you locate functions or methods consuming large chunks of CPU time and functions or methods in which excessive memory allocations are occurring.
ObjectAlloc tracks memory allocations and deallocations in any program. This historical data reveals repetitive allocation behavior and overall allocation trends. For Objective-C code, ObjectAlloc records the invocation of every copy, retain, release, and autorelease method as well as every alloc invocation. It also records the Core Foundation functions that correspond to these methods as well as memory allocated through the malloc (and related) functions.
MallocDebug shows all currently allocated blocks of memory in your program, organized by the call stack at the time of allocation. At a glance you can see how much allocated memory your application consumes, where that memory was allocated from, and which functions allocated large amounts of memory. MallocDebug can also find allocated memory that is not referenced elsewhere in the program, thus helping you find leaks and track down exactly where the memory was allocated.
QuartzDebug is a tool to help you debug how your application displays itself. It is especially useful for applications that do significant amounts of drawing and imaging. QuartzDebug has several debugging options, including the following:
auto-flush drawing, which flushes the contents of graphics contexts after each drawing operation)
a mode that paints regions of the screen in yellow just before they’re updated
an option that takes a static snapshot of the system-wide window list, giving the owner of each window and how much memory each window consumes.
Thread Viewer displays activity among a process’s threads. It shows time lines of activity on each thread, which is color-coded with the action. By clicking a time line, you can get a sample backtrace of activity at that point.
For performance analysis, you can also use command-line tools such as:
top, which shows a periodically sampled set of statistics on currently running processes
gprof, which produces an execution profile of a program
fs_usage, which displays file-system access statistics
Many other command-line tools for performance analysis are available. For more on the performance tools and applications you can use in Cocoa application development, as well as information on concepts, techniques, and strategy related to performance, see the Performance Programming Topics.
Note: Performance Overview discusses the Mac OS X performance tools.
You might find the following applications (also located in /Developer/Applications) useful in Cocoa application development:
Icon Composer and icns Browser. For application and document icons, you can use Icon Composer to create icns files from imported images in various formats. You can use the icns Browser application to create variations of an icon in different sizes, bit depths, and bit masks.
FileMerge visually “diffs” text files (such as source files, header files, and property lists) and offers selective merging capabilities.
Package Maker packages applications (and other types of software) for installation by the Installer application.
Property List Editor is an editor for creating and editing XML and old-style property lists.
| < Previous PageNext Page > |
© 2006 Apple Computer, Inc. All Rights Reserved. (Last updated: 2006-12-20)
|