Starting From Scratch

Building Cocoa Applications is split into four sections, each of which covers a different aspect of Cocoa development. The first section eases you both into the world of Cocoa and into Mac OS X in general. It explains the basics of the Mac interface, as well as some of Apple’s development tools and some basic OS X utilities.

There are two ways to approach this section. One way is as a Mac user (or developer) looking to learn Cocoa. If you fit into that category, you will probably want to skip the section introducing the OS X interface. It’s extremely basic and doesn’t introduce anything of great depth. For a Mac user, the most enlightening part might be the section that gives the official names for some of the Aqua UI widgets (for instance, the difference between a pop-up menu and a pull-down menu). Furthermore, if you’ve been using OS X for a while or are comfortable with Unix tools, you can probably skip the section on the bundled utilities, since you’ve likely seen them already.

You will, however, want to read the section on the development tools. Although there will be plenty of time through the course of the book to become familiar with many of them, ObjectAlloc is looked at only in this section. It’s a useful tool to be familiar with, so you should check it out.

The other way to approach this section would be as a developer coming to the Mac from another platform. In that case, read this section. You will at least learn the basics of the Mac interface, which will be of immense value when you release your product, as the majority of Mac users have very little patience for applications that don’t adhere to Apple’s Human Interface (HI) guidelines.

As for the other portions of this section, use your discretion. Depending on your background, you may only need to read portions of the developer tools and utilities sections.

A Bit Beyond “Hello, World”

Once your toes are in the water, Garfinkel and Mahoney take you deeper into the world of Cocoa with a pair of applications. The book’s second section introduces the basic Cocoa application, in the form of a calculator. Here, you learn about designing a user interface with Interface Builder, writing the Objective C code to interact with the interface, and the idea of the controller.

One of the nice things about the Calculator example is that it’s not just a calculator, it a fully functional calculator application. Along with being able to tell you that 2 + 2 = 4, it also has things like an icon and an About Calculator window. This is A Good Thing because the calculator acts as a real Macintosh application and, as I mentioned earlier, Mac users tend not to support products that act otherwise.

After completing the basic calculator application, Building Cocoa Applications covers document-based Cocoa applications in the third section. In this case, the MathPaper application builds on the idea of the calculator in the previous section. Instead of pressing buttons to generate answers, though, MathPaper lets you type in the formula and returns the answer when you press return.

One of the things I like about the MathPaper project is that it combines Cocoa and the Macintosh interface with the Unix roots on which OS X is built. In MathPaper, you actually create two different programs—a command-line program that does the actual arithmetic, and a Cocoa program that communicates with the command line program so users can work with a graphical program instead of the Terminal. Along with demonstrating inter-process communication, this approach lets you use different tools for the two portions of MathPaper. Also, it lets you test the function evaluator separately from the user interface, which could come in handy for trying to figure out where bugs are happening.

I do have a complaint about this section, though. In the course of writing the user interface, Garfinkel and Mahoney have the reader build a class for displaying text using Rich Text Format (RTF). However, Cocoa includes its own classes for creating and outputting formatted text, and these classes are probably more robust and better tested than anything an amateur developer could put together. The main point of an API like Cocoa is to make life simpler for the programmer by implementing functionality like this. There might be some people who want to learn the guts of RTF, but most of the people reading Building Cocoa Applications want to learn Cocoa.

Beyond the Basics

Once you make it into the fourth section of Building Cocoa Applications, the topics start coming thick and fast. In the book’s final section, you learn how to build a multi-threaded application that stores preferences, reacts to mouse events, supports both copy and paste, and acts as a Service for other applications. This approach builds on the MathPaper project and a slightly modified version of the Evaluator program to determine the solutions of single-variable functions. Then, instead of displaying the solution as text, GraphPaper draws the graph on screen.

By the time you complete this section, you end up with a very well-rounded application. It supports most of the features users expect in a Macintosh application. However, it feels like the aforementioned topics come so rapidly because the authors’ deadline was fast approaching. The Close command is removed from the File menu, but we are never instructed to disable the close widget in the title bar. The code for reverting the color preferences doesn’t work. Missing a widget is one thing, but including code that doesn’t work is something else. The authors should have done a better job of testing to make sure things like this didn’t happen.

Closing Thoughts

From the standpoint of wanting to learn Cocoa, Building Cocoa Applications does a decent job. It introduces you to many features of the Cocoa environment and gives you a good push towards learning the rest on your own by pointing you towards other available resources. Along with the issues I’ve mentioned above, though, there are a few things I’m not crazy about.

First, every chapter ends with a series of exercises. Some of these are programming questions such as, “implement this feature.” Others are theoretical questions like, “explain why approach A is better than approach B.” Although these exercises are good ways to push the reader off to work on their own, it would be nice if some answers or discussion were available, either in an appendix or on the book’s Web page.

It’s not so much the programming exercises that concern me, but the implementation issues. Novice developers might not know enough to answer these questions and it would be useful to see the thoughts of professional developers. Basically, some of the questions seem like something out of a class textbook, but at least when you’re taking a class, you can talk to the professor or the teaching assistants. That’s not really the case here.

Second, there are about 20 pages of corrections on the book’s Web site. Some of these are typos or semantic corrections, but others are corrections to code which otherwise won’t compile as it’s written. Again, I don’t think there’s any excuse for this. If you’re including code in a book, write the code in the IDE and check its syntax. If it’s correct, copy and paste it down into the manuscript.

Third, many Cocoa developers originally developed for the NeXT operating system before Apple acquired the company. At times, you can tell that these people are Cocoa developers, but they aren’t Mac developers. I noticed this a few times throughout the book. First, there was the authors’ tendency to push command-line applications like emacs and gdb over their graphical counterparts. I’ve used a variety of the command line-tools and they do work well. However, Apple’s graphical tools were designed largely with Cocoa in mind and they integrate with the environment extremely well.

In addition to this, the authors wanted to prepend the name of the MathPaper application to the document name displayed in the title bar of each MathPaper document. Personally, I can’t remember the last time I saw this on a Macintosh document-based application. I know this practice is used in Windows, but I can’t be sure if it was used in the old NeXT operating system.

Finally, and this is not the authors’ fault, Building Cocoa Applications is already a bit out of date. Garfinkel and Mahoney wrote the book when OS X 10.1 was the current version of OS X. Now that Apple is shipping version 10.2 (10.2.1 at press time), certain aspects of both Cocoa and the user interface have changed. I didn’t come across any code that specifically would not work with 10.2, but the book obviously doesn’t include anything Apple added for 10.2.

The portions of the book that are most in need of updating are the parts dealing with the user interface. You might have to dig a bit to find options in Project Builder that were moved since the book was published. Also, with the changes to the Finder and many of the Aqua widgets, the first portion of section 1 should be re-written. There hasn’t been any announcement about a second edition of this title, but I wouldn’t be surprised to see one at some point.

Fortunately, O’Reilly & Associates lets you register your book and typically buy subsequent editions at a discount. If you want to learn Cocoa and are interested in this book, you shouldn’t let the differences between 10.1 and 10.2 scare you off from buying it.

Building Cocoa Applications gives you a solid introduction to developing software with Cocoa. It’s a little rough at certain points, but it also goes beyond the basics of some other tutorials by showing you how to interface with Unix tools. If you make it through Building Cocoa Applications, you won’t be a Cocoa expert, but you will be well on your way to becoming one.