Simple Animations on iOS

08 March 2011
3 comments

Anyone who has used iOS will be familiar with the way Apple uses animation in their apps. It's one of the most delightful features of the platform and users loved it, even before there was an App Store. If you use apps that don't employ judicious animation, you get a sense of something missing, of an undefinable lack of quality.

Of course, this means that you need to think hard about animation when designing an app for iOS. On platforms I've used in the past, good, smooth animation was hard to achieve and the payoff always seemed to be too small to invest the time in getting it right.

But Apple have done an amazing job with iOS, which comes with their Core Animation framework built in. As with many Apple technologies, it's ridiculously easy to get the basics right but you can also get extremely fine-grained control should you want to do more than Apple have provided for.

I think this philosophy is one of the biggest reasons for the incredible success of the App Store. Almost anyone can have a simple, good-looking application up and running in no time flat, but there are nearly always ways to get under the skin of the Apple frameworks to deliver exactly the right experience for users.

** Enter Holler Gram

Last year, almost the entire company went to Austin for the SXSW interactive festival and, to celebrate, we redesigned our homepage specially for the event. We were wondering what we could do this year, and we were all keen on the idea of creating an MxM SXSW iPad app. The result is Holler Gram, a very simple but, we hope, elegant and fun app that lets you provide instant feedback on a talk or amuse your drinking buddies with your wit. Check it out in the App Store. Go ahead, it's free!

In Holler Gram we use two very simple animations: a zoom transition and a fade transition. iOS provides an incredibly simple way to implement a basic animation. All you do is to state the start condition, the end condition and then the duration of the animation. Core Animation does the rest.

** Zoom

When you are in the 'At a Session' section of the app, you can select from a list of Conor's beautifully designed slides. When you tap one of the slides, it zooms to fill the whole screen. Here's how you do that in Core Animation.

In the code below, our view – called 'self' (i.e. the current view) – has an initial size of 200 x 150 points. We then specify the animation we want between the calls to 'beginAnimations' and 'commitAnimations'.

In this example, we set the duration of the animation to be half a second and the size we want our view to end up. The important thing here is that the size does not change at this point, because we are in the middle of a beginAnimations/commitAnimations block. Instead, the animation begins the moment 'commitAnimations' is called. Core Animation works its magic, and over the half second the view's size will grow linearly from 200 x 150 to 1024 x 768 points.

Here's the code:

self.frame = CGRectMake(0.0f, 0.0f, 200.0f, 150.0f);

[UIView beginAnimations:@"Zoom" context:NULL];

[UIView setAnimationDuration:0.5];

self.frame = CGRectMake(0.0f, 0.0f, 1024.0f, 768.0f);

[UIView commitAnimations];

** Fade-in

The other animation we use is a fade. If you go to the 'Set your score' section of the app, you can choose a mark out of ten and then tap the 'Display my rating' button. When you do so the screen is filled with your score, but there's a subtle fade transition so that it doesn't feel too jarring.

Here's how it's done. To start with, we set our view to be invisible by setting its alpha property to zero (i.e. completely transparent). As before, the Core Animation handles any changes we specify between between our calls to 'beginAnimations' and 'commitAnimations'. This time, we want the animation to last one second, and we want it to animate the alpha value towards 1 (i.e. fully opaque).

Here's the code:

self.alpha = 0.0;

[UIView beginAnimations:@"Fade-in" context:NULL];

[UIView setAnimationDuration:1.0];

self.alpha = 1.0;

[UIView commitAnimations];

** Why 'Points' not 'Pixels'?

When Apple announced the iPhone 4, they called the new, high pixel density display the 'Retina display'. The Retina Display has precisely twice the number of pixels as the previous iPhone models in exactly the same size of screen. The result is an incredibly sharp display because it's physically difficult to see the individual pixels.

As usual, Apple thought about the impact this would have on developers, making it as easy as possible to support both displays from the same codebase.

As a result, we don't talk about pixels when defining the sizes of images or views in our iOS apps. Instead, iOS deals in points, which it automatically converts to pixels as appropriate for the device it's running on. If it's an iPhone 3GS, a point is one pixel. If it's an iPhone 4, a point is a four pixel square: four times the area. If we were running on an iPhone 4, the image in our first example would actually end up being 2048 pixels by 1536. As programmers, we would not need to worry about that because iOS does the conversion for us. The only inconvenience is that we need to provide two versions of every image, one twice the size of the other.

But this is an iPad app, not an iPhone app, and iPads don't have Retina Displays. Well, not yet they don't. But here's another reason that Apple makes it easy to write apps for iOS: our code will not have to change at all to take advantage of the new display if (or, rather, when) it comes.

Steve Jobs doesn't bound all over the stage shouting "Developers, developers developers", but that doesn't mean that Apple doesn't care about coders. Quite the opposite, in fact. iOS is a pleasure to write code for.