Apple Computer recently teamed up with O'Reilly & Associates to publish books aimed at Macintosh developers and administrators. O'Reilly is working with Apple to produce titles on Mac OS X, Apple's new operating system--a move consistent with O'Reilly's commitment to the Open Source Movement. One of the first books to come out of this collaboration is Learning Cocoa, which was written by a team of Apple writers and engineers. We asked the team at Apple to tell us about the Cocoa application environment and how this technology will benefit developers.
O'Reilly: Mac OS X represents a revolutionary change in Apple operating systems. How does Cocoa fit into Apple's new OS scheme?
Apple: Mac OS X supports three application environments (in addition to pure Java), and each is intended for a particular type of application.
The Classic environment lets you run most of your existing Mac OS 9 applications. Because Classic is a compatibility environment, it does not support new Mac OS X features such as Aqua or core architectural enhancements provided by Darwin.
The Carbon environment runs all Mac OS 9 applications whose code has been optimized for Mac OS X. By converting their code to use the Carbon APIs, developers can ensure that applications take advantage of protected memory, preemptive multitasking, and other features of Darwin. Carbonized applications can also take full advantage of the Aqua user-interface.
The Cocoa environment offers an advanced object-oriented programming environment for creating the best next-generation applications. Cocoa provides full access to all features of Mac OS X, including protected memory, preemptive multitasking, the Quartz graphics system, and the Aqua user-interface.
Using Cocoa, developers will be able to rapidly create new applications for use with Mac OS X, delivering exciting solutions to Mac OS X customers. Within weeks of Mac OS X's release there were already several full-featured, powerful, third party Cocoa applications out on the market. In fact, Apple itself relies heavily on Cocoa--many of the applications that come with Mac OS X are developed using Cocoa.
O'Reilly: To what extent is Cocoa based on NeXTStep? This technology has been around for a while, right?
Apple: Cocoa is based on NeXTStep, but has also been enhanced a great deal since then. It implements Aqua, the advanced user interface of Mac OS X; it understands a great deal more file formats, whether it be images, or sounds, or fonts; it supports today's standards such as PDF, XML, and HTML; and it integrates with OpenGL and QuickTime. The world of computing has undergone big changes since NeXTStep came out, and Cocoa has continued to track these changes and make them available to developers and users in an easy-to-use but robust and powerful fashion.
O'Reilly: Is Apple attracting a new breed of developer with Mac OS X's BSD roots?
Apple: Absolutely. We are seeing lots of interest from people already working with the various Unix variants. We are also seeing a lot of renewed interest from higher education and the scientific community who see Mac OS X as a way to get a fully supported operating system with a great UI, while still being able to build and run all their Unix-based custom applications.
|
Related Reading 
|
O'Reilly: Cocoa's advanced object-oriented APIs allow developers to work in both Java and Objective-C. How will this change application development for the Macintosh, and how well has this been received so far by the existing developer community?
Apple: Object-oriented programming by itself represents a much greater level of productivity for developers than traditional procedural programming. In addition, Cocoa is native to Mac OS X and provides APIs that integrate very well with it. Cocoa implements various advanced features of Mac OS X, such as Aqua, while providing access to QuickTime, OpenGL, and the Posix layer. These two factors combine to make Cocoa the perfect development environment for Mac OS X developers, especially those that are coming to the platform for the first time or those that are starting new projects. The ability to develop Cocoa applications using Objective-C and Java also makes it accessible to more developers.
Interest in Cocoa has been ramping up steadily, and the number of developers new to Cocoa, those who are learning it and asking questions on the various public mailing lists devoted to the topic, has been growing by leaps and bounds in the last year or so.
O'Reilly: In Learning Cocoa it is stated that after working their way through this book, developers will find Cocoa to be an environment they want to program in, and it will even make application development easy and fun. Specifically what aspects of Cocoa will endear it to developers?
Apple: The overall message of Cocoa and the thing that really wins over developers who begin to understand it is that Cocoa "makes easy things easy and hard things possible." What this means is that much of the design of Cocoa is centered around the concept that if there are things that all apps do and that get done mostly in the same way by all apps, the applications should not have to do it themselves. Cocoa provides very complete, out-of-the-box solutions to these common areas; however, it also is designed to allow for customization when the developers' needs are somewhat different from the usual.
With Cocoa, the "grunt work" in creating an application is done for you in the frameworks. Thus you concentrate on your own code, whether it be a productivity suite, a word processor, or a game. You don't deal with things like managing whether a mouse-down event is in the title bar of a window or the scroll bar. You don't have to write a single line of code to make use of a standard font dialog or color dialog. And you get a bunch of advanced features, such as spell checking, PDF rendering, and the ability to run in other languages for free.
In addition, thanks to Interface Builder, you can have your user interface prototyped and running in no time. Because Interface Builder does not generate code but instead archives objects, which can be edited over and over, you are able to make radical changes to your app's user interface at any time without breaking the rest of your app. Seeing your ideas come to life quickly and easily in an app that looks and works great on Mac OS X is a big reason developers fall in love with Cocoa.
O'Reilly: Is Learning Cocoa written for experienced object-oriented programmers, or can someone with no previous experience in an object-oriented language still benefit from this book?
Apple: Learning Cocoa is targeted at developers with some programming experience, but not necessarily a strong object-oriented background. Anyone familiar with a C-based programming language should be able to pick up the book and get right to work.
In fact, exploring the Cocoa frameworks is a great way to learn object-oriented concepts if you learn well by example. The frameworks are full of great object design patterns that can be applied to your own development, whether you are using Cocoa or not. In fact, in the most popular book on design patterns, Design Patterns: Elements of Reuasable Object-Oriented Software, there are a huge number of examples that are drawn from the Cocoa (then NeXTStep) APIs.
To keep on top of all the latest developments in Mac OS X, visit the O'Reilly Network's Mac DevCenter. For more information about using Cocoa, check out the Programming with Cocoa column.
O'Reilly: Objective-C is the native Cocoa language. What are the benefits of using Objective-C?
Apple: Objective-C is a small superset of C and is very easy to pick up, far easier than C++. It's small, it's efficient, and it's fully object-oriented. A lot of Cocoa features, such as the target/action paradigm and the ability to freeze-dry objects in nib files, rely greatly on the dynamic nature of Objective-C. Many programmers pick up Objective-C in a few short days, whether or not they have an object-oriented background. Those with a background in a dynamic object-oriented environment such as Java usually pick it up within a matter of hours.
O'Reilly: What are nib files, and when do they come into play?
Apple: "Nib" files store user-interface information for applications. When you create the user interface for an application, the information is saved in a nib file by archiving (or "freeze drying") the objects. When the app is later run, the nib file is loaded and the objects are brought back to life, re-creating the user interface. The important point here is that no code needs to be generated to implement the user interface, which means the interface can be tweaked throughout the development cycle of the application, independent of any code you write for the application.
O'Reilly: At the core of Cocoa is the Foundation framework and the Application Kit framework. What roles do these frameworks play in developing Cocoa applications?
Apple: Foundation framework is the "low-level" framework, providing a lot of system and OS level services. Foundation provides a layer of abstraction between the programmer and the operating system. It provides objects for base types, such as strings (with full Unicode support, of course), collections like dictionaries and arrays, and other basic functionality. It provides no user-interface services, and has no dependencies on Quartz or Aqua. This makes it appropriate for use by servers and other tools that have no user interface.
The Application Kit, or AppKit as it's commonly known, is a framework for developing applications with a graphical user interface. It provides a system for event handling in an application, a number of user interface elements that are pre-built and designed by Apple to provide all of the benefits of Aqua, as well as other services for interacting with the rest of the system. The Foundation base types are used extensively in the Application Kit. For example, if you ask an application for a list of its windows, you get back an array (a Foundation type) of NSWindow objects (an Application Kit type). Applications with a user interface will end up using both the AppKit and Foundation frameworks.
O'Reilly: Explain the roles of Project Builder and Interface Builder.
Apple: Project Builder is the native IDE on Mac OS X. It integrates very nicely with the system and knows how to deal properly with Java, Objective-C, C++, and other features of Mac OS X, such as the Mach-O executable format, bundles, and frameworks. Cocoa developers will typically use Project Builder in developing their applications.
Interface Builder is used to construct user interfaces and is an integral part of Cocoa. You use Interface Builder to create and edit user interfaces for Cocoa applications. Interface Builder is used very extensively in Cocoa development; it's extremely rare that an app creates a window and puts buttons and other controls in it programmatically. While that is certainly possible, it is much more convenient to use Interface Builder to construct the application's user interface.
O'Reilly and Apple Team Up--Tim O'Reilly introduces O'Reilly & Associates' expanded publishing program with books aimed at Macintosh developers and administrators. Our first two Macintosh developer books are Learning Cocoa and Learning Carbon.
O'Reilly: What does Project Builder do when you tell it to index a project? Is this always a good idea?
Apple: Project Builder indexes a project by analyzing all its source code and remembering important information about it, such as what classes you define and what methods they have. Many features in Project Builder depend on indexing information to function.
You should always index your projects unless there's some reason why you cannot.
O'Reilly: Can you explain the relationship between the Window Server and the NSWindow object?
Apple: WindowServer is the system service which manages the screen. Among other things, it vends areas of the screen to applications for them to draw on. These areas are called "windows," as you might expect. The NSWindow object is Cocoa's representation of these windows. Cocoa programmers will usually deal with Cocoa objects (which are all prefixed with "NS") rather than Window Server concepts directly. The Cocoa objects handle all the details of communicating with the Window Server to perform the operations requested by the Cocoa application.
O'Reilly: What kind of classes does Cocoa provide for managing files in the file system?
Apple: NSFileManager in Foundation does a lot of the stuff the Posix calls do, but with a more convenient and Cocoa-friendly API, including NSStrings and such. Use it to move, copy, delete files and folders, get information about them, and enumerate folder contents.
And there is NSURL which can be used for file:// URLs as well as other URL schemes.
NSFileWrapper in AppKit does a lot of document-level file handling, including managing file packages.
NSBundle in Foundation can be used to deal with (enumerate, load) resources and files belonging to an application. This includes doing the right thing with localized variants and loading the appropriate version for the user's chosen language.
Classes such as NSData, NSDictionary, NSString, and NSImage provide functionality to read and write files. So typically, rather than creating a file stream and writing the contents of an image to it as bytes, you just tell an NSImage object to write itself out to a file.
O'Reilly: In what ways can a Cocoa application communicate with other applications?
Apple: Between Cocoa apps you can use distributed objects, which allows objects in different applications to call each other transparently, as if they are in the same app. Between Cocoa and Carbon apps, you can use AppleEvents or lower level facilities such as CFMessagePort from CoreFoundation or Mach messaging.
In addition, distributed notifications (NSDistributedNotificationCenter) can be used to communicate events (such as "user preferences changed" or "networking configuration got updated") between applications. Perhaps the most straightforward method for exchanging data between applications is to use the clipboard to send information back and forth. This is how drag and drop works and also how services are implemented. Additionally, all the facilities of the lower-level subsystems are available to Cocoa applications, so TCP/IP and other communication services can be used.
O'Reilly: Learning Cocoa is one of the first books to be released under the new publishing partnership between Apple and O'Reilly & Associates. Why did Apple choose O'Reilly to work with on OS X-related titles?
Apple: Apple chose O'Reilly because they are a leader in the technical publishing business and many of Apple's current and future developers have a good deal of respect for the O'Reilly name. O'Reilly has a superior reputation among developers, particularly in the Unix and Java communities, where Apple has seen a huge surge of interest around Mac OS X. We're excited to be working with O'Reilly & Associates to ensure that developers get the highest quality books for Mac OS X development.
O'Reilly & Associates recently released Learning Cocoa (May 2001).
Sample Chapter 6, Essential Cocoa Paradigms, is available free online.
You can also look at the Table of Contents, Index, and Full Description of the book.
For more information, or to order the book, click here.
Copyright © 2009 O'Reilly Media, Inc.