Dave Batton at Mere Mortal Software has produced an excellent tutorial on developing an Apple mail-style interface. To develop the interface he has brought together useful classes from a whole bunch of awesome developers. Well done Dave, I hope you write more tutorial style articles in the future!
Technorati Tags:
Cocoa, Interface Builder
I’ve already gushed about how I’m learning to love Interface Builder but there are still some things that I find annoying.
If Interface Builder is supposed to be WYSIWYG editor, then why can’t I create my toolbar in Interface Builder? I could then preview my complete user interface in Interface Builder. Why on Earth should I be expected to write *so much* code to accompany a mock-up of demo GUI?
It took me ages to get the hang of those darn springs! Is the fixed position relative to the enclosing view or the window? How many people get caught out by this every day? I actually think that the spring metaphor is a good one, but I think its detail as presented in the sizing window of the inspector could be more clear.
In the first instance I think that using a standard widget set is fantastic. This provides fantastic consistency between applications, and really reduces the burden on the user. So why does Apple insist upon changing the look of an app at every release? Take the latest iTunes for example, with its darker toolbar. It looks different to Mail, which both look different to Safari’s metal toolbar. Each time Apple releases a new look the independent developers rush to produce something “similar” such that their app is not deemed to look obsolete.
Is anybody actually following these anymore? John Gruber doesn’t think we should blindly follow them. Daniel Jalkut has a great article on where we go from here. As mac users we’re spoilt for great looking and easy to use GUIs. But I have to ask why does Apple insist on
writing the Human Interface Guidelines when they themselves violate them so frequently. I struggle to think of a single Apple application that obeys all of the HIG.
In short, I am learning to combine the visual approach with a hand-coded approach. There are a lot of things that Interface Builder does well, especially when combined with bindings. However, I can’t help but feel that Interface Builder in its present state is only half the tool it could have been.
Technorati Tags:
Cocoa, Interface Builder
In all of my Cocoa adventures to date, the creation of graphical user interfaces (GUIs) using Interface Builder has been both the best part of the experience and the worst. Coming from a java background I had previously hand coded all of my GUIs, and in the process have gained a valuable insight into the dreaded GridBagLayout manager (yes I am aware of the various java GUI designers, but I have never found one that I like using).
In the early days it was fantastic to create a native GUI with ease pushing the components around, conforming to Apple’s human interface guidelines was a mere snap away. I was blown away, I was able to take charge of tables like never before! But as I began to understand a little more Cocoa and move away from the tutorials I got a little lost. Where do I put this object? Should I instantiate it in the NIB or from the code? I did (and *occasionally* still do) miss connections, and then wonder why things aren’t happening.
However recently I’ve noticed that I am getting better at understanding where to instantiate objects, and how to link code to NIB files and so on. In the event of any unexpected behaviour, a systematic approach seems to solve most bugs and I can finally spot missing actions. It may take time, and even a little patience, but as you travel on your quest for more cocoa knowledge do not fear the NIB!