Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Businesses Book Reviews Apple IT Technology

Cocoa Programming for Mac OS X, 2nd Edition 162

Posted by timothy from the add-water-and-stir-then-sift-for-marshmallows dept.
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.
Cocoa Programming for Mac OS X, 2nd Edition
author Aaron Hillegass
pages 450
publisher Addison Wesley
rating 9
reviewer Kevin H. Spencer
ISBN 0321213149
summary 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.

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.
This discussion has been archived. No new comments can be posted.

Cocoa Programming for Mac OS X, 2nd Edition More

Cocoa Programming for Mac OS X, 2nd Edition

Comments Filter:

  • Mmmm... Cocoa (Score:2, Funny)

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

  • In case anyone is wondering.. (Score:5, Informative)

    by AKAImBatman ( 238306 ) <akaimbatman&gmail,com> on Wednesday May 26, 2004 @02:09PM (#9261302) Homepage Journal
    ...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.

  • Differences from first edition (Score:3, Interesting)

    by tenuki ( 704832 ) on Wednesday May 26, 2004 @02:10PM (#9261314)
    How different is this one from the first edition?

  • Other good books are... (Score:5, Informative)

    by Space cowboy ( 13680 ) * on Wednesday May 26, 2004 @02:11PM (#9261317) Journal
    "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

    • 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

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

    by NeoGeo64 ( 672698 ) on Wednesday May 26, 2004 @02:11PM (#9261318) Homepage Journal
    Real men code everything in BASIC.

  • I'll wait (Score:5, Funny)

    by Bingo Foo ( 179380 ) on Wednesday May 26, 2004 @02:11PM (#9261325)
    I'll wait for the third edition: Protocol Handler Exploit Programming for Mac OS X.

    • THAT is an old story... (Score:5, Interesting)

      by argent ( 18001 ) <peter@nOSpAM.slashdot.2006.taronga.com> on Wednesday May 26, 2004 @02:29PM (#9261482) Homepage Journal
      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... (Score:5, Interesting)

        by dasmegabyte ( 267018 ) <das@OHNOWHATSTHISdasmegabyte.org> on Wednesday May 26, 2004 @02:41PM (#9261612) Homepage Journal
        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.
        • 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
          • 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 designe

            • Re:THAT is an old story... (Score:5, Informative)

              by argent ( 18001 ) <peter@nOSpAM.slashdot.2006.taronga.com> on Wednesday May 26, 2004 @04:43PM (#9262760) Homepage Journal
              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.
      • 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?

        • 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.
      • 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! (Score:5, Informative)

    by Capt.Gingi ( 89525 ) on Wednesday May 26, 2004 @02:14PM (#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.

  • Second Edition Errata (Score:5, Informative)

    by bcolflesh ( 710514 ) on Wednesday May 26, 2004 @02:17PM (#9261376) Homepage
    http://www.bignerdranch.com/products/cocoa1.shtml [bignerdranch.com]

  • I'm . . . (Score:5, Funny)

    by Prince Vegeta SSJ4 ( 718736 ) on Wednesday May 26, 2004 @02:20PM (#9261400)
    kookoo for Cocoa Progs

  • Good Tutorial (Score:5, Informative)

    by druske ( 550305 ) on Wednesday May 26, 2004 @02:24PM (#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.")

  • I'll be programming at.... (Score:5, Funny)

    by millahtime ( 710421 ) on Wednesday May 26, 2004 @02:25PM (#9261449) Homepage Journal
    the cocoa, cocoa cabana....
  • Can Cocoa use the same objsect code produced in Mono?

  • No xcode? (Score:5, Interesting)

    by tf23 ( 27474 ) <tf23@lo t t a d o t . com> on Wednesday May 26, 2004 @02:37PM (#9261549) Homepage Journal
    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? (Score:5, Informative)

      by clichekiller ( 665320 ) on Wednesday May 26, 2004 @02:41PM (#9261608) Homepage
      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.
    • 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? (Score:3, Informative)

      by technomancerX ( 86975 )
      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? (Score:3, Interesting)

      by BasilBrush ( 643681 )
      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!... (Score:2, Interesting)

    by tonywestonuk ( 261622 )
    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-e
    • 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.
      • 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 autogener

        • Re:MVC Shite!... (Score:5, Informative)

          by shawnce ( 146129 ) on Wednesday May 26, 2004 @03:55PM (#9262209) Homepage
          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.
          • You can implement rather complex GUIs without writing a single line of code yourself (more so now thanks to the contoller objects supported

            Recently wrote an article on this, for those that are interested:
            Introduction to Bindings [cocoadevcentral.com]

            - Scott
          • 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.

            My favorite trick is the do-it-yourself web browser, done entirely in IB.

            Start IB, make a new empty nib, and drag a window into it. Drop a WebView in that window, size to your liking, and leave a bit of space at the top. Next, drag a text box into the window, then control-drag from the text box to the WebView, set i
        • MVC=Model-View-Controller, and has nothing to do with whether a GUI builer is used or not. I've done more MVC style apps wthout GUI builders than with.
    • 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 componen

    • Re:MVC Shite!... (Score:5, Interesting)

      by jamesmrankinjr ( 536093 ) on Wednesday May 26, 2004 @03:45PM (#9262140) Homepage

      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!... (Score:4, Interesting)

      by Ilan Volow ( 539597 ) on Wednesday May 26, 2004 @03:56PM (#9262228) Homepage
      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.

    • Re:MVC Shite!... (Score:3, Insightful)

      by Fermata ( 644706 )
      Hmm...you must have skimmed through the tutorial without reading closely, since it *specifically* tells you that the Currency Converter is overdesigned to introduce the MVC concept:

      "This design for Currency Converter is intended to illustrate a few points, and so may be overly designed for something so simple. It is quite possible to have the application's controller class, ConverterController, perform the computation and do without the Converter class. By adhering to the MVC paradigm in this tutorial, how
    • 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?

      As could I with xcode/IB.

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

      Sure.

      What ab
    • Firstly as other people have said there is no surprise in the fact that you could program a currency converter app in another environment. The two main reasons are that you are not yet familiar with XCode and Interface Builder (IB), and secondly that the Currency Converter example is overdesigned to demonstrate the principles behind MVC.

      As for the dynamic screen that adjusts itself to the data inside it, of course you can do this. This has always been fairly easy to accomplish, but 10.3 adds a concept ca
    • Another Addison-Wesley book called Design Patterns, Elements of Reusable Object-Oriented Software written by a gang of four programmers might explain the advantages and limitations behind something like the Model/View/Controller pattern more clearly than Apple's or Mr. Hillegass's references

      The Currency Coverter is really designed to show this pattern at it's most simple. Sure there are all sorts of short cuts you can take if you are really writing a simple currency converter, but the point of the exercis

  • Aaron Hillegass - a personal opinion (Score:5, Informative)

    by anactofgod ( 68756 ) on Wednesday May 26, 2004 @02:39PM (#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---

    • 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 went to graduate school briefly with Aaron. (He left soon after he started to pursue his NeXt / Apple / Cocoa interests.) He was indeed a super nice guy; he helped me through first year differential geometry (and now I think of myself as a differential geometer).

      Go Aaron!

      I'm gonna pick up this book asap.

      Alas, I'm not

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

    by Anonymous Coward on Wednesday May 26, 2004 @02:39PM (#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 (Score:4, Informative)

    by ashpool7 ( 18172 ) on Wednesday May 26, 2004 @02:45PM (#9261645) Homepage Journal
    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 (Score:3, Funny)

    by SKPhoton ( 683703 ) on Wednesday May 26, 2004 @02:54PM (#9261724) Homepage
    Ah, so they have Java and Cocoa now, eh? In that case, I have just one question for you:

    Cream or sugar?

  • Reference (Score:4, Interesting)

    by Ann Coulter ( 614889 ) on Wednesday May 26, 2004 @03:05PM (#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.
  • "...porting your apps to Mac users..."

    Interesting idea. I thought most Mac users had to be programmed in English, though. :-)
  • 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.
    • 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.
    • Objective-C is a very simple language, and takes under a day to pick up if you are already familiar with OO concepts, however it has little in common syntactically with C++ or Java. If you know C and understand OO design then you should have no problem with Objective-C.
  • 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.
    • Perhaps O'Reilly feels that this book's audience too closely overlaps the one for their "Learning Cocoa on Mac OS X" book.

      Perhaps O'Reilly paid through the nose to be the exclusive "Apple Developer Connection Approved Documentation" label (or whatever the exact phrase is) and simply doesn't want to share.

      Perhaps there is some bad blood betwixt Mr. Hillegass and his former employer (Apple/NeXT).

      There are many possibilities, but my suspicion is that you won't see this great Addison-Wesley book show up on t
  • 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...

  • Better "dive in" well before... (Score:3, Insightful)

    by macserv ( 701681 ) on Wednesday May 26, 2004 @04:39PM (#9262728)
    ... you get screwed up by C++.

    Well, OK, not screwed up, but C++ experience should not be considered a good background for learning Objective-C Cocoa. Its approach to programming with "objects" is very different, and the transition to Objective-C, IMHO, leads to a mix of techniques that is hell to read/debug, making for buggy Cocoa apps. If you're a C++ vet, it may be a good idea to unlearn a lot of what you know, and assimilate the conventions of the seasoned Objective-C coders.

    That said, even though C++ may not give you a good start for Objective-C development, it can still be very beneficial to leverage C++'s speed in various parts of your application. You can, for example, build your engine from C++, and your widgetry in Objective-C Cocoa.

    A strong Java background makes for a fairly easy to transition into Cocoa, trading in a few conveniences for greater flexibility, more mature classes, and easy GUI development. Java is quite similar to Objective-C and both can be used/mixed to build Cocoa applications (most don't though).

    If you're a C jockey, Objective-C is like adding a new weapon to your arsenal. Objective-C is a superset of C. Those who are fluent in the design patterns of both languages will get the most from their Cocoa applications. Indeed, the ability to (fairly) freely intermix C, Objective-C and C++ is a great advantage, allowing you to use the tool that's right for the job.

    As a switcher from any language, one of the biggest hurdles can be getting some fundamental OO design patterns down, which are expected by most of the Cocoa API. For example, you can't go one step in learning Objective-C without being taught the MVC (Model-View-Controller) paradigm. In contrast, a great many mature Java/C++ developers have never learned, or even heard of, this concept.

    Just some observations... YMMV.

  • A few addenda (Score:5, Informative)

    by buckhead_buddy ( 186384 ) on Wednesday May 26, 2004 @05:19PM (#9263080)
    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.

  • Don't really need to know C++ nor Java... (Score:3, Insightful)

    by Whatchamacallit ( 21721 ) on Wednesday May 26, 2004 @06:19PM (#9263545) Homepage
    One does not really need to know C++ nor Java as Objective-C is really ANSI C + Smalltalk extensions. Obj-C on it's own is really rather simple. It's much easier and some may argue more powerful then Java or C++.

    What this book does is introduce you to the Cocoa API and the Apple Dev Tools XCode & Interface Builder. The first edition was a blast and I plan on picking up the second edition in the near future.

    If you are coming from a C++ background and you like it, you should study Carbon and not Cocoa at first. You can call Cocoa objects from Carbon and visa versa though. New projects should probably be written in Cocoa. Older projects written in C++ can be ported to Carbon easily. C programs can be ported to Cocoa and Java programs should probably stay Java or be ported to the WebObjects frameworks if it's a web based solution. You can write Java apps using the Cocoa API but it then becomes locked into the OS X platform as the Cocoa API (for Java) is not available on other platforms (maybe GNUStep but it's not all the way there yet) Note, you can run Tomcat and JBoss on OS X!

    The NeXTStep / OpenStep / Cocoa API is rather advanced and can take some getting used to... i.e. you will have a rather steep learning curve to absorb it all and understand the best practices. This book is a great introduction and will get one up to speed quickly.

    I found Interface Builder to be the most difficult part of the development process. This was because I had to unlearn all the preconceived crap in my head that I learned from other GUI interface tools. It turns out IB is much more advanced then anything I've ever used before because it builds live objects and not just GUI code. It then archives these objects into NIB files which are automatically unarchived by a Cocoa application. You literally build objects graphically and then interconnect them to each other and your Obj-C classes and instances. WebObjects does the same thing but with Java. It's a really slick development tool and once you start to understand it, the light turns on and you can see the possibilities.

    Total newbies should probably pick up the "Programming in Objective-C" by Stephen Kochan. This book covers just the underlying Obj-C language and the Core Foundation (NeXStep/OpenStep/GNUStep/Cocoa) API. Programming in Objective-C does not cover the GUI portion of Cocoa programming. I just finished it and it managed to bootstrap my understanding quite a bit.
  • I have the first edition of this book, and found it to be excellent. I'd consider it the first of two essential books for Cocoa programming (the second being the O'Reilly book, which I use as a class reference).

    I've seen the list of what's been updated, but it isn't enough to convince me that getting the second edition is worth the price if you already own the first. Are the differences enough to warrant the additional investment?

  • Right, here's a question that pops into my head whenever I see references to Cocoa/Carbon on slashdot...

    See, I've written some libraries that I use to write my apps, and I deliberately chose to make them portable, in case I ever decided to switch from Windows to Linux or Mac OS X - so I wouldn't end up losing all my software (or having to put a lot of work into porting them).

    So I have APIs for general OS interface and GUI programming, which I designed to be portable, having passing familiarity with Linu

    • 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.

Slashdot Top Deals

CChheecckk yyoouurr dduupplleexx sswwiittcchh..

Close