Coming into Apple’s Cocoa programming from the Java world has been a huge eye-opener for Marcus Zarra. Whenever he speaks with other developers who have worked with Cocoa, he hears praises about Apple’s development tools. See if you agree with his conclusions about Apple’s Interface Builder from a Java developer’s point of view.
The Java Perspective: Cocoa’s Interface Builder
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’m always amazed by people, like the author, who criticise GUI builders. After all, a GUI is just a nested series of configuration options (width, height, position, label, font etc.) and code is an astonishingly bad way to represent such data. A structured document language like XML is far better (see SwiXML for a Java example) and easier to read and edit.
But then there’s the issue of manually entering XML, which is quite time-consuming due to XML’s verbosity (which is precisely it’s advantage when it comes to reading in the file). The obvious solution for any hacker is to write a program for themselves that make entering that data easier. Hence, GUI builders, which not only let you enter the data quickly, but also let you preview the results.
Score!
Frankly, given that the average GUI spends most clock-cycles in a busy-wait loop, I can’t see the point of hand-crafted optimsiations. That should be reserved for the business logic surely.
With regard to the article, Interface Builder’s way of representing GUIs as a serialized object is certainaly interesting, and would definitely improve startup speed. That said, however, I don’t think the time to initialise the GUI is the real bottle neck in most applications: it’s the virtual machine (if any), followed by I/O performed by the business logic.
With regard to Java, the GUI builder in Netbeans 5 is very impressive, and quite easy to use. Likewise, things like SwiXML and Thinlet take the pain out of GUI development, and the upcoming official release of Qt for Java should make things easier still (not to mention faster). I’m not sure Cocoa is the be-all and end-all here; in fact, I think Objective-C is a bit of a hamstring for Apple: for most modern developers – reared on C++ and Java – it’s a very odd looking language.
With regard to the article, Interface Builder’s way of representing GUIs as a serialized object is certainaly interesting, and would definitely improve startup speed. That said, however, I don’t think the time to initialise the GUI is the real bottle neck in most applications: it’s the virtual machine (if any), followed by I/O performed by the business logic.
I don’t exactly undestand where the article’s author found this idea of faster starttime… while it’s perhaps possible, the objects *are* initialized anyway, just from their serialization format rather than by hand, but I don’t think it’s _that_ faster. And more importantly, that’s frankly not the point of Interface Builder !
The real interest of the IB’s approach — manipulating objects directly — is that, along with your objects and their properties, ALL their connections to other objects are saved !
As it can be any objects (even non-gui) you basically can do most of your work in IB instead of doing it by hand. That’s what is interesting in IB — you only need to write and concentrate on the “real”, useful code.
Plus, you can write your own palettes of custom objects (which can be widgets or non-graphical objects) and easily connect them…
I should remind people that a similar tool to IB exists in the GNUstep project, named GORM (btw, read this post of the GORM’s maintener : http://heronsperch.blogspot.com/ ^_^ ) . For a demonstration of GORM+custom palettes with GNUstep, check http://www.xdev.org/gnustep/demo.html
The improved start-up time is NOT just from the object serialization but the fact that the entire GUI is serialized. All of the layout code, connections, bindings, etc. are serialized. This is where the performance boost comes in. I have tested it against hand writing GUI code in Objective-C for Cocoa. The start up times are quite different.
BTW, their is a difference in the initialization times between initWithCoder and init… initWithCoder is generally faster.
Why hate GUI builders? It’s quite simple… resizability.
For years, GUI Builders have easily been able to generate statically positioned forms quite well, but customer’s don’t want that.
Dynamic support has been absolutely painful for years as well, and that’s why there’s so much going against GUI builders. Visual Studio 2005 has some small improvements in this regard, and Matisse does as well, but neither are good enough, and the maturity is just not there.
Delphi has supported resizeability for at least five years now using its system of anchors. NetBeans has supported resizability for an even longer time, although only with Matisse has it become easy to work with. IntelliJ has supported resizability in its GUI designer for quite some time. Qt has supported resizability since Designer came out with version 3, which was around 2001 I think, and before that Glade existed.
The only aspect of “resizability” that GUI designers have traditionally failed on is font-sizes, and resizing forms dynamically based on font sizes. However that’s only on Windows: all the Java IDEs have supported that from the beginning, and so have Glade and Qt Designer. I think even Delphi 2005 supports that now.
I don’t know about Visual Basic or VC++, but GUI designers have been working well for quite some time. And while the font-issue is a weakness, it is a weakness that didn’t matter until this year, when it became feasible – thanks to large, affordable, flat-screen displays – to run your desktop at a high resolution. For the most part, I would say the maturity is most definitely there, it’s just a matter of developers using these features.
In typical Java coder fashion, he managed to make about double the code he needed.
[lblDisplay setStringValue:[NSString stringWithFormat:@”Hello World!”]];
…could have just as easily been…
[lblDisplay setStringValue:@”Hello World!”];
Oh well. Very cool that he’s starting to see the light, though.
I so know what you are talking about. I programmed in Python before I took my compsci classes and they are of course Java. I noticed that the programs of my classmates where always about twice as long as my programs.
That line of code has absolutely nothing to do with Java coding practices. It is a simple error caused by an edit of the article.
There is a way to use InterfaceBuilder for Swing Apps.
http://www.nib4j.com/
Never used it, though.
Anybody with first-hand experience care to comment?
As stated above, NetBeans 5.0 GUI builder is very much like Apple’s Interface Builder.
I have a question concerning this deserialization of GUI components as it is described in the article. I suppose I just don’t get it but I would like to be enlighted…
How does this work when change you Cocoa version ? Do they maintain binary compatibility so that the previously generated GUI files can still be loaded with the new Cocoa version ?
The de-serialization is really a kind of initialization: every object in the nib is initialized with initWithCoder:,
The data returned by the archiver is the same that was written out by the objects encodeWithCoder: method.
The object can use its archiver’s containsValueForKey: method to determine if a certain value had been saved during encoding; that way, it can determine how to best restore itself.
See NSCoding (the protocol which every serializable object adheres to), NSKeyedArchiver, NSKeyedUnarchiver (the coder and decoder most commonly used today).
Thanks for explanation. I was hoping that some more intelligent serialization to be exposed here than plain and simple memory dump. The comment in the article mentionning the speed of this deserialization is inappropriate, if I understand you well. This means that a real instantiation is taking place.
I’ll stick to my web-coding for the moment anyway but seeing other ways to develop user interfaces is always a subject that gets you thinking. Mostly out of frustration 😉
is not instability, general awkwardness / clunkiness, or even its extraordinarily counterintuitive and confusing connection paradigm, it’s that IB only writes a proprietary binary format.
I like GUI builders in general and wouldn’t want to live without them, but some types of editing / repairing are just simpler in a text editor. With IB, for example, you generally have to recreate from scratch when a .nib file suddenly won’t open or refuses to allow or save a setting (and this isn’t a rare occurrence.)
While I strongly suspect you are trolling, and personally have not had any nib file become corrupted, you could just try to save the nib in text format. In the “Nib” tab, check the “Use text archive” checkbox.
As a long time Java/C/C++ developer and a big Mac fan I have tried several times to get on the Cocoa bandwagon and I am just having a tough time seeing why it is supposed to be so dang easy. I have gone through several of the Cocoa tutorials on building GUI’s and frankly I found that keeping the Interface Building aspect seperate from the code window is confusing and difficult to use at best. The only thing intuitive about the interface builder was the actual dragging of widgets onto the screen to actually build the form. Connecting the events to the objects was a different matter entirely. I mean who would think you have to control click drag to create arrows from the object to its delegate or consumer. Sorry I might be getting my Cocoa terminology mixed up since it’s been a couple months since I tried this. Bottom line it was just friggin frustrating to do anything.
On the other hand take writing Swing apps with a good IDE like Netbeans. Netbeans 4.1 was very good at constructing GUI’s and now Netbeans 5.0 Beta has taken it to another level. It has finally beaten VB 6 as the premier GUI construction tool in my opinion. Compared to Interface Builder it is just a breeze to create a GUI. It is intuitive, powerful, and very simple to understand. There are so many great features that I don’t have to space to list here. With Netbeans I just whipped out a new custom Java code editor in a few days as compared to weeks if I did it by hand. With Interface Builder who knows how long it would take.
As a big Apple fan it pains me to say this but Apple needs to look at how Interface Builder works and take a page from Microsoft and Netbeans to really make it a viable tool. Right now it is about as intuitive as Physics to a business major.
Yes I have used NetBeans 5 and I am not impressed with the code that it generates. That is my issue with GUI builders in Java. They write terrible code. Now they have definitely improved over the past few years but they are still no where near what a good GUI coder can do. When it comes to Java GUIs, clean, maintainable code matters. The cleaner it is the faster it performs.
It is shame that your not able to get into Objective-C and Cocoa. The development environment is so much easier to use than any other I have used in the past and I have used a large number of them.
Delphi has supported resizeability for at least five years now using its system of anchors.
Well Interface Builder has had resizeability since it was first released in 1988 or so. You just group things together in a box, and then use an inspector to either add ‘springs’ or ‘struts’ depending on how you want resizing to behave.
I think the best name for the way IB archives out an object graph is calling it an ‘Instance Composition Tool’.
The comment was in regard to the antipathy towards GUI builders in general, as opposed to a comparison (negative or otherwise) with Interface Builder in particular. It actually looks quite good. In particular I like the signal/slot automation: the closest I’ve ever come to that sort of coding has been experimenting with Qt Designer, and it’s something I’d appreciate in Delphi. What I’d really like is the system of layouts and springs you find in Qt and IntelliJ, that’s the best way to create resizeable forms that I’ve encountered.
That said, Delphi is good enough in most respects, so I can’t say I miss the absence of these things too much. However since I’ve got a 19″ LCD screen, I’ve become very aware of the font-sizing issue.