“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!
I’ve finally finished at university for Easter where the last few weeks have been particularly hectic. I’ll mostly be spending the holiday writing my project report, but I’ve got some cocoa projects that I’ve been neglecting for a while now. I’ll be easing myself back in with a little freebie, which I hope to have complete by next week.
Cocoa its good to be back!
First 75 days of Wii Transfer: “In the tradition of other independent Mac developers such as Mike Zornek, Daniel Jalkut, and Gus Mueller, I’m going to share some sales information from the first 75 days of Wii Transfer.”
(Via Manton Reece.)
Well done Manton, I can only hope that my first product will do as well as yours!
I’ve done something stupid (again!). I recently read a great article on avoiding the use of the float data type in financial applications. I said I’d forward the article on to a friend, but I can’t seem to find it. Does anybody know the article I mean? All help appreciated. Cheers!
[Update] I’ve found the article I meant. It was over at allocinit.net. I found it in a slightly unusual way however, that may be of use to others. I found the site to which it linked, and then used Google to search for sites that linked to the paper using the link: prefix. Lo and behold the site I was looking for was in the first couple of hits 
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 was sorry to hear about the recent events at the Big Nerd Ranch. Just prior to their excellent Cocoa course all of the equipment was stolen and the classroom was burnt down. Well done to Emily and Jaye for getting things organized so quickly. I hope that you guys are back on track soon!
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!
I’d been meaning to put together a script to automate the creation of disk images for a while now. I thought I’d link it in with the build phase, so I could have a brand spanking new disk image for each build. I’m placing the script below for anyone to use.
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!
Now that I’m back from the Big Nerd Ranch I thought I’d write my own review, as it was the reviews of others that had finally persuaded me to book my place.
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!).