Understanding iOS Animation - dummies

By Neal Goldstein, Dave Wilson

Fortunately, most of what you need to do as far as iOS animation is concerned is already built into the framework. Some view properties can be animated (the center point, for example), which means that you just need to tell the view where to start and where to end, and a few other optional parameters, and you’re done.

The view itself (in the UIView base class) has the functionality to animate the move. To give you some context in which to understand how animation on the iPhone and iPad works, however, you need to understand what goes on under the hood when a framework takes care of the animation chores for you.

More specifically, you need to delve a bit deeper into views, their properties, and the coordinate systems on the iPad.

View geometry and coordinate systems

The default coordinate system in UIKit places its origin in the top-left corner and has axes that extend down and to the right from the origin point. Coordinate values are represented using floating-point numbers, and you don’t have to worry about the screen resolution; the frameworks take care of that automatically.

The figure shows this coordinate system relative to the iPad screen. In addition to the screen coordinate system, views define their own local coordinate systems that allow you to specify coordinates relative to the view instead of relative to the screen.

The coordinate system on an iPad screen (with a split view).
The coordinate system on an iPad screen (with a split view).

Because every view and window defines its own local coordinate system, whenever you’re drawing or dealing with coordinates, you’ll need to pay attention to which coordinate system you’re using. It sounds ominous, but it’s really not that big a deal after you get into the rhythm of working with the coordinate systems.

Points versus pixels

Okay, so where does the high-resolution display come in?

In iOS, all coordinate values and distances are specified using floating-point values in units referred to as points. The measurable size of a point varies from device to device and is largely irrelevant. The main thing to understand about points is that they provide a fixed frame of reference for drawing.

For example, the screen dimensions (width x height) for the iPhone 4s is 480 x 320 points and for the iPad are 1024 x 768 points.

So although an iPhone 4s with Retina display has a 960-by-640-pixel resolution (a pixel density of 326 pixels per inch [ppi]) and a non-Retina display has a 480-by-320-pixel resolution (163 ppi), as long as you design your interface to fit the screen sizes in points, your views will display correctly on the corresponding type of device. The same principles apply with non-Retina and Retina display on the iPad.

The takeaway here is, “Don’t worry about the resolution; concentrate on points and you’ll be fine.”

A view’s size and position

A view object’s location in a coordinate system is determined using either its frame or its center property:

  • The frame property contains the frame rectangle, which specifies the size and location of the view in its super view’s coordinate system.

  • The center property contains the known center point of the view in its super view’s coordinate system.

In your wanderings, you may someday encounter the bounds property. It’s tied up with the bounds rectangle, which specifies the size of the view (and its content origin) in the view’s own local coordinate system.

The figure shows the frame of the iPad’s Main view (not the Image view) with an origin of x = 0 and y = 20. Its size is shown as width = 320 and height = 460. The reason that its origin is at y = 20 is that its frame is in its window coordinates (its super view), and it has to share the window with the status bar which is, as you might deduce, 20 pixels high.