Slashdot Mirror
Cocoa Programming for Mac OS X, 2nd Edition
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.
...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.
Javascript + Nintendo DSi = DSiCade
"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
Physicists get Hadrons!
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.
http://www.bignerdranch.com/products/cocoa1.shtml
This version is written for Panther, and thus covers the new features of Cocoa that were introduced in Panther, such as bindings.
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 and the mindshare at the Cocoa developer list archives, 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.")
That's what Java is all about: you can be an assembly zealot and still be platform independant with the JVM opcodes ;)
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---
---anactofgod---
"Equal opportunity swindling - *that* is the true test of a sustainable democracy."
Here's an openstep workalike for linux, they even have "Project Builder" and "Interface Builder".
GNUStep project
useful for getting your feet wet with Objective-C (pretty good) and the *step frameworks.
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.
Sir, there is a dragon outside with an armful of armor. He's inquiring if we offer free refills.
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.
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.
Ergonomica Auctorita Illico!
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.
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 i
---anactofgod---
"Equal opportunity swindling - *that* is the true test of a sustainable democracy."
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
.technomancer
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.
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
The only title of honor that a tyrant can grant is "Enemy of the State."
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.
The most striking difference is the message passing syntax. For instance, if "hello world" is a string, returns "llo w" as a new C++ string, whileor, more simplyIn Objective C, the NSArray colllection class is similarsimilarly, there's the more concise method:Objective C is also a dynamically typed language, which makes GUIs somewhat easier to write.
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.
No, you're missing the point. The problem isn't that this or that application is not secure, it's that there are readically different approaches that the high level part of an application has to take when it's dealing with untrusted objects. An application that is designed for an untrusted environment has to implement mandatory access control, what some people call a sandbox. An application that is designed for convenient use by the end-user in an environment where it doesn't have to deal with untrusted objects would be terribly cumbersome if it applied mandatory access control to everything. There are systems that apply MAC everywhere, what they call compartmentalised mode systems, and they're terribly difficult and unfriendly.
So applications like web browsers, mail software, media players, anything that implements a mechanism to access and display untrusted data, have completely different requirements from applications like Finder or Help Viewer. It is very difficult to design a single set of rules that can aply to both, even if you use "Zones" to separate them, because it's difficult to determine *what* zone something is supposed to be in.
That's how the "cross zone" exploits on Windows work, the typical example is to trick an application like Outlook into opening a document on the local disk that has been provided by the exploit script. It's local, so it's trusted, and bob's your uncle... the bad guy is in.
This is exactly the same problem these recent exploits on the Mac use.
The right fix is to have the application keep track of the history of an object and never let it at the "trusting applications" list. And to have applications that deal with untrusted data by default assume that everything they're dealing with is untrusted. In Microsoft's case, instead of having a single "internet explorer" application (actually the MS HTML Control) that you call with a file and have it figure out whether to trust it or not, you would have an IE application that handles access, and calls an HTML entity that only does display and goes back to the application for access. Apple has a different display model using PDF that doesn't do access, so they don't have that problem... all they need to do is split LaunchServices into a "for trusted data sources" and "for untrusted data sources" list. Applications that open remote documents use the "for untrusted data sources" list for references in those documents, and you ONLY put applications that expect untrusted data in that list.
There's little duplication, because there's very little duplication between what you want to do with trusted and untrusted data... and you would generally be able to make do with a wrapper.
As for the famous Apple "graphical SU", well, that's a good start. It's part of a security solution and I'm glad it's there... but it's nowhere near a panacaea for this situation. If I have local access on your machine I don't need to do *anything* to your system configuration to make your life just as miserable as if I were running as Administrator on a Windows box or root on Linux. I could send spam in your name, open up a back door that a bad guy could use to perform more sophisticated attacks, set a listener on your email, redirect your browser through my proxy, just about anything that doesn't require actual superuser access. And all it takes is *one* rogue executable to get it in.
This is not an attack on Apple... there is no way to build an OS that's suitable for a general user population to run arbitrary code on without opening up the possibility that someone might trick the user or the system into running an exploit. You wouldn't want to use a system that sandboxed everything, and neither would I. So don't be in such a hurry to defend Apple's honor... there's no dishonor here for them. It's Microsoft... who created the copreesponding hole in the mid '90s and refused to fix it even when required to under a court order that has egg on their face.
I have both editions, and I have to say that the second edition content and writing are better.
He has incorporated 2 years worth of experiences from the teaching of the first edition at Big Nerd Ranch into this book... so it is little wonder that the second edition is better. He approached the book with the idea that "it'll be released when it is ready", and it shows. He didn't rush this out the door. You cannot find a better resource for Mac OS X programming than this author. I suggest reading anything he writes, if you are serious about programming the Mac.
As far as the content goes -- everything development (CodeWarrior aside...) in Panther is Xcode, not Project Builder -- and the second book reflects this. I had a terrible time implementing the first edition's projects in Xcode, because all of the screen shots were different -- even Interface Builder has changed quite a lot. If you are looking at both editions and do not have the first one, you won't regret getting the second one. If you have the first one, but have not started learning from it yet, you will want to skip it and get the second one. If you've already gone through the first one, the second one might help you dig more into Xcode, but the Xcode website might be all you need for that.
I hope this helps.
"To make a mistake is only human; to persist in a mistake is idiotic." Cicero
I think Spencerian probably answers 90% of the questions most people have about this book: author qualification, tools required, prequisite expertise required, and changes from the original. I won't get involved in the flame wars about Objective-C versus Java and Mac OS X versus GnuStep, but I do have some additional comments (maybe better stated as additional opinions).
Tools:
You must have Panther (10.3) or later to use this book. It was possible to read the first edition (written for 10.1) and make some mental leaps forward, but the reverse is impossible. Besides the differentces between XCode and the GUI screenshots, Apple deprecated a number of methods (like takeValue:forKey:) in favor of much cleaner names (e.g. setValue:forKey:). Aaron doesn't mention the deprecated names (quite rightly IMHO) so that will make the Jaguar programmer have to refer to Apple's website to do the translation back to the older APIs. You may need to do mental exercises like that when you have to read someone elses code or when you're back porting your app, but if you're still learning, be sure to get Panther before trying to use this book.
Presentation:
Many of the books screenshots look much cleaner than the prior version. I think that's mainly attributable to Apple deciding to tone down much of the visual clutter in the Aqua theme. The lack of the pinstripes in windows and menus really makes the documentation much easier on the eyes. The change is really much more dramatic and makes for a much more readable book.
If You Read the First Edition:
I've read the first edition, and I have to say that I got impatient with much of the earlier portions of the book. I wanted the examples for Bindings and other new additions to Cocoa. I was already comfortable with the trivial examples in the early chapters, so it was hard to force myself to go back and really read and work through them. Do it. I remember most of the big points made, but some of the subtler points make more sense now. Whether these were in the last edition, I'm not certain but it was still good a good review.
Applicability to a New Programmer:
I'll underscore that this isn't for a new programmer. If you are new to C, I'd suggest reading the non-GUI text "Programming in Objective-C" by Stephen G. Kochan. An extensive background in object-oriented programming isn't as necessary (and in fact may be detrimental if your background is multiple inhereitance of the C++ world). But it does include some tips and advice on good OO techniques that Objective-C programmers use. You won't see any explanation on pointer tricks, handles, NULL, or many of the other plain C conventions. If you are a strong Unix programmer, you may feel more comfortable reading the Aaron Hillegass and Mark Dalrymple's "Core Mac OS X and Unix Programming" first. That book is billed as the sequel to this one (and it does use a little bit of Objective-C code), but it probably addresses your interests far more than this Application-centric book does.
The lessons of this book are quite worthwhile to certain audiences, but finding whether you are a target for it's wisdom may be tricky. Don't get frustrated. If you find it to be over your head, read another intro book but I'd definitely come back to this one at some point in the future.
I've taken a look at the same problem recently.
My feeling is that while Cocoa is a better choice for developing Mac OS X specific stuff, Carbon may end up being more similar to other platforms, and so possibly a bit easier for this specific use. Cocoa is still very doable for the same problem - but essentially, I suspect many C++ methods would just end up being a call to an equivalent Cocoa method (though often one you've written yourself). Mixing C and C++ is not particularly ugly or hackish in most cases. You can more of less mix the two syntaxes easily enough with Apples Objective-C++ support.
It kind of depends on your specific libraries, though. If your libraries are such that your objects correspond fairly closely to Cocoas, you might be better off using Cocoa.
The real value of Objective-C lies in its dynamic nature, which if you were writing a cross-platform C++ library you might not be able to make much effective use of.
I wouldn't worry that Carbon is being phased out, or that there will be new shiny functionality only accessible from Cocoa. In my experience thats not really the case at all. There is definitely functionality only accessible from Carbon (and lots of it) and Carbon is quite well supported. A lot of non-GUI Cocoa stuff (FoundationKit) is more or less duplicated with CoreFoundation (which is a straight C interface, accessible from both and interoperable with corresponding Cocoa classes). Lots of important apps are written in Carbon. Carbon works well with interface builder (you end up writing a LOT of event handlers, but they are straightforward).