I'm attacking Objective-C from the perspective of a C# and former VB and Java developer, with some knowledge of C as well. I'm trying to actually read through the book as a fast jump-start into understanding the syntax, and although it does well for this, I found this book a bit frustrating at times. It leaves a few fundamental terms unexplained and then carries on using them as though the reader understands.

For example, what are namespaces in the context of Objective-C? In C#, they are simply explicitly declared container names. In Java, they are the same but also a file system hierarchy. In C, AFAIK, namespaces don't exist. But the book frequently says things like "classes are in the global namespace" and "categories are in their own namespace so they can have the same name as classes". What are namespaces in Obj-C? How on earth do you work with these namespaces??

Code examples from one to the next have nothing to do with the previous, so as you learn a new keyword, and you see a one-line syntax example, you have no other code to see it in context.. such as, hello, how on earth would I *use* that after invoking or declaring it?

It also failed to explain "field sections". One of the reasons I BOUGHT the book was because I didn't understand why some things are declared in braces in the interface declaration, and some things are not, but are still before @end. The book said nothing about these braces and what they're containing. It just said, oh hey, there's no semicolon after @end. (Over and over again, needlessly.) I only figured it out by inference--and am still not sure if I'm right--when I came across the "Category" sample code and where in sample code there's often an area in braces with fields there was instead the comment, "// No field section." Ah. So I guess whatever goes in braces is supposed to be fields.

The book is also obsolete. Objective-C 2.0 has since been released, and this book doesn't cover that. It's dated 2003.

So the book doesn't do a good job as a syntax tutorial like I hoped. But I'll admit that it came really, really close. If the book had these missing components, it would only be about 10-15% thicker I imagine, though, but I don't feel that there's any excuse as it's not just small, it's thin.

I'm attacking Objective-C from the perspective of a C# and former VB and Java developer, with some knowledge of C as well. I'm trying to actually read through the book as a fast jump-start into understanding the syntax, and although it does well for this, I found this book a bit frustrating at times. It leaves a few fundamental terms unexplained and then carries on using them as though the reader understands.

For example, what are namespaces in the context of Objective-C? In C#, they are simply explicitly declared container names. In Java, they are the same but also a file system hierarchy. In C, AFAIK, namespaces don't exist. But the book frequently says things like "classes are in the global namespace" and "categories are in their own namespace so they can have the same name as classes". What are namespaces in Obj-C? How on earth do you work with these namespaces??

Code examples from one to the next have nothing to do with the previous, so as you learn a new keyword, and you see a one-line syntax example, you have no other code to see it in context.. such as, hello, how on earth would I *use* that after invoking or declaring it?

It also failed to explain "field sections". One of the reasons I BOUGHT the book was because I didn't understand why some things are declared in braces in the interface declaration, and some things are not, but are still before @end. The book said nothing about these braces and what they're containing. It just said, oh hey, there's no semicolon after @end. (Over and over again, needlessly.) I only figured it out by inference--and am still not sure if I'm right--when I came across the "Category" sample code and where in sample code there's often an area in braces with fields there was instead the comment, "// No field section." Ah. So I guess whatever goes in braces is supposed to be fields.

So the book doesn't do a good job as a syntax tutorial like I hoped. But I'll admit that it came really, really close. If the book had these missing components, it would only be about 10-15% thicker I imagine, though, but I don't feel that there's any excuse as it's not just small, it's thin.

Probably the best book to read to learn Objective-C, if Apple's PDF on the language is not enough for you. Covers Objective-C both from Cocoa and non-Cocoa perspectives. Try Apple's PDF first, and if it's not enough to let you jump into one of the Cocoa programming books (which all mostly assume knowledge of C and Objective-C), then this book is recommended.

Probably the best book to read to learn Objective-C, if Apple's PDF on the language is not enough for you. Covers Objective-C both from Cocoa and non-Cocoa perspectives. Try Apple's PDF first, and if it's not enough to let you jump into one of the Cocoa programming books (which all mostly assume knowledge of C and Objective-C), then this book is recommended.

Andrew Duncan's Objective-C Pocket Reference is just the book that budding Cocoa programmers should have on their desk. It is well written, well indexed, and succinct enough to read in an evening if desired.

After reading it cover to cover, I think this will be a valuable resource for looking up any Objective-C related questions I have.

Note, you should have an understanding of C before trying to read this book. Also - it will probably make more sense to you if you already have some experience with Cocoa. This is a quick reference - probably not the best way to learn the language. However, the book contains a list at the end which recommends other books and websites which are more thorough.

I'd say it's well worth the cost.

O'Reilly's OBJECTIVE-C POCKET REFERENCE follows in its line of slim booklets designed for quick reference while at the computer. I found it a very helpful book.

While titled "a pocket reference", the book is not something that should be put on the shelf right away and merely consulted from time to time. For a beginning Objective-C programmer, reading the book straight-through can be very enlightening. The basics of Obj-C are easy to grasp, and an Obj-C beginner can immediately start constructing solid applications without knowing about categories, protocols, or root objects. But O'Reilly's book is the best place to start becoming familiar with these obscure topics that might just help one solve a particularly tricky problem.

I have only a few complaints about the book. One is that it talks about the #import preprocessor directive, but nowhere does it mention the advantages of using #ifndef guards. Another problem is that in some parts it is Cocoa-specific; I would have preferred that it concentrate on the OpenStep standard in general so that other OpenStep implementations might not be left out (but the book does occasionally mention GNUstep, which is great).

O'Reilly proves itself the best publisher for developers again with this book, and any Objective-C programmer should invest in it.

I have three different books for objective C programming, which by the way are very hard to find. This book, which was published just recently, is the best objective c book I have read yet.

Objective C is a great language for all platforms, not just the Mac OS, and this book leads you to it. It gives you both Cocoa and standard C information. If you are interested in learning Objective C, this is the book for you! It's inexpensive, small concise and packed with information.