Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Cocoa Programming for Mac OS X, 2nd Edition

timothy posted more than 10 years ago | from the add-water-and-stir-then-sift-for-marshmallows dept.

Programming 162

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.

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.

cancel ×

162 comments

Sorry! There are no comments related to the filter you selected.

first post (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#9261274)

first post

Mac OS X (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#9261277)

... is gay. :-)

You are such a winner! (-1, Offtopic)

Mz6 (741941) | more than 10 years ago | (#9261285)

n/t

mmmmm (-1, Troll)

afdsfsdafsdaf (454138) | more than 10 years ago | (#9261290)

MacOroni and cheese....

Mmmm... Cocoa (2, Funny)

skzbass (719269) | more than 10 years ago | (#9261297)

in realated news Dutch cocoa maker Godiva comes out with a book on properly programming your microwave to make the perfect drink.

Re:Mmmm... Cocoa (1, Funny)

Anonymous Coward | more than 10 years ago | (#9261585)

Of course, being naked on horseback is a requirement for good cocoa.

Re:Mmmm... Cocoa (0, Offtopic)

VanillaCoke420 (662576) | more than 10 years ago | (#9261902)

Yesterday was the rerun of that Spin City episode with Alyssa Milano as the Mayor's daughter. She was riding a horse naked too. :)

Re:Mmmm... Cocoa (0, Offtopic)

acey72 (716552) | more than 10 years ago | (#9261882)

Grrrrr - Godiva are Belgian, not Dutch!!!!

In case anyone is wondering.. (5, Informative)

AKAImBatman (238306) | more than 10 years ago | (#9261302)

...he mentioned Java because there's a Bridge mechanism in OS X that allows Java code to call ObjC code, and ObjC code to call Java code. I've used it myself and found it to be an effective way to write Java programs that are native to the OS X platform. Be warned, however. Differences in the way ObjC and Java handle objects causes quite a bugs. Not everything can be 100% mapped, so you'll find yourself writing some ObjC anyway.

Re:In case anyone is wondering.. (-1)

Anonymous Coward | more than 10 years ago | (#9261420)

..he mentioned Java because there's a Bridge mechanism in OS X that allows Java code to call ObjC code, and ObjC code to call Java code. I've used it myself and found it to be an effective way to write Java programs that are native to the OS X platform. Be warned, however. Differences in the way ObjC and Java handle objects causes quite a bugs.

Yeah "quite a bugs" like erasing your whole User folder [kingsofchaos.com] when you try to use the Java.net.* classes.

Re:In case anyone is wondering.. (1)

AKAImBatman (238306) | more than 10 years ago | (#9261643)

Yeah "quite a bugs" like erasing your whole User folder when you try to use the Java.net.* classes.

Err... quite a few bugs. Can't say I've seen it erase any folders, though. Should I ask why you have a link to some game site, or should I just tell moderators to mark you as -1 Troll?

Re:In case anyone is wondering.. (1)

metamatic (202216) | more than 10 years ago | (#9261540)

I was wondering why he mentioned C++, actually.

Re:In case anyone is wondering.. (1)

AKAImBatman (238306) | more than 10 years ago | (#9261658)

I was wondering why he mentioned C++, actually.

That's a good point. A C++ app would use Carbon instead of Cocoa.

Re:In case anyone is wondering.. (3, Insightful)

BasilBrush (643681) | more than 10 years ago | (#9261744)

Presumably as few programmers have Objective C experience. At least if you know C++, you know the C parts of Objective C, and hopefully have some OOP experience.

Re:In case anyone is wondering.. (2, Informative)

Abjifyicious (696433) | more than 10 years ago | (#9262123)

Well, it is possible to mix Objective-C with C++ - the result being an abomination known as "Objective-C++" [apple.com] - but it's not something you typcially need to know about unless you're trying to do something weird, like use a C++ library from within an Objective-C program...

Re:In case anyone is wondering.. (1)

golgafrincham (774723) | more than 10 years ago | (#9261701)

...he mentioned Java because there's a Bridge mechanism in OS X that allows Java code to call ObjC code, and ObjC code to call Java code

sounds interesting. does it work like jni ore more like using the python - c bridge?

mmm... (-1, Troll)

Anonymous Coward | more than 10 years ago | (#9261308)

Why don't they ever think about these things...Who wants to eat apples and chocolate togeter?

Idiots.

Re:mmm... (-1, Offtopic)

bobalu (1921) | more than 10 years ago | (#9261343)

Well, it's not as good as a beer and a Snicker's Bar, that's for sure.

Differences from first edition (3, Interesting)

tenuki (704832) | more than 10 years ago | (#9261314)

How different is this one from the first edition?

Re:Differences from first edition (5, Informative)

skarth (184192) | more than 10 years ago | (#9261422)

This version is written for Panther, and thus covers the new features of Cocoa that were introduced in Panther, such as bindings.

Re:Differences from first edition (4, Funny)

Roofus (15591) | more than 10 years ago | (#9261430)

This one goes up to 11.

Re:Differences from first edition (1)

drauh (524358) | more than 10 years ago | (#9262114)

Don't you mean it goes up to XI?

Re:Differences from first edition (5, Funny)

lacrymology.com (583077) | more than 10 years ago | (#9261477)

"How different is this one from the first edition?"

Brushed Metal pages?

-m

NSController (5, Informative)

Ilan Volow (539597) | more than 10 years ago | (#9261698)

Among the things he adds in the 2nd edition is a piece on NSController, a neat feature that saves you a ton of time you'd otherwise spend creating GUI glue code between your view and controller layers. He also includes some info on creating frameworks, which is kind of hard to come by in most mac programming books.

Re:Differences from first edition (5, Informative)

for_usenet (550217) | more than 10 years ago | (#9261844)

The chapter on GNUStep is also new. This is of interest to me, as I do a lot of work on Linux, but have been wanting to do some OS X coding as well. I've heard that GNUStep still has a "bit" of catching up to OS X's implementation of OpenStep. But with applications like GNUMail, maybe this isn't all hopeless, and might actually be useful.

Re:Differences from first edition (4, Interesting)

Art Tatum (6890) | more than 10 years ago | (#9262053)

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 [gnustep.it] . 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.

Other good books are... (5, Informative)

Space cowboy (13680) | more than 10 years ago | (#9261317)

"Cocoa Applications" (excellent step-by-step guide) and "Learning Cocoa with objective C" (more focused on the language than the framework). These are both from O'Reilly and recommended by the ADC (Apple Developer Connection).

Simon

Better Than This Book? (1)

Black-Man (198831) | more than 10 years ago | (#9261687)

O'Reilly... a well respected publisher (and have bookshelf full of their titles) and Addison Wesley.. another respected publisher.

Which one to choose if you could only choose one? Thanks.

Re:Other good books are... (1)

.com b4 .storm (581701) | more than 10 years ago | (#9261714)

Learning Cocoa with Objective-C does an excellent job at easing you into programming on OS X. I bought it around a year ago, and it really helped me get up to speed on how OS X applications are written, how to use Interface Builder, etc. There's a lot of good detail on Objective-C, of course, but I'd say that's only about 50% of the content. The rest helps you understand how to hook code up to the UI, work with bundle files, and so forth.

It's a great book to start with, and anyone who's programmed before will likely not need anything beyond that and the reference documentation to build decent apps.

C++ is for the weak (3, Funny)

NeoGeo64 (672698) | more than 10 years ago | (#9261318)

Real men code everything in BASIC.

Re:C++ is for the weak (1, Funny)

Anonymous Coward | more than 10 years ago | (#9261352)

i still have a pascal compiler laying around somewhere for the apple IIe on two five and quarters... ah, here it is. anybody have dual 5.25 inch drives?

Re:C++ is for the weak (0)

Anonymous Coward | more than 10 years ago | (#9261390)

Hahah. Last time that happened to me was in a rarely taught class at a liberal arts college. Our snobol bootstrap compiler and class notes were on two 5-1/4's.

BASIC is weak (2, Funny)

millahtime (710421) | more than 10 years ago | (#9261408)

Real men code everything in assembly

Re:BASIC is weak (2, Informative)

nkh (750837) | more than 10 years ago | (#9261466)

That's what Java is all about: you can be an assembly zealot and still be platform independant with the JVM opcodes [sun.com] ;)

Assembly is weak (4, Funny)

dasmegabyte (267018) | more than 10 years ago | (#9261502)

Real men don't care WHAT the real answer is...instead, they choose one at random and beat the shit out of anyone who disagrees.

Which is why true && false == true. What, you wanna start? BRING IT ON!

Re:Assembly is weak (1)

Short Circuit (52384) | more than 10 years ago | (#9261679)

You accidentally left out a line:

#define true=false

Then your statement works out just fine.

Re:Assembly is weak (0)

Anonymous Coward | more than 10 years ago | (#9261921)

Actually, 'true && =false == true' is meaningless

Re:Assembly is weak (1)

Short Circuit (52384) | more than 10 years ago | (#9261966)

Oops. That should be:

#define true false // At which point it becones // 'false && false == false' // Which is false. :)

Re:Assembly is weak (1)

Short Circuit (52384) | more than 10 years ago | (#9261986)

Gah!

Make that...

#define true false

// At which point it becones
// 'false && false == false'

// Which is false. :)

Re:BASIC is weak (3, Funny)

Anonymous Coward | more than 10 years ago | (#9261518)

0000000: 2052 6561 6c20 6d65 6e20 636f 6465 2065 Real men code e
0000010: 7665 7279 7468 696e 6720 696e 206d 6163 verything in mac
0000020: 6869 6e65 206c 616e 6775 6167 650d 0a00 hine language..

Really real men ... (1)

burgburgburg (574866) | more than 10 years ago | (#9261649)

HAND code everything in assembly, from memory, in the dark.

While the building is on fire.

What is the world coming to? (1)

Abjifyicious (696433) | more than 10 years ago | (#9262225)

Assembly?!?

What ever happened to creating binaries from scratch in a hex editor??

Re:C++ is for the weak (3, Funny)

lacrymology.com (583077) | more than 10 years ago | (#9261438)

"Real men code everything in BASIC."

Well, you fail then... the correct answer was:

10 "Real men code everything in BASIC."
20 goto 10

-m

Re:C++ is for the weak (2, Funny)

lacrymology.com (583077) | more than 10 years ago | (#9261458)

Whoops! I fail too! :p

I meant:

10 print "Real men code everything in BASIC."
20 goto 10

-m

Re:C++ is for the weak (1)

TheRealMindChild (743925) | more than 10 years ago | (#9261616)

Who uses number lines? Plus, you need a print statement for that first line to do anything:

JumpHere:
Print "Real Men Code everything in BASIC."
goto JumpHere

Re:C++ is for the weak (1)

uberdave (526529) | more than 10 years ago | (#9261644)

Real BASIC uses line numbers. You're using some sort of pseudo BASIC that was developped by people who couldn't handle C.

Oldie but goodie (3, Funny)

Anonymous Coward | more than 10 years ago | (#9261619)

Real Programmers don't write specs -- users should consider themselves lucky to get any programs at all, and take what they get.

Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.

Real Programmers don't write application programs, they program right down on the bare metal. Application programming is for feebs who can't do system programming.

Real Programmers don't eat quiche. They eat Twinkies. And Szechwan food. (Do not go to eat Szechwan food with a group of Real Programmers unless you are prepared to argue bitterly over the last spring roll.)

Real Programmers aren't scared of GOTOs... but they really prefer branches to absolute locations.

Real Programmers don't write COBOL. COBOL is for wimpy application programmers.

Real Programmers' programs never work right the first time. But if you throw them on the machine they can be patched into working in "only a few" 30-hour debugging sessions.

Real Programmers don't write in FORTRAN. FORTRAN is for pipe stress freaks and crystallography weenies.

Real Programmers never work 9 to 5. If they are around at 9 AM, it's because they were up all night.

Real Programmers don't write in BASIC. Actually, no programmers write in BASIC... after age twelve.

Real Programmers can take the scissors off the phone cord.

Real Programmers don't write in PL/I. PL/I is for programmers who can't decide whether to write in COBOL or FORTRAN.

Real Programmers don't play tennis, or any other sport which requires you to change clothes. Mountain climbing is OK, and Real Programmers wear their climbing boots to work in case a mountain should suddenly spring up in the middle of the computer room.

Real Programmers don't do documentation. Documentation is for simps who can't figure out the listing.

Real Programmers don't write in PASCAL, or BLISS, or ADA, or any of those pinko computer science languages. Strong typing is for people with weak memories.

Another OBG - Klingon SW Quality Assurance (2, Funny)

anactofgod (68756) | more than 10 years ago | (#9261771)


* Perhaps today is a good day to die... I say we ship it."

* Specifications are for the weak and timid!!

* This machine is a piece of GAGH! I need dual Pentium (!) processors if I am to do battle with this code.

* You cannot really appreciate Dilbert unless you've read it in the original Klingon.

* Indentation?! I will show you how to indent when I indent your skull!

* What is this talk of 'release'? Klingons do not make software 'releases'. Our software escapes, leaving a bloody trail of designers and quality assurance people in its wake!

* Klingon function calls do not have "parameters" - they have "arguments"- and they ALWAYS WIN THEM.

* Debugging? Klingons do not debug. Our software does not coddle the weak.

* I have challenged the entire Quality Assurance team to a Bat-Leh contest! They will not concern us again.

* A TRUE Klingon warrior does not comment his code.

* By filing this bug report you have challenged the honor of my family. Prepare to die!

* You question the worthiness of my code? I should kill you where you stand!

* Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!

(sources too numerous to attribute)

---anactofgod---

Re:Another OBG - Klingon SW Quality Assurance (2, Funny)

jcr (53032) | more than 10 years ago | (#9261898)

Thanks for reminding me why I shouldn't hire anyone who shows up for an interview wearing a klingon insignia.

-jcr

Re:C++ is for the weak (1)

Ilan Volow (539597) | more than 10 years ago | (#9262346)

Strange. I had always been told that real men speak with a LISP.

I'll wait (4, Funny)

Bingo Foo (179380) | more than 10 years ago | (#9261325)

I'll wait for the third edition: Protocol Handler Exploit Programming for Mac OS X.

Re:I'll wait (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#9261374)

That would be a pamphlet, as opposed to the 12 volume set about Windows security vulnerabilities.

ACT UP says (0)

Anonymous Coward | more than 10 years ago | (#9261397)

We Bash Back

THAT is an old story... (4, Interesting)

argent (18001) | more than 10 years ago | (#9261482)

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.

Re:THAT is an old story... (4, Interesting)

dasmegabyte (267018) | more than 10 years ago | (#9261612)

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.

Re:THAT is an old story... (1, Interesting)

argent (18001) | more than 10 years ago | (#9261776)

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? :)

Re:THAT is an old story... (1)

dasmegabyte (267018) | more than 10 years ago | (#9262394)

And, well, there's this thing called a "subroutine library"...you write it once, use it from two places.

And this is exactly what Windows does, more or less. UN-fortunately, certain programs were told to, by default, automatically handle files using functions from these libraries -- including libraries which handle executable scripts that basically have free reign over the system. This is the problem -- not that the same libraries were used for both user functions and "teh intarnet," but that the designers foolishly allowed scripts from an alien source (such as the internet) to run uninhibited in user space.

never automatically execuite something that might be unsafe

There's a big difference between opening a text file for edits and opening a system configuration window. What Apple does is prevent casual users and their programs from making edits to system files without realizing an edit will be made...basically, by forcing the user to run in user mode and setting all important system files owned to root and with access set to 755. "Administrator" users under OS X are members of wheel, and thus can use sudo to temporarily assume root access to system files. Apple has automated this process in their installer and system preferences programs.

OS X is still vulnerable to spyware that might be piggybacking onto desired installers...but it takes more than an autoexecing script or a few mis-clicks to do so.

Re:THAT is an old story... (2, Insightful)

The Almighty Dave (663959) | more than 10 years ago | (#9262054)

Sheesh. This isn't rocket science. Hopefully Apple has some rocket scientists and won't spend the next decade patching one hole after another.

I am having a hard time following your logic. If this isn't rocket science, why do you hope Apple has some rocket scientists? Wouldn't it be better to have someone who is not a rocket scientist to deal with problems that are not rocket science?

Re:THAT is an old story... (1)

argent (18001) | more than 10 years ago | (#9262268)

I would draw a Venn diagram explaining this for you, but the margin is too narrow to hold the graphics. I will simply suggest you consider that there are more possibilities allowed by set theory than disjoint sets.

Re:THAT is an old story... (2, Insightful)

Paradise Pete (33184) | more than 10 years ago | (#9262150)

This isn't rocket science. Hopefully Apple has some rocket scientists

Well, if it isn't rocket science then what good would that do?

Good Read! (5, Informative)

Capt.Gingi (89525) | more than 10 years ago | (#9261349)

I've read several of the other Cocoa books out there and Aaron's is the only book that intelligently steps you through adopting this language and the design metaphors that Apple encourages you to adopt to build applications to best effect that leverage all the capabilities of the system foundations versus trying to do everything yourself.

The additions of covering bindings is just how to get around the new Xcode interface including the revamped Interface Builder makes this book a must read. Starting with any of the other books you'll be banging your head against the wall as what you see and what they describe in terms of many of the actions will not match the current tools.

I'm . . . (4, Funny)

Prince Vegeta SSJ4 (718736) | more than 10 years ago | (#9261400)

kookoo for Cocoa Progs

Re:I'm . . . (1)

Prince Vegeta SSJ4 (718736) | more than 10 years ago | (#9261424)

LINK [toysrgus.com]

Good Tutorial (4, Informative)

druske (550305) | more than 10 years ago | (#9261441)

I read through the first edition about a year ago, and found it to be an excellent hands-on tutorial, gradually walking the reader through the construction of increasingly complex apps. I came at the book from a strong C++ background and various Microsoft technologies, and zero experience with Mac software development, and left with a reasonable beginners knowledge of Objective-C and Cocoa. Supplement this tutorial with resources like Apple's reference material [apple.com] and the mindshare at the Cocoa developer list archives [mamasam.com] , and you'll be well on your way to developing your first Mac app.

I'm glad to see that the second edition added AppleScripting and material on implementing Undo, even if at the expense of the Java chapter. (No surprise, there: in the beginning of the first edition's Java chapter, Hillegass basically says this about programming Cocoa using Java: "DON'T.")

Same for GnuStep it seems... (1)

mariox19 (632969) | more than 10 years ago | (#9261512)

[I]n the beginning of the first edition's Java chapter, Hillegass basically says this about programming Cocoa using Java: "DON'T."

I was browsing the second edition at a bookstore (I own the first edition), and the the Java chapter seems to be replaced with a chapter on GnuStep. [gnustep.org] Maybe I'm reading it wrong, but it seems he basically has the same advice, saying something about GnuStep being announced 10 years ago and still not at a 1.0 version, and also being both difficult to install and a bit buggy.

I think he puts these chapters in his book only to answer the question, "I wonder what Hillegass thinks about coding in such-and-such."

Re:Same for GnuStep it seems... (3, Interesting)

Art Tatum (6890) | more than 10 years ago | (#9261719)

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.

I'll be programming at.... (4, Funny)

millahtime (710421) | more than 10 years ago | (#9261449)

the cocoa, cocoa cabana....

can cocoa... (1)

millahtime (710421) | more than 10 years ago | (#9261467)

Can Cocoa use the same objsect code produced in Mono?

Objective C, pshaw (1)

zx2c4 (716139) | more than 10 years ago | (#9261541)

Why did apple choose to use Objective C? Why not just use C++? What are the differences? Is objective C more like C#?

Re:Objective C, pshaw (4, Informative)

anactofgod (68756) | more than 10 years ago | (#9261709)

Why don't you Google to answer your silly question on why NeXT (not Apple) chose Objective-C over C++.

You may as well as why ID chose NeXT and Objective-C over Windows and C++ to develop the original Quake engine.

But, to save you the effort of typing "Objective C versus C++" in a Google search field, I cut & paste a short paragraph out of an article (returned by said search) printed in the Linux Journal on Sept 13, 2003 [linuxjournal.com] .

As for C#...Objective-C pre-date C# by decades. It was developed independently and comtemporaniously with C++.

---anactofgod---

An introduction to Objective-C for programmers familiar with C++ or any other OOP language.

It is a surprising fact that anyone studying GNUstep or the Cocoa Framework will notice they are nearly identical to the NEXTSTEP APIs that were defined ten years ago. A decade is an eternity in the software industry. If the framework (and its programming language--Objective C) came through untouched these past ten years, there must be something special about it. And Objective-C has done more than survive; some famous games including Quake and NuclearStrike were developed using Objective-C.

Why Should I Learn Objective-C?

Objective-C gives you the full power of a true object-oriented language with exactly one syntax addition to C and, unlike C++, about a dozen additional keywords.

Since Apple purchase Next for $400 million and Mac OS X ships with Objective-C, recycling NEXTSTEP (later called OpenStep), as well as the fact that GNUstep is delivering the rock-solid window-manager Window Maker, Objective-C is (rightly) getting more attention because it is more flexible than C++ at the cost of being slower.

In reality, Objective-C is Object C and is as close to Smalltalk as a compiled language can be. This is no surprise as Brad J. Cox added object-oriented, Smalltalk-80-based extensions to the C language.

So objective-C is a hybrid between Smalltalk and C. A string can be represented as a `char *' or as an object, whereas in Smalltalk everything is an object. As with Java (int, double,.. are no objects) this leads to faster performance.

In contrast, C++ traditionally is associated with the Simula 67 school of object-oriented programming. In C++, the static type of an object fixes what messages it can receive. In Objective-C the dynamic type of an object determines what messages it can receive. The Simula 67 format allows problems to be detected at compile time. The Smalltalk approach delays typing until runtime and therefore is more flexible.

A GNU version was written by Dennis Gladding in 1992 and then Richard Stallman took over the development. The current GNU version is derived from the version written by Kresten Thorup when he was a still a university student in 1993. He ported that version to the NeXTcube and joined NeXT.

Apple chose Objective-C for Cocoa, as NEXTSTEP was based on Objective-C. But, even if they had written it from scratch, they might have decided to use Objective-C because it is object-oriented, which is undoubtedly a must for big software projects. It extends the standard ANSI C, so that existing C programs can be adapted to use the frameworks, and programmers can chose when to stick to procedural programming and when to go the object-oriented way. C was intended to be a good language for system programming. C is fine as it allows the programmer to do exactly what she wants, all the way down to the hardware. C also keeps the gold old pointers, which can be used for efficient code.

Objective-C is simple, unambiguous and easy to learn. But most of all, it is the most dynamic language of all object-oriented languages based on C. Its dynamic late binding offers flexibility and power. Messages are not constrained by either the class of the receiver or the method selector, allowing rapid change and offering access to information about running applications.

The following is a short introduction to OOP in Objective-C, starting with the basics. Procedural programs consist of data and operations on data. OOP works at a higher level by grouping data into units, which are called objects. Several objects combined and their interactions form a program.

Re:Objective C, pshaw (3, Informative)

Jeremy Erwin (2054) | more than 10 years ago | (#9262122)

Because NextStep has always used Objective C.

The most striking difference is the message passing syntax. For instance, if "hello world" is a string,
mystring.substring(2,5);
returns "llo w" as a new C++ string, while
[mystring substringWithRange:NSMakeRange(2,5)]; returns the same content as a Objective C NSString. (NSMakeRange is a C convenience function)

Here's some code that interates through a C++ vector, invoking a method on each member.
<ecode>
for(myvectortype::iterator pos=myvector.begin(); pos !=mvector.end(); pos++)
{
pos->do_something();
}
or, more simply
for_each(myvector.begin, myvector.end(), do_something());
In Objective C, the NSArray colllection class is similar
NSEnumerator *enumerator = [myArray objectEnumerator];
id object;

while (object = [enumerator nextObject]) {
[object doSomething];
}
similarly, there's the more concise method:
makeObjectsPerformSelector:@selector(doSomething);
Objective C is also a dynamically typed language, which makes GUIs somewhat easier to write.

No xcode? (4, Interesting)

tf23 (27474) | more than 10 years ago | (#9261549)

From this review [applelust.com] 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)

Re:No xcode? (4, Informative)

clichekiller (665320) | more than 10 years ago | (#9261608)

This book does use XCode, its a typo in the reviewers review. I've just started reading it and the first thing it has me do in the first example is fire up XCode so no worries there.

Re:No xcode? (1)

xirtam_work (560625) | more than 10 years ago | (#9261638)

I agree entirely. I wanted to get started with Cocoa & ObjC only to find that every book I could find dealt with Project Builder!

Seeing as this is a 2nd edition I would have thought that they'd had time to address this by know, as Xcode was released along with Panther (10.3) and there's plenty of Panther books around nowdays.

Re:No xcode? (2, Informative)

technomancerX (86975) | more than 10 years ago | (#9261713)

You'll note the review you linked to is for the FIRST edition and this is about the SECOND edition. The second edition is revised for 10.3 which includes XCode. You can identify the second edition easily as it seems to have a scary bright yellow cover. Hit the B&N link under the review to see a photo

Re:No xcode? (2, Interesting)

BasilBrush (643681) | more than 10 years ago | (#9261889)

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?

MVC Shite!... (2, Interesting)

tonywestonuk (261622) | more than 10 years ago | (#9261557)

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?

Re:MVC Shite!... (1, Funny)

Anonymous Coward | more than 10 years ago | (#9261923)

What is the big deal surrounding MVC for a GUI?

And that, my young padawan, is why you fail.

Re:MVC Shite!... (1)

BasilBrush (643681) | more than 10 years ago | (#9261954)

When you are learning anything new, you start with small examples, that don't really use the power of the new concept. For example it might be easier and quicker to do that simple currency converter app in a procedural language than an OO language, but that doesn't mean OO "is shite". When you come to do larger apps with multiple views, then, eventually, the benefits of MVC will become clear to you. Particularly if you want to do any unit testing of the non-UI bits.

Re:MVC Shite!... (1)

jrockway (229604) | more than 10 years ago | (#9262095)

I think GUI builders lead to poorly-designed interfaces, myself. I'm writing a rather large app in java right now, and I haven't designed any of the forms. I come up with an idea for how the form should work, then I add widgets to JPanels (to group them) and add those to layouts (and can repeat). The end result is a layout that looks good when the dialog comes up and continues to look good when the user resizes it. Plus, I didn't have to deal with some other programmer's naming conventions, or autogenerated code that gets munged every time I compile, etc. If you haven't done UIs by hand, you should consider it.

Re:MVC Shite!... (4, Informative)

shawnce (146129) | more than 10 years ago | (#9262209)

I guess you don't understand very well how Apple's Interface Builder works or Cocoa (AppKit) in general. Interface Builder (IB) doesn't generate code (like most RAD tools do for other language/frameworks) it constructs real objects, connects those objects with each other and then archives that object graph to a file called a nib. Using IB you can test you interface without having to compile or building the application, simple use the live objects that you are working with (it has a test interface mode).

When your application runs the nib is loaded as needed and that object graph is unarchived.

You can implement rather complex GUIs without writing a single line of code yourself (more so now thanks to the contoller objects supported) and without any other tool generating code for you.

If you haven't really used Interface Builder and AppKit you should consider taking it for a serious spin... often their is no need to code your GUI by hand.

Also note that you can load a nib (with one or more views, etc.) and have its views inserted into the view hierarchy as needed and multiple times.

Re:MVC Shite!... (1, Informative)

Anonymous Coward | more than 10 years ago | (#9261959)

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?

If you read the tutorial, it tells you what the big deal is. The MVC stuff is a nice way of separating your logical code from your GUI code. True, it wouldn't be needed for something as simple as the Currency Converter, but then, would you rather they give a tutorial on writing an incredibly complex piece of software? Just like any class in a university, the Currency Converter program is being used to demonstrate the MVC model. By using a small, simple example to give a hands-on experience.

Tell me, Can I make a dynamic screen, that adjusts itself based on the data inside it (AKA Java Swing)....

Yes, I believe I've seen this done. And using my limited knowledge, I can think of at least one way to try it, but haven't given it a shot yet.

What about creating reuseable, database linked components, that can be dropped into any screen in a line of code?

Don't know, but I assume so. Even if you can't, why judge a language/toolkit on a feature of another specific language/toolkit? Might as well say that Lisp is the best because I can do things in one line that take mid-sized functions in other languages.

Re:MVC Shite!... (2, Insightful)

golgafrincham (774723) | more than 10 years ago | (#9262026)

geez, i'm not the only one cursing this pattern insanity nowadays.

What about creating reuseable, database linked components, that can be dropped into any screen in a line of code?

i also think that ides do make a difference (i'm trying to say that ides influence your way of coding and also your productivity. not to forget the fun). using eclipse for example is like using xwindows and, say, gnome. it takes some time until everything is configured well, but when it is, you do drop your db linked components into any frame without writing even a line of code. a company i once worked for was primilary doing frontends, mostly for databases. all widgets in the gui part are standard widgets, wrote once, wrapped in beans. so the only real work was creating a laf according to style guides and occasionally to modify some jdbc drivers for rare dbs. like oracle (man, "classes.zip" somehow works, but it is the worst jdbc driver i saw. and you have to pay much if you want their network protocol in order to write your own drivers. or you jad and sniff;)

it is also possible to ship complete ejb applications with a one (nearly one) click installer (just use the ant classes. their license allowes this and it's the best way to gain access to the os). every technology that wants to incorporate with java should not restrain that way of coding (that's the reason i use this language). cocoa does.

Re:MVC Shite!... (4, Interesting)

jamesmrankinjr (536093) | more than 10 years ago | (#9262140)

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!... (3, Interesting)

Ilan Volow (539597) | more than 10 years ago | (#9262228)

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.

Aaron Hillegass - a personal opinion (5, Informative)

anactofgod (68756) | more than 10 years ago | (#9261572)

I was an consultant for Apple back in the heady days right after NeXT acquired Apple, when Jobs was Apple's "interim CEO" (the term "iCEO" hadn't been coined yet). I had the good fortune of taking a class taught by Aaron on advanced WebObjects programming.

He struck me then as someone that falls into the category as a "Big Brain", esp wrt to training/educating on software programming. And a super nice (and patient) guy, to boot.

I'm gonna pick up this book asap.

---anactofgod---

for those of you that like openstep & linux (3, Informative)

Anonymous Coward | more than 10 years ago | (#9261580)

Here's an openstep workalike for linux, they even have "Project Builder" and "Interface Builder".

GNUStep project [gnustep.org]

useful for getting your feet wet with Objective-C (pretty good) and the *step frameworks.

Good book, but (4, Informative)

ashpool7 (18172) | more than 10 years ago | (#9261645)

This book combined with "Learning Cocoa with Objective-C" and AppKiDo is invaluable for a novice Objective-C programmer.

However...

Complete knowledge of the AppKit and the Foundation is essential to writing good Cocoa programs (To a lesser extent CoreFoundation (horribly documented!) and Carbon). There are plenty of objects I found post-facto that would have made my life easier had I known they existed. I have yet to find a single book that does this well.

Currently, the best way to start developing (and gain the kit knowledge) in Cocoa is to read these two books and then just try and develop a program, all the while stopping and searching AppKiDo for useful objects that you think may exist.

yum (2, Funny)

SKPhoton (683703) | more than 10 years ago | (#9261724)

Ah, so they have Java and Cocoa now, eh? In that case, I have just one question for you:

Cream or sugar?

Reference (3, Interesting)

Ann Coulter (614889) | more than 10 years ago | (#9261829)

I perfer Cocoa Programming [amazon.com] 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.

Re:Reference (3, Informative)

jcr (53032) | more than 10 years ago | (#9261956)

Actually, that book is by Scott Anguish, Erik Buck, and Don Yacktman. I'd recommend it in addition to, but not instead of Aaron's book. The two books have entirely different purposes.

Aaron's book is the text that he wrote for his one-week course. Anguish, Buck & Yacktman's book is more of a comprehensive reference, with a great deal of material on style and techniques that just can't be covered in an introductory text.

-jcr

Re:Reference (0)

Anonymous Coward | more than 10 years ago | (#9262104)

Way to post a link that gets you money. How honest.

No referral link in URL, try it and see. (0)

Anonymous Coward | more than 10 years ago | (#9262213)

I like to smash and bash the Amazon-sponsor-link trolls as much as anyone, but this has no referral link in it. The "ref" completely valid -- in fact, try it yourself from the main Amazon page. You'll get it.

To spot referral links, look for the string "-20" after a suspicious looking username, like "ccats-20". That's your tip-off.

Porting your apps to Mac users (1)

richmaine (128733) | more than 10 years ago | (#9261873)

"...porting your apps to Mac users..."

Interesting idea. I thought most Mac users had to be programmed in English, though. :-)

Please explain (1)

Shimmer (3036) | more than 10 years ago | (#9261922)

If you are experienced in C++ or Java programming, Cocoa development will seem familiar enough. Objective-C is used throughout the book.

Are you saying that familiarity with C++ or Java is sufficient to learn Objective-C with no further effort? Or perhaps you're saying that the book teaches me how Objective-C along with Cocoa?

Without some sort of clarification, the two sentences above seem rather contradictory.

Re:Please explain (1)

BasilBrush (643681) | more than 10 years ago | (#9262010)

The book does indeed tech programming in Obj-C as well as Cocoa, but only at the level of the differences from other OO languages. Hence the prerequisite for C++ or Java. I do C++ and had no problem picking up enough Obj-C from this book to get by. But it's probably too advanced for someone who's not already up to speed with OO GUI programming of some sort.

Soungs good, but not on Safari... (1)

SuperKendall (25149) | more than 10 years ago | (#9262050)

It does not look like even the first edition of this book is on Oriley's Safari site (they do have other Addison-Wesley books), which is very unfortunate. Hopefully with the new update they'll consider moving the book online.

Moderated funny? (2, Insightful)

NSAnonymousCoward (756801) | more than 10 years ago | (#9262380)

Are the food jokes about Cocoa (and Java) really still amusing? Or were they ever? There's enough derivative/inflamatory crap on this site without having skim over peoples lame-ass regurgitated humor...
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?