Slashdot Mirror
Cocoa Programming for Mac OS X
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 :)
Two resources I've found useful in Cocoa programming are stepwise.com and O'Reilly's Mac Devcenter.
Lies about crimes
Well, maybe not, but as a everyday user of OSX its easy to see how Cocoa apps are the future. They interact better with the OS, they seem less bloated, and they just seem tighter. Cocoa apps like Okito Composer are compelling reasons to move to X... it blows away MS Word.
"Smokey, this isn't Nam, there are rules." -Walter
You can set the mouse position through Core Graphics. No, it's not Cocoa per se, but the CG APIs can be called from Cocoa. "Direct access to memory registers" isn't required.
No it's not a "marketing thing." If you know anything about OO and Java programming, it's actually very easy to write a Swing program that uses the Aqua look and feel. And you can place Cocoa-access code in its own objects so that you can remove / change that code later.
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.
"I think there is a world market for, maybe, five computers." __ IBM Chairman, 1943 __
For those interested in learning Objective-C (assuming a working knowledge of C), look no further than
this PDF.
Slashdot's first reaction to VMware
...and it's Mac OS X Developer's Guide by Jesse Feiler. It's probably best described as "a developer's introduction." It is very broad, covering topics from the Mach kernel to the Interfact Builder. It's at least worth a look.
This page contains a list of applications that are either already Carbonized or Cocoaized or are in the process of being Carbonized or Cocoaized. Check it out at Xappeal
Support Texas Troops use TXGoogle
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 for loads of MacOS X goodness.
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.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
Read about it here
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. Originally a Next Step book, now available free (HTML/PDF) at Apple.com or thru print on demand at Fatbrain.
Lord Pixel - The cat who walks through walls
A little bigger on the inside than out
Try Fink, 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 are some common compiling problems and solutions for OS X.
Insanity is the last line of defence for the master diplomat. But you have to lay the groundwork early.
There's a free ~40 page tutorial + sample code available at http://www.areax.net that covers both an introduction to Objective-C for C++ programmers as well as Objective-C++, the new (well, recently revived) language that lets you use C++ libraries in Cocoa. Check it out! link
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.
Apple have just released the latest version of their developer toolset (probably not available for non-seed download yet) and the main new cool thing is full support for writing Cocoa apps in AppleScript (AppleScript Developer Studio).
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.
I've had two decades of programming in the C and C++ world and have only played with Objective C for a couple of months, and it's already clear that Objective C has some very powerful advantages going for it.
It has a dynamic structure that lets you do some things that cannot be done in most other OOP languages I've used. In Objective C you can reference a class or method by it's name, in a variable string if desired. You can create an object of variable class. You can have a piece of code which can examine an object of unknown class to see if it supports a particular method, and if so, call that method. You can compare a class name against an object to see if it's that class or a subclass. This is all powerful stuff.
Add to that the tools Apple provides to build interfaces, which rely on those dynamic features, and you end up with one of the fastest mechanisms for building new applications I've ever worked with. This wouldn't work well with C++ or C by itself.
Given that, I can live with the relative ugliness of the language. (And C++ has its own ugliness -- look at the template syntax... Yecch!) It's also a very easy language to learn if you know C.
Or you can sign up for a free web ADC membership and d/l the developer tools for free, although they are sometimes posted a few weeks after they are available on CD.
"Reality is just a convenient measure of complexity" -Alvy Ray Smith
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.
Moderators should have to take a reading comprehension test.
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.
Here are some more books on MacOS X / Cocoa / Carbon Programming:
.. and you can develop "X-only" applications with this)
Java: "MacOS X Java" Wiliams, Albert, Hart, Hopkins and Steinberg, Wrox press. (Just got this one, reading it now)
WebObjects 5 for Java: A Developer's Guide (With CD-ROM)
by Jesse Feiler (Paperback)
Java & ObjC: "Mac OS X Programming" by Dan Parks Sydow (got this one on order)
Mac OS X Developer's Guide by Jesse Feiler (Paperback) (this is an OK text, some good examples with ObjC & Java, but lacks a lot of detail on many Cocoa topics)
Mac OS X Carbon Developers Black Book (With CD-ROM) by Dan Parks Sydow (Paperback) (don't have this one)
REALbasic: "REALbasic: The Definitive Guide" by Matt Neuburg (good book, but only covers development with REALbasic
As far as I've been able to suss out (I haven't had a chance to play on OS X yet, but I have looked at a bunch of the developer docs), Cocoa is pretty much a relabeling of the NeXTStep API. I imagine that any code you write for Cocoa will compile fairly easily under GNUStep. In fact, the GNUStep guys are working to add a Java API (in addition to the extant Obj-C API) to match the one that Apple added for OS X.
"Whatever can go wrong, will." --Finagle's Law
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)
Let' see. Send a system wide notification to ANY application thats listening, including a dictionary (HashTable of information) NO RMI stub bullshit.. That would be ONE line of code
Publish an Object so it can receive distributed method calls from other applications ala CORBA.. (again NO stub bs, no real need to even know object type or the methods it can respond to as those can be discovered at run time. ) Ah. That would be two lines of code.
Connect to and message that object from any other app. 1 line of code (two for error checking).
Include basic printing, editing of a scrolling text object WITH control over fonts, color and automatic connection to other SYSTEM services like spell checking... NO lines of code.. it's built into the IDE.
Yep.. Very cheesy, weak ass OS.. Hardly any power. Can't do squat..
I've been using ObjC as delivered by NeXT and now Apple for about 12 years. So I WON'T take your word for it, because you don't know what the hell your talking about.
Worse than MFC.. I don't think so.. Try this with MFC, ADD a method to the Window class. No I didn't say subclass window.. add a method to the actual window class.. You can't do it. Why? Because you don't have source and C++ doesn't have catagory methods. ObjC does.
All stop here, cause I have about 50 more examples.
'The other Cocoa' eventually found a new home and became known as Stagecast Creator.
-Mark
Here's a little tidbit of info that demonstrates how completely filled with misinformation your post is:
You complain bitterly how "their hardware is cruddier [sic] each year," giving the Blue and White G3 as an example. (I won't even comment on your assertions about the B+W G3's quality).
The blue and white G3 was discontinued more than two years ago!
I could go on (and on and on...), but I won't.
All is Number -Pythagoras.
That's wrong, you're talking about the regular ObjC. If you rename all your files to .mm, you will be able to mix both languages:
class myclass { public: myclass() { NSArray *array=[NSArray array]; } };
Yes, that is an issue with dynamic typing but that comes with the complexity of your app. Today's programs are far too complex to write in assembly, but assembly can be much faster. Static typing doesn't make things faster, that's just an implementation issue.
In Objective-C's case, only the first time you send a message to another object takes some extra lookup time. From then on, it's cached. It's just like using a virtual table. Object Oriented programming was NEVER designed for speed. That's the tradeoff. If you try to make a balancing act of that of speed vs. OO, you're missing the point and wasting your time. If you need the speed, write the back-end in C (but not C++).
As ESR has said in his Python introduction piece (I think it was in there, sorry if I'm misquoting), most programs nowadays don't even need compiled speed. 90% of the stuff joe user does is I/O bound, not CPU bound. Of course you can be a really sloppy programmer and waste the CPU, but that's not the language's fault :)
Moderators should have to take a reading comprehension test.
"The NeXTStep API has been around for quite a while, and has never really had a following."
You are confusing the original Nextstep API with Cocoa, they are not the same thing. Cocoa is a modified version of Openstep, a complete rewrite of the Nextstep API. It was designed to be portable version of the Nextstep API and also fixed many of its shortcomings. BTW, it did have a small following of very high profile people, like John Carmack and Tim Berners Lee.
"When that failed, they tried to sell just the OS."
The API may never have been a huge success, but it was enough of a success to keep Next in business for 10 years. It was popular in vertical markets and in RAD shops. Next abandoned the hardware and ported the softeare to Intel hardware because customers really digged the application toolkits, but didn't want to buy the hardware.
"When that failed, they tried to sell it as an API that would run under Unix"
I am not sure what to make of this. Nextstep was always sitting on top of BSD. If you are talking about Openstep on Solaris, Sun co-developed the Openstep API and did their own version. However, Sun killed the product after Java became successful (BTW, interfaces in Java are taken from objective-c protocols, something added to the language by Next).
"...they finally managed to sell the whole ball of wax to Apple after Copeland self-destructed."
Before the Apple acquisition, Next was a profitable company, buoyed by the success of WebObjects, a framework based on EOF which was based on Openstep. Apple was originally only interested in the Operating System, but when they saw WebObjects and Next's vertical market penetration, they decided to buy the *whole* company!
(A close relationship between the chairmen of the two companies helped.)
Where did you hear this? The acquisition of Next happened because a Next employee saw that Be was offering their OS to Apple for some ludicrous amount of money and decided to pitch Nextstep as alternative. Steve Jobs did not learn about this until later when Apple became interested.
"people actually think that Cocoa is going to seduce a significant numbers of Carbon, Windows, or Linux/Unix developers -- isn't it a little late in the game for that kind of realignment?"
It's amazing that people continue to say this sort of thing. Look at some of the recent languages, like PHP, how many years old is it now? It somehow realigned enough developers. Why can't it happen to another language, like Objective C?
"why this whole thing took so long -- this isn't a new OS, it's a port of an existing one!"
First, it is basically a new OS. Nextstep was BSD 4.3 on Mach 2.5, Mac OS X is BSD 4.4 on Mach 3.0, these are very significant changes. Second, the reason it took so long was not because of Cocoa, it was due to porting Carbon and building a new driver infrastructure. Both were very daunting tasks that took many years.
As a long time NeXTStep, OpenStep, Webobjects (yes, WebObjects also uses ObjC) programmer I'd like to point out a few things about ObjC and the NeXTish frameworks, without religious bias.
ObjC was a very nice language when it first came out. For a hybrid language (object semantic hacked on top of ansi C), it is much more powerful and clean than c++, which is why I made the switch. However, it is absolutely erroneous to say that there are things you can do in ObjC that cannot be done in c++. You just have to jump through hoops of fire in c++ to achieve the dynamism of ObjC. On the other hand, it WAS a hybrid language: fundamentally still C. So it was no Smalltalk. Programmers are still fundamentally responsible for memory management (there's a refcounting scheme for helping) and this requires a high skill level. In large programs, tracking memory leaks could take time. Also, ObjC was not nearly as clean as Smalltalk in other respects. Some of the object semantics in ObjC were hacked on through the use of cpp macros. You could not stay entirely in the object world-- the facade of OO was not complete. In dealing with the low level of the runtime you would have to handle c structs.
The state of the art moves on. But ObjC doesn't, for the most part. ObjC has some features that Java is lacking: method forwarding, posing, categories, etc. Still, there are no circumstances under which I would now choose ObjC over Java. Why? Advantages of Java over ObjC:
- Automatic memory management.
- No direct memory access. Because of this, I can feel comfortable working with junior programmers. Not the case under ObjC.
- Only Objects and a few sensible primitives. No other data types.
- Unicode based.
- Strongly typed (yep, it's an advantage, good ObjC programmers type as much as possible anyhow)
- Exception handling first class citizen of language (it's hacked on in ObjC)
- Fully integrated threading model (much more difficult on ObjC)
- multi-platform. I know java isn't perfect in this respect, but ObjC and the Foundation framework was much, much worse. Basic things like threading could work differently on Solaris vs. windows under OpenStep Foundation.
- multi-vendor.
- A tremendous number of third party tools.
- A tremendous amount of third party information.
I can go on and on. I really don't see the point of Apple pursuing Cocoa, except as far as they are locked into it for legacy reasons.
For the record, my suggestions and contributions were simply that I helped correct typos and programming example errors, and I also helped out with Apple history/factoids.
I recently conveyed this fact to the powers that be, and I apologize for not stating this from the beginning. I didn't think it was a conflict of interest. In fact, the only reason I got involved and offered to help Aaron out was because I enjoyed the book so much (I took Aaron's class at the Big Nerd Ranch, and this is the coursebook!)
Again, I wasn't involved directly in writing the book, I just helped polish its' appearance.