One of the greatest things about the iOS platform and applications people see on it is its beauty. Smooth gradients, consistent transitions, and animations that illustrate the transition of UI elements from one state to another. Animations are more than flashy eye-candy; they tell the user what’s happening. If an element is being deleted, instead of it simply disappearing it fades or slides out of view. Unlike traditional desktop or web applications where a “2 items deleted” statusbar message is necessary, these animations are in many cases enough.

Knowing where to start with animations can be a problem for developers though, because there’s many different steps involved. Instead of walking you through it fully here in the blog, I highly recommend you watch the WWDC 2010 videos on the topic. I truly mean it; anything I do here will simply be a rehash of that material, and I don’t see the point in reproducing perfectly good documentation unnecessarily.

• WWDC 2010 Session 123 – Building Animation Driven Interfaces
• WWDC 2010 Session 424 – Core Animation in Practice, Part 1
• WWDC 2010 Session 425 – Core Animation in Practice, Part 2

I’ve often been asked by people about where to start with iOS programming, whether they be co-workers, colleagues in the same line of work at other companies, or even total strangers who happen to see me happily working away on my personal projects in Xcode. Some rather naïve people assume that I learned from a book, still others even think I took a class to learn all of this! I can say definitively that it’s in my opinion that to be a great iOS developer, you just need to write apps, and lots of them. Experiment, try different things out, and more importantly, buy a few really good iPad and iPhone apps so you can see for yourself the design patterns that make good apps, and those that make poor apps.

I recently had to improve the performance of a few views that utilized CALayer-based shadows on rounded-rect UIView objects. On this particular iPad application, when the device was rotated, the views rotated quite a lot slower than we would have hoped. It wasn’t a show-stopper, but the jerky rotation animation made it look cheap and unpolished. The easiest way to have our cake, and eat it too, was to set a custom CGPath to the layer’s shadowPath property. This told UIKit to set the inside of the path to opaque, reducing the amount of work the rendering engine needed to perform.

As some of you may be aware, I have enough allergies to various common foods to have earned the name “bubble-boy” from my friends. In fact, my wife’s friends used to semi-joke about me while we were first engaged that she should take a good life-insurance policy out on my, “just i n case”. She used to laugh at that, until she had to race me to the hospital a couple times, or stay up all night to make sure I didn’t stop breathing. Now it’s not a laughing matter. Now she’s paranoid for me wherever I go, always carries a spare epipen with her, and arranges our travel schedules around flights and hotels that can accommodate allergies.

For myDrumPad the main pad buttons are images. I create a UIButton object, and use setBackgroundImage:forState: to customize which image will be used for each state (UIControlStateNormal and UIControlStateHighlighted mainly).  I customize the title label font, shadow and color, and voilà I have a pad button that simulates the look and feel of  a Korg padKONTROL. There’s just a few small problems with it.

1. The images on the iPad are fairly large, and memory is at a premium.
2. The size of these buttons can change in portrait vs. landscape. It’s time-consuming to export different versions from Photoshop for the different orientations.
3. The buttons are sized differently depending on the size of the button grid (e.g. a 3×3 grid of buttons have larger images than 4×4 or 5×5 grids). If I resize these images on-the-fly, then the edges look blurred and aren’t well-defined.
4. The retina display complicates all of this, meaning I have to have two versions of each image.
5. I want to be able to customize the buttons to have different colors when you’re on different drum sets.

Because of that long list, simply using an image isn’t good enough. But instead of drawing my images using regular Core Graphics drawing routines, I’m going to use Core Animation Layers, or CALayers, to accomplish the same thing. Ultimately I want my buttons to be able to be animated, to change color, and to feel more “alive” than a static image could accomplish.

Passwords are definitely fickle beasts.  I’m used to juggling a multitude of different semi-incomprehensible passwords containing a mixture of numbers, symbols, upper and lower-case letters, and in some cases unicode characters (letters such as ü, • and §). And for some mysterious reason I’m able to remember these gibberish-filled passwords with ease. But despite all this, when asked to input a 4-digit passcode into my iPhone to be able to lock my phone (a requirement for hooking it up to my company Exchange server), I couldn’t keep that simple password in my head for longer than 8 minutes.

Boomle is by far the lowest-selling app I have published on the iTunes App Store, and sadly as a result I just haven’t had the motivation to dedicate more time to it. However it’s times that I see people using it in person that I see just how much people enjoy playing it. I really hope I’ll have time to revisit it, because it’s one of those games that people just “get”, and is enjoyably challenging throughout the whole game.

My life is pretty darned busy right now. Transitioning to a new job, travel for work, helping @dccp with her travel arrangements for her academic conferences, my own iOS projects, and my blog. Since the time I have available to work on my own coding experiments is limited to evenings and weekends. I’ve been recently attempting to focus on just one or two projects at a time, since for a while there I was coming up with at least 3 new prototypes per week.  Focusing on myDrumPad has really made it easy for me to give it the extra polish and attention it needs to take it to the next level. However, since I started participating in NaBloPoMo, the National Blog Posting Month, this has been consuming a great deal of my free time.

For as long as I’ve been a developer, there was only ever once when I had a machine that I felt was an adequate development workstation. That was around 2001 when I had a dual-proc 667MHz P3 768MB RAM and three 17″ CRT monitors. This baby put out enough heat that my home-office didn’t need a heater on during the rainy Seattle winters; in fact, it was so warm in there that I’d wear shorts, a tee-shirt, and left the window wide open.

One of the things that’s hard as a developer is keeping your legacy code up to date.  It’s all too easy to fire-and-forget; write your code, debug it just enough so that it compiles, and then forget it until it breaks again.  I’m guilty of that as well.  In fact, just today I discovered that my continuous deployment configuration for Boomle was broken…for the past 3 months.

After merging my code from a private repo over to Github, it still didn’t work.  After updating the Hudson build configuration to point at the proper repos and to respond to the proper webhooks (to get automatically triggered on a new check-in), it STILL didn’t work.  You see, not only does configuration change, but SDKs and APIs shift out from under you.  The iOS SDK had changed out from under my project, and the Xcode configuration was pointing at libraries and SDKs that no longer were shipped by Apple.