Pain-free GUI building
I have been pounding away at code examples in "Cocoa Programming for Mac OS X" (ISBN 0321213149), a book by Aaron Hillegass. (For anyone who's interested, it's certainly so far an excellent book for people who, say, know some C or Java, but don't know Objective C or even anything much about Mac OS X.) I want to make an observation about Mac OS X which I think is neat, but I had better preface it with a short description about my Java experience, just in case it turns out that the observation is not that neat, and, in fact, I've been doing things the hard way all along.
I have written quite a few lines of Java code over the years, the majority of which has been console-based tools and applications. However, I've written the odd toy, and collaborated on a single substantial project, using Swing to create graphical user interfaces (GUIs) for Java programs. Further, I've never been a fan of great big, hulking integrated development environments (IDEs). And that's not through a lack of trying them out, starting way back with Sun's Forte. I'm more of an emacs kind of guy, and even in the large Swing application, we built the GUI by hand—that is, by typing in the code to build the GUI bit-by-bit. It was, well, awful.
Enter Apple's Xcode. Xcode is a great big, hulking IDE. But it's free, and it comes with good documentation, and Hillegass's book has been stepping me through it. There are (some) emacs key bindings in its editor, and they're getting me through the withdrawal. Finally, here's the neat bit. There's a tool called Interface Builder for putting together the GUI for applications. Nothing remarkable there. Instead of generating code to recreate the GUI at run-time, though, what Interface Builder does is this: it allows you to construct the actual object hierarchy for the GUI in a drag and drop fashion (which is probably what the Java IDEs are doing as well), and then just serialises that object to a file for reconstruction at run time! That is, it doesn't translate the object hierarchy you built into code to reconstruct that hierarchy, which is the only way I've ever seen a Java IDE do it, it just serialises the actual instance of the object hierarchy you've just built on-screen (or "archives" it, in Apple-speak) for deserialisation ("unarchiving") at run-time. I think that's neat.
I have written quite a few lines of Java code over the years, the majority of which has been console-based tools and applications. However, I've written the odd toy, and collaborated on a single substantial project, using Swing to create graphical user interfaces (GUIs) for Java programs. Further, I've never been a fan of great big, hulking integrated development environments (IDEs). And that's not through a lack of trying them out, starting way back with Sun's Forte. I'm more of an emacs kind of guy, and even in the large Swing application, we built the GUI by hand—that is, by typing in the code to build the GUI bit-by-bit. It was, well, awful.
Enter Apple's Xcode. Xcode is a great big, hulking IDE. But it's free, and it comes with good documentation, and Hillegass's book has been stepping me through it. There are (some) emacs key bindings in its editor, and they're getting me through the withdrawal. Finally, here's the neat bit. There's a tool called Interface Builder for putting together the GUI for applications. Nothing remarkable there. Instead of generating code to recreate the GUI at run-time, though, what Interface Builder does is this: it allows you to construct the actual object hierarchy for the GUI in a drag and drop fashion (which is probably what the Java IDEs are doing as well), and then just serialises that object to a file for reconstruction at run time! That is, it doesn't translate the object hierarchy you built into code to reconstruct that hierarchy, which is the only way I've ever seen a Java IDE do it, it just serialises the actual instance of the object hierarchy you've just built on-screen (or "archives" it, in Apple-speak) for deserialisation ("unarchiving") at run-time. I think that's neat.
"I've never been a fan of great big, hulking integrated development environments (IDEs)." Ditto. I prefer to use a text editor (Crimson Editor) and keep things simple for my simple little mind (KISS). Then again maybe I'm just too lazy (not unlikely!) to learn how to [properly] use something new :P
ReplyDeleteInteresting what you were saying about the way the objects were serialized. Way back when Java beans were new and exciting (1998?) this was the way that they were supposed to be used. You instantiated a java bean, interacted with its properties and then serialized the results.
ReplyDeleteIt's nice to hear that the old way of doing things still gets used somewhere.
BTW I do like big Java IDE's. Intellij IDEA is my favorite with Eclipse a close second.
I thought that it was unlikely that this was the first time anyone had thought of this—thanks for the info on Java beans. As I noted in the post, it was more likely that I had just been doing things the hard way all along.
ReplyDeleteI think the difficulty I had with Java IDEs was probably that the emphasis on building the GUI up-front didn't really work for the kind of Java code I was writing. If a project needed a GUI, it seemed backward to me to even think about coding that before the back-end of the application itself. Maybe I just wasn't approaching GUIs properly. Either way, with Xcode I'm a convert to great big, hulking IDEs.