Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cocoa Programming for Mac OS X, 2nd Edition

Posted by timothy on from the add-water-and-stir-then-sift-for-marshmallows dept.

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.

13 of 162 comments (clear)

  1. Differences from first edition by tenuki · · Score: 3, Interesting

    How different is this one from the first edition?

    1. Re:Differences from first edition by Art+Tatum · · Score: 4, Interesting
      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.

  2. THAT is an old story... by argent · · Score: 4, Interesting

    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.

    1. Re:THAT is an old story... by dasmegabyte · · Score: 4, Interesting

      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.

      --
      Hey freaks: now you're ju
    2. Re:THAT is an old story... by argent · · Score: 1, Interesting

      I've been writing software professionally since 1978, I've been managing computer systems and computer networks since 1984, and I've written safety-critical (as in, if I screwed up people would die) software for railroads and the oil industry. I think it's fair to say that I know how programs work.

      And, well, there's this thing called a "subroutine library" that solved this straw man you've built up. You're a smart guy, I'm sure you've heard of them: you write it once, use it from two places.

      As for "never automatically execuite something that might be unsafe", well, if a document (say a web page) wants to open a file, a new network connection, even a new window on the display... it shouldn't be allowed, right? Imagine trying to use a local resource, like a text editor, with those restrictions! "TextEdit has tried to open a new window, should it be allowed?"...

      This isn't a theoretical question, by the way. Try installing Paranoid Android (a fine program by Unsanity) and then opening a document in Butler (a fine application by Peter Maurer). "Butler is attempting to open a "file:" URL... huh, how about that? :)

  3. No xcode? by tf23 · · Score: 4, Interesting

    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)

    --
    http://slashdot.org/~tf23/journal
    1. Re:No xcode? by BasilBrush · · Score: 2, Interesting

      Is XCode really that different from Project Builder and associated apps that came before? I've got the first edition of this book, that I worked through with Jaguar. Would I need to get the second edition too if if I wanted to use Xcode, or are the differences fairly minimal?

  4. MVC Shite!... by tonywestonuk · · Score: 2, Interesting

    I'm a Java programmer, and used to program Mac's in the system 7 era. So, I thought I'd take a look at using the Cocoa API. There is a java-cocoa tutorial on apples developer site, so I fired up x-code / Gui Builder and jumped in.

    After spending a good few hours understanding how to develop in this environment,I honestly think that the effort and pain needed to put together this simple currency converter app, is not worth it.... I could have done the same thing in any other environment (Swing/VB/ old Res-edit & Pascal), in minutes... What is the big deal surrounding MVC for a GUI?

    Tell me, Can I make a dynamic screen, that adjusts itself based on the data inside it (AKA Java Swing).... What about creating reuseable, database linked components, that can be dropped into any screen in a line of code?

    1. Re:MVC Shite!... by jamesmrankinjr · · Score: 4, Interesting

      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

      --
      XML Tools for Mac OS X
    2. Re:MVC Shite!... by Ilan+Volow · · Score: 3, Interesting

      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.

      --
      Ergonomica Auctorita Illico!
    3. Re:MVC Shite!... by Archibald+Buttle · · Score: 2, Interesting

      Firstly as other people have said there is no surprise in the fact that you could program a currency converter app in another environment. The two main reasons are that you are not yet familiar with XCode and Interface Builder (IB), and secondly that the Currency Converter example is overdesigned to demonstrate the principles behind MVC.

      As for the dynamic screen that adjusts itself to the data inside it, of course you can do this. This has always been fairly easy to accomplish, but 10.3 adds a concept called "bindings" which builds on the MVC paradigm to allow UIs to automatically update whenever the underlying data model changes.

      As for re-usable database linked components, of course you can do that too, and if you do it right you don't need to write any code to reuse them. WebObjects is designed to do that kind of stuff, although of course there's a license fee involved. There's a few other frameworks available to for this which interface with Cocoa.

  5. Re:Same for GnuStep it seems... by Art+Tatum · · Score: 3, Interesting
    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.

  6. Reference by Ann+Coulter · · Score: 3, Interesting

    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.