Cocoa Programming for Mac OS X, 2nd Edition 162
| 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.
Differences from first edition (Score:3, Interesting)
THAT is an old story... (Score:5, Interesting)
After all, this is the same basic design flaw that led me to ban IE and Outlook at work about
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.
No xcode? (Score:5, Interesting)
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)
MVC Shite!... (Score:2, Interesting)
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?
Re:THAT is an old story... (Score:5, Interesting)
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.
Re:Same for GnuStep it seems... (Score:4, Interesting)
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.
Re:THAT is an old story... (Score:2, Interesting)
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?
Reference (Score:4, Interesting)
Re:No xcode? (Score:3, Interesting)
Re:Differences from first edition (Score:4, Interesting)
It's still in development, and there isn't a graphical builder for it yet, but it's very promising.
Re:MVC Shite!... (Score:5, 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
Re:MVC Shite!... (Score:4, Interesting)
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.
Re:MVC Shite!... (Score:2, Interesting)
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.