Cocoa Programming for Mac OS X, 2nd Edition

Spencerian writes "Aaron Hillegass new book, Cocoa Programming for Mac OS X, 2nd Edition, is a very helpful book for developers interested in getting not only their feet wet, but become totally immersed in creating applications using the OpenStep-derived API known now as Cocoa. Don't dive in without knowing how to swim in C++/Java, however." Read on for the rest of Spencer's review. Cocoa Programming for Mac OS X, 2nd Edition author Aaron Hillegass pages 450 publisher Addison Wesley rating 9 reviewer Kevin H. Spencer ISBN 0321213149 summary Aaron Hillegass new book, Cocoa Programming for Mac OS X, 2nd Edition, is a very helpful book for developers interested in getting not only their feet wet, but become totally immersed in creating applications using the OpenStep-derived API known now as Cocoa. Don't dive in without knowing how to swim in C++/Java, however.

The author is no stranger to OpenStep, having worked at NeXT as well as Apple in OpenStep application development and training. Currently, Hillegass teaches Cocoa programming for The Big Nerd Ranch.

Cocoa Programming for Mac OS X, 2nd Edition is written in a way that makes you feel like you are in a class. There are prerequisites you must know and understand before you can begin, and, as a good professor would, the author points out what you need to have and know before beginning. Happily, the author is quite meticulous and has generously provided useful resource links and help where readers may explore for their supplies and primers and the like.

Essentially, anyone with a copy of Mac OS X 10.3 Panther has all that should be required--the Developer Tools CD contains all developer software and documentation necessary (the author notes in the book specific locations for key primers and references).

If you are experienced in C++ or Java programming, Cocoa development will seem familiar enough. Objective-C is used throughout the book (the author notes that development in Java is possible, but not recommended) for the various and numerous exercises. Cocoa development is made easier with Apple's Xcode application, however, Cocoa is not for the timid or novice programmer. This book is well-written and easy to follow IF you have a respectable level of C/C++ or Java development under your belt.

The text, as well as its diction, is easy on the eyes and mind, and while this is a programming book, the author's voice speaks well, allowing you to feel as if you can ask the book questions as if you were in a classroom. Graphics and text are plentiful, but information is not packed on every page, so following along is far from drudgery. Each chapter does stack itself on information from the previous, so this isn't a reference book in the strictest sense.

Addison-Wesley, the publisher, has formatted the book nicely, with a pleasant font that won't tire the eyes, consistent code and text conventions, and a detailed Table of Contents and Index, However, it's thickness and binding doesn't lend itself to lying flat, so you'll have to weight the book pages down to read the book hands-free as you type in examples. Speciality bindings that could have been useful for this book are not cheap, based on my publishing experience, and such a binding would add more to the book's $45 US cost. (Amazon has a great deal on the book at the time of this review.)

Five new chapters were added in this 2nd edition, which discuss creating AppleScriptable applications, integrating OpenGL, adding Undo abilities, creating reusable frameworks, and tinkering with GNUStep, the raw open-source tools for those curious about making Cocoa apps under Linux.

If you're a UNIX or Windows developer who picked up a Mac OS X machine recently in hopes of developing new apps or porting your apps to Mac users. this book should be strongly considered as one of your essential reference and training tomes.

You can purchase Cocoa Programming for Mac OS X, 2nd Edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.

Comments

Differences from first edition

[tenuki]

How different is this one from the first edition?

Re:Differences from first edition

[Art Tatum]

I've been playing with GNUstep happily for quite some time now. And one thing you absolutely *have* to see (if you haven't already) is Renaissance. You define your GUI with an XML document (including targets, actions, and outlets) and it's automagically laid out on both OS X and GNUstep. This not only makes porting much easier, it will also make it much easier for your GUIs to adapt to foreign languages, the upcoming GNUstep theme support, and different end-user fonts.

It's still in development, and there isn't a graphical builder for it yet, but it's very promising.

THAT is an old story...

[argent]

From what I've heard Apple is taking this more seriously than Microsoft.

After all, this is the same basic design flaw that led me to ban IE and Outlook at work about ... jeeze... getting on for a decade ago, and that about nine out of ten email viruses and worms exploit, and that Microsoft not only refused to fix but spent five years in lawsuits with the justice department to defend... even though every other person in the security business was telling them it was a bad idea.

HEY, PEOPLE, DON'T USE THE SAME PROGRAMS AND HELPER APPLICATIONS FOR LOCAL DATA AND THE INHERENTLY UNTRUSTABLE INTERNET!

Sheesh. This isn't rocket science. Hopefully Apple has some rocket scientists and won't spend the next decade patching one hole after another.

Re:THAT is an old story...

[dasmegabyte]

I'd have to say you have a very skewed opinion of how programs work.

