Cocoa

Ben Galbraith, Dion Almaer and the No Fluff Just Stuff team are preparing a developer conference focused on desktop technologies. In case you haven’t noticed the banner on this web page, it’s called Desktop Matters and takes place in San Jose, CA, on Thursday March 8 and Friday March 9.

Most of the conference material is about desktop Java technologies but there will be some sessions about Adobe’s, Apple’s and Microsoft’s solutions. It seems like a good opportunity to discover other technologies and talk about them with specialists. Also, some members of the Swing team should be present in case you’d be interested to meet them.

I will be present to talk about Filthy Rich Clients. Hope to see you there!

Desktop Matters

Whenever I have some spare time, I continue my exploration of Cocoa/Objective-C development. Lately, there’s been a few blogs telling the world how vastly superior Cocoa is to Swing. Cocoa is a fine toolkit and some APIs are wonderful but there are things, aside from having to maintain those stupid .h files, that I find quite annoying.

Being used to Java IDEs, it’s hard to forget about refactoring. Xcode does not provide any support for this and because of the way I am used to code now, I am frustrated. But I can live without refactoring.

The real gripe I have against Apple’s developer tools is how the Interface Builder works. It is an impressive, easy to use piece of software that lets you build nice UIs very quickly. You can even do databinding in it, which is very useful. Yet, things are getting hectic with events handling.

In the Interface Builder you can connect an element, for instance a button, to an action in a target. Doing so is easy as you simply have to draw a line connecting the button and the target. When you first build your UI, you generate .h and .m files corresponding to the target (usually called a controller, following the MVC pattern.) In the .m file you find the methods you need to implement to respond to actions in the UI. So far so good.

The real problem arises when you have typed some code in the .m file and want to handle more events. You go back to the Interface Builder, connect another component to an action in a target, and… you’re screwed. You have to explicitly tell Interface Builder to re-generate the target’s .h and .m files. If you do so, you must either replace the files altogether or go through a painful process of merging code. That’s right, you are shown a diff/merge tool and must merge by hand. While it might be acceptable for small applications, like the ones I write to learn Cocoa, I can’t fathom the consequences on large projects. The other solution is not to use Interface Builder to connect actions and do everything in the code.

I am disappointed and I sincerely hope I have missed something big here. If some of you have experience in Cocoa development, please tell me I’m wrong :) I have heard a lot of complains against NetBeans’ GUI Builder for instance, because it generates the UI code rather than putting it into an external file, akin to Interface Builder’s .nib files. I understand those complaints but at least NetBeans GUI Builder, or other Java GUI builders for that matter, let me incrementally work on my UI without worrying about diffing/merging the code.

Cocoa Development Tools