Back from a week of studying Cocoa

As a wise man (Brent Simmons of NetNewsWire fame) once said in a blog post explaining MySQL to Frontier users: “Old programmer’s philosophy: if you work primarily (or exclusively) in one environment, it’s a good idea to learn about others. It stretches your mind, helps you think more widely and imaginatively about how to solve problem”.

For the past week, I’ve been studying Cocoa and Objective-C by reading Cocoa Programming for Mac OS X (Second Edition), by Aaron Hillegass, which came recommended and is definitely the best book I’ve seen about Cocoa programming. The author always brings a smile to my face, not just from his clear and warm writing style, but also the fact that he wears this huge cowboy hat all the time. It’s been quite interesting and exciting and its definitely been a mind-stretching experience. There’s a lot in Objective-C that Java could learn from, plus things in Cocoa for other desktop frameworks. (And vice-versa, of course.)

Here’s one example: in Objective-C, you don’t have an actionListener type framework, with actionListeners that either do work or delegate to other classes. Instead, you’ve got actions and targets, where if you press a button, you can tell another class to directly do something, instead of going though an actionListener.

For example: if you had a button that generated a random number, in Java/Swing, you’d have something like:

  myJButton.addActionListener( new ActionListener() {
    public void actionPerformed( ActionEvent anEvent ) {
       randomNumberGenerator.generate();
    }  
  } );

In SWT, you use selectionListeners. The code would look like:

  myButton.addSelectionListener( new SelectionAdapter() {
    public void widgetSelected( SelectionEvent anEvent ) {
      randomNumberGenerator.generate();
    }
  } );

In Objective-C/Cocoa, you’d visually wire a button in a program called Interface Builder to an instance of RandomNumberGenerator, by control-dragging from the button to the instance (called a target from the button’s point of view). Then you’d pick a method to call (which is called an action). The end result is less code to maintain (actually zero lines of code vs 5 lines of code each for Swing and SWT) and a more direct mapping of the programmer’s intent: in this case, to generate a random number when the button is pushed.

6 Replies to “Back from a week of studying Cocoa”

  1. I’m a little confused about this post and am hoping that you can provide a little clarification. It seems that the example you provided isn’t comparing apples to apples. You’re comparing code that a developer would have to write in Swing/SWT in order to perform an action on a button click to how this is done in a WYSIWYG Cocoa editor. I believe there are Interface Builder type applications for SWT (although I’m not that familiar with them) and the only way to make a proper comparison is to differentiate what you do in these editors with the one you outlined above. Or are you saying that there is no programatic way of telling a button what function to execute in Objective-C/Cocoa outside of Interface Builder?

  2. In addition to Brad’s point, it would help if you posted the generated Objective-C code. I don’t know Cocoa/OC, and I think it’s great you’re going out of your way to learn it, but let me take a wild guess here: OC has “less code to maintain” in this instance because it does event handling through function pointers? Something obviously not allowed in Java – intentionally.

  3. This doesn’t make sense to me either. You’re talking about code-generation versus hand coding UI control logic.

    Anwyay, it’s not like you can’t do this with Java IDEs. I remember doing this sort of thing in Java using Visual Cafe about 6 years ago – identically to how you describe the Cocoa interface builder.

  4. Agreed with previous posts. Is the point that Cocoa has cool tools or the language is nice?

    How do you know that the builder app doesn’t just generate a listener implementation in code for you?

  5. I think I left out an important point: Interface Builder saves out to a NIB file, which consists of “freeze-dried objects”. That is, it takes a snapshot of the state of the actual UI and other objects that were instantiated at design-time. This is what causes the Cocoa code to have 0 lines of code. At first, this seemed really strange to me, but after thinking about it, it seems to simplify UI creation, wiring, and maintainance. I found an interesting project for Swing that seems to be doing something like Interface Builder called Bob.

    So it definitely isn’t apples to apples, this is true. A closer comparison would have been with something like XUL + Java + SWT or Swing.

    The big point I wanted to make was that after seeing how Cocoa does things, it would be good if we as a community could figure ot ways to reduce the burden of wiring up Swing/SWT widgets with the objects they need to interact with. Also it seems that we keep repeating ourselves with the same boiler-plate code for listeners, thus violating DRY (Don’t Repeat Yourself.) I’ve got a proposal for doing this that I’ll type up soon that I’d like to get everyone’s opinion on.

  6. This thread is painfully funny. IB has only been around for, what, 15+ years or so? And most programmers still assume that it was be generating code behind the scenes! Argh!!@#!@#!

Comments are closed.