See, if you have to do something twice, you only write it once. Because if you had to write it twice, each version would be twice as buggy. Which in your case would mean twice as many exploits. It really isn't rocket science to see which is a better idea from a process management perspective. If you want stable code, you can't go writing a separate version of something just for use on the internet.

What you should do, however, is never make the assumption that what the program is being told to do is what the USER wants the program to do. This works for local exploits as well...like when your brother starts trying to screw around with the network settings. If your program is being asked to do something twitchy...like delete something, change a system setting, open a port, etc...then your program should require user input before doing so. It should never automatically execute anything that might be unsafe.

Which is where Apple's one step better than Windows. It asks you for your system password before mucking with the system. It asks for your system password before deleting system wide programs. It unpacks archives automatically, but doesn't run the files inside. And it can be made to ask for your user password before messing with your user settings.

No xcode?

[tf23]

From this review it says that the book starts out with how to start a Cocoa application project with Project Builder

Where are the Xcode books???

I'd love to see a "more up to date" version of this that deals strictly with using Xcode. That seems to be the tool of choice for the OSX Cocoa developer's future.(imho)

Re:Same for GnuStep it seems...

[Art Tatum]

I wonder how long he spent looking at it. The GNUstep-base (Foundation) reached 1.0 a long, long, long time ago (currently at 1.9.1) and is stable and featureful on both UNIX and Windows. GNUstep-gui (AppKit) is at 0.9.2 and is also very stable and useful on UNIX, getting there on Windows.

GNUstep has very fine InterfaceBuilder and ProjectBuilder clones, a quickly growing number of excellent end-user applications.

Also, it seems to me that the install is *not* difficult. Granted, I've been working with it for a long time, so maybe I'm just used to it. And I'm sure Hillegass wasn't used to dealing with Linux (or BSD, or Solaris, or whatever he tried to install it on).

But considering the very small number of people working on the GNUstep core, I'm amazed at the quality and completeness of the project.

Reference

[Ann Coulter]

I perfer Cocoa Programming by Scott Anguish. It is a great Cocoa book as it describes many aspects of Cocoa, not just making a GUI like most books I've seen. It describes the philosophy, principles, design, and even implementation of Cocoa. It is more in-depth than any Cocoa book I've seen. It is the only Cocoa book I know of that contains more than 1000 pages. And as for value, it is an invaluable reference to any Cocoa programmer and the cost is not much either as you can find it in some outlet book stores for about twenty dollars. I would certainly recommend Cocoa Programming to anyone interested in developing for the Macintosh OS Ten.

Re:MVC Shite!...

[jamesmrankinjr]

Tell me, Can I make a dynamic screen, that adjusts itself based on the data inside it (AKA Java Swing)....

Yuck. Gag. Barf. Retch.

First off, MVC is really not very controversial. Most developers accept that MVC design is a Best Practice for applications with a significant user interface.

Secondly, if you honestly prefer writing a ton of code to create a Swing GUI to drawing exactly what you want in IB and being done with it, you are a masochist. With bindings, it's even easier now to hook up the GUI to your model. And if you use a tool that generates the GUI code for you, you're justing putting the pain off a little bit. Sooner rather than later, you will need to dive into all that autogenerated code, and what you see won't be pretty.

Thirdly, yes, I'm sure you can do the Currency Converter app faster in VB. BUT THAT'S BECAUSE YOU'RE MORE EXPERIENCED IN VB! Maybe you can save a small amount of time writing Currency Converter in VB if you eschew MVC design, but that's just because Currency Converter is not a serious application. Write anything more complex, and a good MVC design will give you a huge advantage in development time and code quality. It's a matter of being penny wise and pound foolish.

What about creating reuseable, database linked components, that can be dropped into any screen in a line of code?

Apple owned the definitive technology in this space. It was called Enterprise Objects (it kind of still exists but only Java and only works with WebObjects). Apple apparently decided it gave them too much of a competitive advantage for enterprise development and were afraid it might lead to success in that market segment, so they dropped Cocoa support for it.

Peace be with you,
-jimbo

Re:MVC Shite!...

[Ilan Volow]

Right now, I'm developing a Java app in Cocoa. I vastly prefer it to Swing because every Swing UI builder I've ever used is clunky while Interface Builder is simply elegant. And the nice thing about Java is that is has a large number of classes for stuff like X509 certificates and regular expressions don't really have counterparts in Objective-C (or if they do, crappy third-party counterparts).

In regards to the dynamic sizing issue (if I understand the complaint correctly), you can have dynamically changing sizes. Open up an inspector for a control and select "Size" from the pop-up menu at the top. You should see a box within a box. Clicking on different areas of the box draws little springs--those springs represent in what ways the control is allowed to grow/shrink.

The biggest advantage of the MVC for a GUI, IMHO, is portability. While the UI/View for my Cocoa app will be mac-specific, the logic/model for the app is completely cross-platform. I could probably also make the controller code cross-platform by wrapping it for the system I'm porting to, especially if that system supports the MVC paradigm.