More than two years ago we reviewed the first edition of the excellent book by Aaron Hillegass, “Cocoa Programming for Mac OS X”. The second edition has just being released and we will be taking a quick look as to what’s new.There is not much point going into depth as most of the book is very similar to the first edition, which is already reviewed. However, we did spot many clean ups in the way the text is layed out. A lot of additions/correction in the midst of past content has being added too as the Mac OS X API has evolved since then. For example, our main gripe in the previous book was the minimal information on the debugger, and the updated content has now some added information. The same is true for other places throughout the book making it now feel richer and more ‘mature’ somehow (which is probably because the API itself is now more mature than it used to be and the use of XCode throughout the book makes things simpler).
Additionally, all screenshots have being re-worked to present 10.3 Panther-derived shots throughout the book.
The new book includes five new chapters: adding capabilities to your app using NSUndoManager, Applescript, OpenGL on Cocoa, reusable frameworks and a chapter for the introduction to GNUstep.
The chapter for Applescript is also an introduction to the script language which can be very handy and useful in the design of an application, the OpenGL chapter is a bit short on details but if you already have some experience with 3D programming it should be enough to get you started. There is an interesting tidbit about prebinding on chapter 30 as well.
Regarding the GNUstep chapter it goes through how to install it and setup some of its tools but that chapter is really too short. The GNUstep guys say that if you want to design an app that’s going to work on both Cocoa and GNUstep, you need to start writing it on GNUstep and then “port” it to Cocoa. The other way around is not going to work well because GNUstep doesn’t have implemented most of Cocoa’s API. So, some pointers of what frameworks/functions to use and what to avoid when targetting portability should have being interesting in the current book.
Other than that, this is as good as the first book and it is a recommended buy for all OSX programmers. The writing is definately enjoyable and Aaron proves again to be a great teacher.
On another note, DevChannel published an excerpt from the book, you can read it here.
Overall: 8.5/10
Buy “Cocoa Programming for Mac OS X, Second Edition“ at Amazon.com |
I tried the previous edition, I think after seeing the review here, and was not impressed when the first bit of sample code called non-existant methods and would not compile.
Does anyone know if the new NSController class is covered in the new book?
I thought the first edition was pretty good, got me over a few hurdles…
I was hoping to check into this book as a resource for Java/Cocoa programming. However, looking at the Amazon description, it indicates that the author lightly covers the topic but does not recommend using the two together.
Anyone know why or have more info on this?
Actually, if the two don’t really play well together, this is another reason to dive into GCJ’s native compilation of java code (see topic from a few days ago on osnews)..
Like most people who have been using Cocoa since it was NeXT, the author believes ObjC is THE ANSWER, so it’s not surprising that he recommends it. At the time of the first edition, there were still a lot of bugs in the Java/ObjC bridge, so he justifiably recommended against using Java with Cocoa. My understanding is that a lot of those bugs have been squashed, so there’s less reason to avoid it. That said, Java apps launch slowly because they have to wait for its runtime to launch, and Cocoa was designed for use with ObjC, so it will always be a better fit with that language.
Going with GCJ won’t help with most of these issues, because they are language issues, not compiler issues. An example off the top of my head is that lots of things in Cocoa still use C-style structs (ie – window areas are defined as a rectangular “frame” struct with an origin and size, which are in turn both structs). Since Java doesn’t allow primitives like this, the whole thing has to be reworked and new classes created to handle these things.
Cheers,
JT
yep.. the NSController class is cover in this text. i have the text in my hands now.. and see that it’s chapter 6.
I received a preview copy when I went to Big Nerd Ranch in April and I must say excellent book, excellent instructor!
Also, this is the only book to cover Bindings, I believe.
GNUstep doesn’t have implemented most of Cocoa’s API
Are you sure ? 90% (if not more) of Cocoa API is OpenStep, which GNUstep implements. Additions to OpenStep API could exist ot not in GNUstep, but many are (NSDocument, NSToolbar, etc.). What’s missing is NSDrawer, the XML classes (because GNUstep already have ones, and you could use others framework like skyrix-xml — but compatible classes will appear anyway), and some recent additions like the controllers stuff (panther).
I’ve read part of this book, and the author does not agree with using Java to build Cocoa apps. He says if you want to use Java, it’s better to use the Swing API because that is portable, while Cocoa/Java only exists on the Mac.
I should buy a copy for Adobe and send it to them considering the bad port of Premiere 6.5 a few years ago. It’s no wonder why they dropped mac support, because it ran so horribly on OS X. I’m almost positive it was a carbon app, can anyone give me any knowledge on that? Cocoa app’s run so much better on OS X.
I’m surprised at the number of cocoa/gnustep articles lately on osnews. As usual for those coders who are somewhat interested in the API and want a brief overview, i recommend checking out my objective-c tutorial at http://otierney.net/objective-c.html
Objective-C is a great language for any platform; Windows, Linux, OR Mac.
“NOTE: Exception handling is only supported in Mac OS X 10.3”
Is this still true? That would be a major bummer.
” I’m almost positive it was a carbon app, can anyone give me any knowledge on that?”
Yes, it sure was. It takes a long time to rewrite large complicated apps like that. Even the Finder, iTunes, and QuickTime Player are stil carbon. A large part of the reason they dropped it for OS X was the next version was a complete rewrite, even on Windows, and the effort for writing two completely different versions (Windows and OS X) when one wasn’t going to sell very well against FCP just wasn’t worth it.
“NOTE: Exception handling is only supported in Mac OS X 10.3”
Is this still true? That would be a major bummer.
No, exception handling in ObjC existed way before OSX 10.3; but a new exception handling mechanism was introduced in 10.3, and _this_ mechanism isn’t supported on older apple gcc (nor it is on the fsf gcc for the moment, by the way), which is quite normal.
After a few weeks of cocoa and a few books bought I am well on my way of doing my first real cocoa app. OBJ-C is really cool language and after trying out perl and java bindings and a lot of different things I learnt a lot and found obj-c a really easy and cool language, I am most likely bying this book
So what exactly has changed? Just curious…
Well, it should be safer than the previous mechanism; the syntax has changed too, to be quite java-ish. Before, you had:
NS_DURING
// Your code
NS_HANDLER
// The exception handler
NS_ENDHANDLER
now, you’ll have:
@try {
// Your code
}
@catch {
// The exception handler
}
Plus, you’ll have the possibility of using a finalize block.
More infos on http://gcc.gnu.org/onlinedocs/gcc/Objective-C-Dialect-Options.html
I’ve struggled with a number of cocoa books in the past, but never really got my head around it. I’m not sure if it’s just me coming back to it fresh, or the way this book teaches, but it all makes sense to me now. Many thanks Aaron.