Slashdot Log In
Cocoa Programming for Mac OS X
from the mixed-barrel dept.
Intro to Cocoa
If you're interested in programming for Mac OS X, you've
definitely heard of Cocoa by now. Cocoa is the name of the library of
frameworks that gives you the ability to write advanced applications with ease. The Cocoa frameworks enable you to perform tasks that used to take a decent amount of code and implement it in a very straightforward manner. The hardest thing about learning Cocoa is that because it's so simple, it takes some getting used to.
Until today, there was only one book if you wanted to learn Cocoa. That book is Learning Cocoa , which is published by O'Reilly and written by Apple Computer, Inc. The new kid on the block is Cocoa Programming for OS X, which is published by Addison-Wesley and written by Aaron Hillegass of the Big Nerd Ranch. With two books out, Cocoa programmers now have an actual choice of which book to buy. Which brings us to the point of this review -- which book is better?
Is it really O'Reilly?
Since Learning Cocoa was out first, I'll start with my
analysis of it first. When I heard that O'Reilly was going to start publishing
OS X programming books, I was stoked. O'Reilly books have historically been amazing -- very complete and straightforward sources that any programmer would be proud to have in his or her arsenal of knowledge. Unfortunately, Learning Cocoa falls short of the O'Reilly tradition, and makes me wonder if O'Reilly actually supervised the printing of this book.
There are some good points about the book. It was the first and only Cocoa book, so when I got my copy back in May, I was looking forward to learning the language. It does provide some good examples on how to write Cocoa applications, which allows one to dive straight into Cocoa programming. The introduction to Cocoa is really good -- it gives a very in-depth description of Object-Oriented and Cocoa program design, which I really like. Additionally, it gives a very good background to the concepts and techniques of using Cocoa.
However, there is a real problem with this book. This book reads more like it was meant to be an internal reference at Apple, rather than a book for the beginner. Another problem is that the layout and order of the content is confusing. Unlike past O'Reilly books and other quality programming books, it seems like this time they took a bunch of internal technical documents on Cocoa, and sent them to the binding machines without further editing. That the book credits "Apple Computer, Inc." as the author provides good evidence for my theory.
The heart of the problem is that the reader has to really dig and explore through this book to find that info that he or she wants. When learning a new language or programming concept, a book should be easy to follow and it should allow the reader to focus on learning the actual concepts, and not having to figure out the flow of the book.
Aaron hits a home run
The "flow" statement is a perfect segue into my analysis of
Cocoa Programming For Mac OS X. Right away, I could tell that I was going to like this book. The author, Aaron Hillegass, wrote this book like he is a friend
speaking directly to the reader -- he takes you through each concept like he is right there with you. This book teaches you Cocoa by specifically having you write applications, and in each new chapter, you add new features. As you add each new feature, you'll learn an important Cocoa concept.
O'Reilly's book also has the reader write applications and add features, one by one, but it does so in a very sporadic way. I was never really sure what the purpose of adding a certain method was, whereas with Aaron's book, each chapter is focused on an ordered and very specific concept, making it very clear what I was about to learn, and why.
Another part of this book that I really appreciate is the chapter on Objective-C. In just one chapter, I understood Objective-C. You must already know C and at least one object-oriented language (like C++ or Java,) but after reading this chapter, you will be able to write Cocoa applications in Objective-C.
This book comes with an online counterpart, powered by Techstra. Techstra is an online engine that allows you to enter any page of the book and get "extras." The extras include examples not in the book, solutions, errata, and even input from readers. It's very cool and very helpful.
A final and very strong point of Aaron's book is that it reflects the latest update of the Mac OS X development tools, Project Builder and Interface Builder. Apple just updated the development tools to version 10.1, substantially changing the UI and functionality, and the latest version is reflected in Aaron's book.
Conclusion
It's clear to see which book I'm giving the nod to. I know
it appears like I'm being biased towards Cocoa Programming For OS X, but if can get to your local bookstore and actually compare the two books side by
side, you'll see why I'm so enthusiastic about Aaron's book.
I think having both books is a good choice, as the O'Reilly book does offer very in-depth information, which is useful once you learn Cocoa using Aaron's book. If O'Reilly changed the title to After Learning Cocoa, I think my perception of the book would be different.
Cocoa allows programmers to write powerful applications in a very short amount of time. I am amazed at the power and simplicity of the Cocoa frameworks, and can't wait to see what myself and other programmers end up creating in the future. I'm sure other books will come out in the future, but for now all we have is two. The one I'd recommend is Cocoa Programming for Mac OS X, but you already knew that. :)
You can purchase this book at Fatbrain. Want to see your own review here? Read the book review guidelines first :)
other Mac OS X programming resources (Score:3, Insightful)
Other (non-book) resources. (Score:4, Informative)
Two resources I've found useful in Cocoa programming are stepwise.com [stepwise.com] and O'Reilly's Mac Devcenter [oreillynet.com].
Wondering which was first... (Score:3, Insightful)
Re:Wondering which was first... (Score:4, Interesting)
Cocoa was a multimedia authoring environment for kids. Apparently, a pretty interesting one too- a object-oriented IDE for kids, believe it or not. I think Alan Kay had something to do with it while he was still with Apple.
How I long for the days when Apple would do interesting research! Am I the only one who misses it? (the original) Cocoa, Dylan, MacLisp- a lot of interesting things that they seem to have given up on.
Actually, it looks like your Cocoa came first- they started calling it that around 1990, it appears.
Link:
http://hometown.aol.com/schmucker1/index.html
Parent
Re:Wondering which was first... (Score:2)
Actually, what came before both of them, I imagine, was Apple's long-lost *other* Cocoa. Cocoa was a multimedia authoring environment for kids.
Yes, it did come first, but it's not lost! That project was spun off from Apple into the company Stagecast [stagecast.com]. Apple retained rights to the original name. Actually, the earlier name for the project was KidSim [acm.org]. The prime movers for KidSim were David Smith and Alan Cypher. Larry Tesler was Stagecast president. Both Smith and Tesler originally came from Xerox PARC.
Re:Apple did not make MacLisp (Score:2)
http://www.digitool.com
Apple Developer Connection (Score:5, Interesting)
Cocoa will replace Ecstasy... (Score:4, Informative)
Re:Cocoa will replace Ecstasy... (Score:2)
It seems OmniWeb has caught up. Once again, it is my primary browser. And damn- I forgot how sweet pages look in OmniWeb!
What was my point again? Oh yes. Cocoa has no intrinsic advantages as far as what the user sees- especially considering that Services are being largely ignored. The advantage comes to the developer, who is allowed more time to work on important things in their app, rather than pidly things. But Composer could've been written in Carbon or MFC- it just would've taken a lot longer.
...and this is coming from me, a NeXTie, who still has a NeXT cube (working MO drive!) and ran OpenStep 4.2 and Rhapsody DR2/x86 on his PC until I finally just bought a Mac a year.5 ago. So, if anything, I'm positively biased toward the Cocoa API.
Open Source Cocoa (Score:2, Funny)
For each cup:
Mix 2 tbs cocoa powder with 2 tbs sugar.
Slowly add 8 oz milk while stirring.
Heat on stove, but do not allow to boil!
Add 1 shot of either orange liquer, creme de menth, or Irish Cream.
If you don't like those froo froo 'liquers' but instead prefer real liquor, add 1 shot Southern Comfort Bourbon or Rum
I do NOT reccomend the o'reily book (Score:2, Interesting)
Re:I do NOT reccomend the o'reily book (Score:2)
Not sure why anyone would spend the almost $40 cover price for this book- seemed to have the same content as the Learning Objective-C PDF that Apple has on their site!
At least I got a few posters with the class hierarchy on them.
java (Score:4, Informative)
I find that it's actually very good for prototyping complex GUI apps. And the reason there isn't much information about it is that the Java API is simply a name-for-name bridge to the Objective C api. The objects (almost all of them) are provided in Java as bridges to the actual Obj C objects.
They essentially did the Visual J++ thing but they did it __right__. Their classes are in addition to the Java 2 platform, not a sneaky replacement for it. I personally wish __more__ vendors would provide platform-level access in bridged Java classes.
Objective-C Tutorial and Reference (Score:5, Informative)
this PDF.
"There is another..." (Score:3, Informative)
So... (Score:3, Interesting)
But you'd think it's Unix, too, so it potentially steals market share...
Re:So... (Score:2)
Apple created an Objective-C/Java bridge to allow programmers to access Objective-C objects and classes from Java. An external, native library, accessed through JNI funkiness. A person not running Mac OS X just doesn't have the Cocoa library, do they cannot use apps that depend on it.
MS fuddled with the spec, and the VM, making what could've been standard Java apps not run on other platforms and virtual machines.
So Sun couldn't object on the same grounds- unless interfacing with any native library is grounds enough for you. And if it is, why not stop the people making GTK+ bindings for Java too?
Re:So... (Score:3, Insightful)
The fact is that Sun had no problems with MS making it easier to tie Java apps to Windows via J/Direct.
What they objected to was MS leaving out bits of functionality by obeying the letter of the spec and not the spirit (RMI support, for example, required accessing an FTP server at MS that would change from time to time).
Apple has been providing ways to bridge Mac OS calls and Java for about 4 years. Sun has never objected, because Apple also implements the Java spec to aching accuracy. They just add extra stuff on top of it.
-jon
Carbon and Cocoa Application Lis (Score:2, Informative)
Be careful! (Score:3, Informative)
IMO, there's a MUCH better book on Carbon programming out now, which is about 1.75" thick and darned heavy - I think it's called "Carbon Programming" or vice versa... D'ohhh.
Keep in mind, too - what the difference is between Cocoa and Carbon. The former being Objective C (object oriented and much like C++) and the "real deal" for MacOS X programming, and the latter being based on C. The benefit of the latter being that it will run on either MacOS 9 or X. Then again, there's higher level languages that you can use like RealBasic or Applescript - or hell, Perl. :)
Be sure to check out Everything Mac [everythingmac.org] for loads of MacOS X goodness.
Python for Cocoa (Score:4, Interesting)
Even if you don't favor making your releases in Python few people disagee that Python is great for rapid prototyping.
If you are interested in helping out visit the sourceforge project [sourceforge.net] where work is just beginning on a rewrite to take advantage of Python 2.2's new class/type system.
Idiots keep attacking Objective C 's syntax (Score:5, Insightful)
What they mean is it doesn't look like C and C++ and Java.
Of course, how it looks has no bearing on how useful a language it is (heh, think Perl
Who cares what the syntax for calling a function is? So long as its not 3 pages of code its irrelevant.
Do we see any insightful comparison of the truly powerful language features from these people? Do we see discussions of how C, C#, C++, Java and Obvjective-C's approach to types and bindings work? How they support dynamic behaviour?
eg, I'm prepared to state that Objective-C makes generic types unnecessary, whereas C++ relies on them and Java is introducing them (slated for JDK 1.5). This is a good thing in C++, will be a good thing in Java, and I expect to see them in C# one day, because of commonality between how these languages are defined. Objective-C doesn't need them, it has another solution, more akin to Smalltalk.
We don't see this sort of comment (shallow though my example is) from most of the posters here because frankly all that they're experienced enough to comment on _is_ the syntax.
Even all that said - the features of the language pale into insignificance next to the quality of the class library. Java is nothing without the java.* and javax.* classes, C# is useless without the
This is a review of a book about Cocoa, not Objective-C. The class library, not the language. The class library will dominate any concern over the language used to program it. Learning a language takes days (or weeks if its something completely new to you like your first declarative functional or logical language). Learning a class library can take months or years (depending on the size).
Do yourself a favour and learn some more languages. Learn about languages. Use real class libraries. Then open your big mouth!
There is another new book out there (Score:2, Informative)
Read about it here [wrox.com]
Objective-C - Apple give away whole free book (Score:5, Informative)
If you want to know more about objective c, or to prepare before reading the books above, or to gain more depth of understanding of the language if the chapter or so spent in the above books doesn't explain enough, then look no further than this:
Object Oriented Programing and the Objective C language [apple.com]. Originally a Next Step book, now available free (HTML/PDF) at Apple.com or thru print on demand at Fatbrain.
Re:Objective-C - Apple give away whole free book (Score:2)
Another free online tutorial (ObjC AND ObjC++) (Score:2, Informative)
GNUstep (Score:3, Interesting)
Re:GNUstep (Score:4, Informative)
Parent
You see it coming, don't you? (Score:4, Troll)
What about Apple's other Cocoa? (Score:3, Interesting)
Re:What about Apple's other Cocoa? (Score:3, Insightful)
It's pretty unfortunate too, it was a great way to write simple little apps. I wrote a whole Mendelian genetics breeding simulation (which I still have somewhere), and I have a couple of books that have pictures and descriptions from tons of little programs people wrote. It wasn't meant for serious work, but could make some nifty little demos very easily. Great way to get kids programming. I've thought repeatedly about doing a free version for linux, but it's a lot more work than I have time for. Still, it'd be a very worthy project.
Re:Why objective C? (Score:2)
aside from that, calling Objective C a "kludge" while suggesting C++ doesn't make much sense if you think about it.
have you ever even used Objective C? it's really quite nice, and you can program in ANSI C on an Objective C compiler and it's no big deal.
Re:Why objective C? (Score:2)
Uh, the same is true of C++.
calling Objective C a "kludge" while suggesting C++ doesn't make much sense if you think about it.
Sure, this is true. They are both C + OO kludged in.
So, Objecive-C and C++ are both backward compatable, OO kludges of C.
You haven't made much of an arguemnet for either one over the other.
OTOH, Objective-C is used by . . . Apple. C++ is used by "everyone" (I suspect this includes Apple).
Bottom line is that there is no rational reason to use Objective-C. Clearly this is a case of Not Invented Here on Apple's part. (AFAIR Objective-C is a NeXT thing, but six of one, half a dozen of the other; it's all Jobs.)
-Peter
Re:Why objective C? (Score:5, Insightful)
You have no idea what you are talking about. Cocoa could not be done in C++. (Yes, Turing equivalence, I'm talking in practical terms here.) Cocoa depends on a dynamic runtime for much of its power, which C++ does not have. Simple example: given the name of a class in a string at runtime, instantiate an object of that class. One line in ObjC, not possible in C++. Another example: given an arbitrary object and the name of a method, determine whether the object has a method of that name, and if so call it. Trivial in ObjC, not in C++. These dynamic capabilities are used throughout Cocoa, and that is why a dynamic language such as ObjC or Java is required to use it.
Parent
Re:Why objective C? (Score:3, Informative)
Bottom line is that there is no rational reason to use Objective-C. Clearly this is a case of Not Invented Here on Apple's part.
I'm not a particular fan of either language (C++ or Objective-C), but the NIH accusation is simply false.
Objective-C was invented by Brad Cox in the mid- or early- 80s, and was intended to bring Smalltalk-style capabilities to C. It was later adopted by Next. Since they now have tons of legacy code in Objective-C, they have a strong rationale to continue supporting it.
Re:Why objective C? (Score:3, Interesting)
One of the big problems with writing GUIs in C++ is that the type system gets in the way. The kludges neccessary to support a GUI system on C++ are infamous. Most systems resort to macros. GTK-- uses templates. QT uses a preprocessor and language extensions.
Re:Why objective C? (Score:3, Informative)
Then your opinion is worth much less than those of us who have. Objective-C is more flexible, powerful, and easy to use than C++. Cocoa could not be done in C++ because it lacks the dynamic runtime of Objective-C.
Re:Why objective C? (Score:3, Interesting)
Re:Why objective C? (Score:5, Informative)
C is a very nice, compact, clean language. People have historically abused it and produced ugly code, but for a well disciplined programmer, C's a dream. Except that it's not Object Oriented.
C++ was designed by committee. Its most fundamental spec is that it is insanely strongly typed. Templates are a hack to bring dynamic programming to a strongly typed environment. Exceptions are a hack to provide messaging in an environment that doesn't allow object A to talk to object B without knowing what the type of B is.
Objects that communicate with each other is the most fundamental thing in object oriented programming. You can't drop foreign objects into an OOP system when that system needs to know the exact type of those objects- prepare to start editing code. Great code re-use. C++ does NOT offer code re-use anymore than C does.
You like Qt's slots mechanism? They're a hack to give C++ something that every other OO language (inc. java, but not easily) can do naturally, make two objects talk to each other without knowing their type!
Objective-C is a dynamically typed object oriented programming language, which is a much better setup for OO programming. There's only one core syntatic addition to C, and that's to support OO programming. Not the billion-and-one keywords and obtuse syntaxes that C++ is full of (just how do you overload that operator again?). The syntax you describe is the best part. Compare this code,
object->runProcess(processType, duration);
[object runProcess:processType untilDate:time];
Not the greatest example, but the point is that you focus on the messages that the objects are sending to each other (which are very descriptive in Obj-C), not the types of the objects (which in many cases in OO programming, is irrelevant, unlike procedural programming). Compiler warnings of 'unrecognized selector' (unrecognized method) are more valuable than unknown type.
The sad thing is, I didn't think there was much wrong with C++ until I started using Objective-C several years ago. I just thought, that's the way OO programming is. Take a stab at smalltalk (www.squeak.org), and you'll see just how different things can be.
Parent
Re:Why objective C? (Score:3, Informative)
Er, sort of. There is one new "call syntax", which includes new syntax for unordered arguments as well as calling through an object. There is one new preprocessor macro to replace (or at least augment) #include. There is a whole new declaration syntax for objects as well. That is more like three things. And it may be as many as eight.
Now that doesn't compare to C++ which is described in less detail by a book 5 times as thick as K&R C, but it is a little more then one change.
(and having used both, I miss some of the C++ stuff, but not as much as I'll never mind is gone)
This is still true, sort of (Score:3, Informative)
the mac api did have a c binding but you had to specify a pascal binding to all your functions
To the extent that this is sort of true, it is still true. Pascal has a different stack convention from the one in C. The convention that Pascal uses was shared by most other languages at the time, but C originated as a system language. C is organized such that functions like printf could take a variable number of parameters using a kludge involving pointing directly to the stack.
However, C and C++ compilers for the Mac all accept the "pascal" keyword, which is included in all the header files for the API. Besides that, you can ignore it, except in the special case where you need to pass a pointer to the API for a callback function. Then you need to declare your function as pascal, too. You have never had to declare all your functions pascal.
Also, the majority of the API calls are not bindings in the strict sense of the word. They use compiler extensions to produce inline traps in the code.
Re:Easy? Powerful? (Score:3, Insightful)
I'd say thats the reason, why Apple didn't include such functionality into the API.
Re:Setting the mouse position (Score:2, Informative)
Re:The Joy of Objective-C? (Score:3)
Re:The Joy of Objective-C? (Score:5, Insightful)
I for one am glad Apple stuck with ObjC. It's good to see that at least one company has the balls to choose what is good rather than what is popular. I was scared for a little while- Apple made WO5 Java only, and I'm glad they didn't pull that on Mac OS X as well.
As far as other languages, you can program OS X in a bunch of them. Quite a few languages have Carbon bindings, and there's no reason you couldn't write a binding for you favorite language- Carbon is just C. If you're already using another language, you don't really need a binding to Cocoa, rather than Carbon.
Python, and F-Script both have Cocoa bridges.
Parent
Re:The Joy of Objective-C? (Score:2, Informative)
This is a very cool thing. For people who haven't heard of / used AppleScript before - it's a HyperTalk-type language (i.e., very verbose, almost natural language) that can be used to externally control and script many Mac OS applications. You can now basically throw together applications very quickly that have complex UI elements and interact with other applications and system components.
A neat feature is the ability to mix-and-match ObjC and AppleScript in the same application, so you can rapid prototype in AppleScript and then code complex sections in ObjC.
Hats off to Apple for throwing so much effort into a (IMHO) much overlooked technology. AppleScript is the key piece in a lot of custom workflow systems, and now a must-see for those who miss the old HyperCard days.
Re:Where are the compilers? (Score:2)
Re:Where are the compilers? (Score:2, Informative)
Try Fink [sourceforge.net], it's got, among a mass of other stuff, Make. OS X comes with a version of gcc installed called cc. Fink will probably get you all you want other than that. Here [forked.net] are some common compiling problems and solutions for OS X.
Re:Where are the compilers? (Score:4, Informative)
Parent
Re:NeXT Step was 500% better than this new Crap (Score:4, Insightful)
First up, let me cover a few of your 'quickie' style complaints. You talk about how Apple screwed up 'Carbon 1.0', then never shipped it. Isn't this a good thing? Would you rather they release something worse than Windows 95?
Second, you talk an awful lot about speed issues with OSX and Cocoa. I suppose you haven't used 10.1. OSX 10.1 is amazing. Coupled with Office v.X (I'm a student, need Office compatibility or I don't pass my classes) OSX 10.1 is just stunning in speed, stability, and functionality. Granted, OSX may seem a bit bloated on the surface, but I decided after ten years of using Wintel that I'd trade bloat for stability, a choice Microsoft never offered.
Was NeXTStep awesome? Sure, seemed like it was to me anyhow. But back then, you didn't have the newer requirements of being out-of-the-box simple, and supporting so many hundreds of standards to make everything run as transparently as possible. Back in the days of NeXT, you had a NeXT if you were a developer, not an end user. Keep in mind, as a lot of people fail to do, that Apple is a company geared toward the consumer market, not simply the developer market.
Are there flaws? Yes. Are most of the flaws you pointed out accurate representations of the issues facing the Apple userbase? Hell no.
In November, I bought my first current Mac after only having an ancient '030 simply to say I had one. When I was younger, I felt that Apple had great hardware, but a lousy OS. Now, after X.1, I'm convinced that Apple has a far superior consumer grade OS than anyone else with market share. And simply by it's nature, it's also the best OS out there for developers. After all, you didn't have to shell out $2500 for a copy of the development tools, did you?
Parent