Ian Robinson posted a callout to any Cocoa developers in Northern Ireland (and wannabees, I presume). He wants to form a group to get together in order to dicuss Mac and iPhone development. Great stuff.
However, there’s another fledgling group of misfits meeting under the banner of Xcake.
Let’s get together, and code ! (You kinda have to sing that so it doesn’t sound *too* silly)
I’m a geek and a coder. It’s inevitable, then, that I’ll collect a huge number of books about every geeky, coding subject going. I have countless books on Java, Python, C, testing, framework-this, framework-the-other. A new batch is adding another layer of veneer on my desk at home: the Mac development books.
The issue is, though, that I seem incapable of picking up one book and working through it to the end. I’m time-slicing my scant resources over countless books. This leads to an unfortunate outcome: I learn nothing from any of them (another side effect being the sizable amount of money that I’ve basically wasted over the years).
Reading has become a wholly mechanical activity. I open the book, scan it for all the pictures (being turned off immediately if the word/picture ratio is too high … I like to think of myself as a visual learner, rather than shallow), and then follow the steps in all the programming examples. I end up with lots of example applications, but ask me how they work, or ask me to build one of them from scratch without the aid of the book, and I’d probably struggle.
This is not the fault of the books themselves (although, there are some decidedly sub-par tech books on the market, and most of those have red covers), it’s just that I have an awful lack of attention and focus. So, I’ve decided to take the bull by the horns, and force myself to abide by these rules from now:
The book at the top of the stack is Aaron Hillegass’ Cocoa Programming for MacOSX, 3rd edition. The author builds a little application throughout the book, and my plan is to write another little application in parallel, only referring to the book as reference where necessary. That’s rules 1 & 2 covered. For rule 3, if anyone is also reading through this book, get in touch.
Last night at XCake showed me just how much catching up I have to do if I’m going to be an active (useful) member of the MacHack community here.
So, I started with Bill Dudney’s Core Animation for OS X tonight.
I’ve only got through the first chapter so far, and one very tiny code example, but already I’m looking forward to getting deeper into the book and the subject.
The very first code example shows the way things are going. The author provides a little project that moves a picture from one point in a window to a new point, on a keypress. Then, with one change in the code, the image is animated along the path, rather than simply disappearing from one and appearing in another.
Like most things that Apple dream up, it’s all magic, and yet all perfectly logical. Instead of dealing directly with the thing you want to animate, you request it’s animator proxy. Then, instead of telling the window to move, you tell its proxy, and it’s the proxy’s job to interpolate everything from the start position to the end within the time alloted to the animation. Simple!
Actually, the animator proxy delegates (it’s amazing how often that word crops up in Mac development) the actual interpolation to an implementation of CAAnimation. The animator proxy looks up the implementation for the specific action you’re attempting (setFrame: for instance) and it does the interpolation between the fromValue (usually the current position) and the toValue (the argument passed to setFrame: in this case). Brilliant!
The intriguing part will come later when the book goes on to talk about how you write your own CAAnimation implementations are make them available to the animator proxies.
We’ll see how it goes from here (to there).
Update: Isn’t amazing how boring I can make such an exciting subject sound? Maybe I should’ve followed a career in higher education.