“A list of things that you must do for every app. Most of these should be done up front; some can be put off a little bit; some can be put off a long time, but ought to be done at some point rather than put off into the indefinite future.”

(Via Domain of the Bored.)

I’d agree with all of Peter’s comments- I can’t stress point 1 enough!

(Via Manton Reece.)

Well done Manton, I can only hope that my first product will do as well as yours!

Technorati Tags:
Cocoa, Interface Builder

1. Toolbars

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?

2. Resizing Springs

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.

3. Consistent Look and Feel

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.

4. Human Interface Guidelines

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 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!

imagename=”$PROJECT_NAME.dmg”
if [ -e "$imagename" ]
then
rm “$imagename”
fi
hdiutil create -srcfolder $CONFIGURATION_BUILD_DIR -volname “$PROJECT_NAME” “$imagename”

It’s all fairly simple bash script, and logically executes the statements. The most difficult part of the project was remembering to escape the variables in the hdiutil command. The next step will be subversion integration for version numbers. Stay tuned!

Technorati Tags:
Cocoa, Xcode

The instructor for the course is Aaron Hillegass, author of the highly regarded introductory text on Cocoa programming. The book forms the majority of the course materials, and quite rightly so. It is both well written and easy to follow. In addition to the book another 6 as yet unpublished chapters are used, covering concepts like advanced objective-c, a better understanding of bindings and CoreData.

I’ve been to many courses, but none have been so intensive. There is a lot to cover, but each concept is introduced with a short lecture, followed by activities with enough depth to challenge those that work quickly and those that like to work a little slower or apply the concept to something slightly different.

After a days hard work most students returned to the classroom to play around with what had been covered that day, or work on personal projects. During this time Aaron was available to iron out any wrinkles or help solve any bugs that cropped up.

The real value of the course can only be seen afterwards. I am delighted with how my personal projects have been developing since I returned from the course.

I went as a privateer, and had some initial reservations about the high cost of the course, although these reservations are now a distant memory! So if you have an interest in Cocoa programming or a need to program in Cocoa then book yourself a place on the course today (and if you can get your company to pay for it then all the better!).