Modern applications are filled with animation. Press a mouse in the middle of a word-processor window and drag the mouse cursor up, off the window: the window scrolls until you release it. Press the mouse on the window’s down arrow: the window scrolls in the other direction. Clocks have animated hands. Even web browsers have animated icons that tell you they are fetching the next page.
An animation basically consists of three things:
An event that is repeated, perhaps in different locations
A frequency with which the event is repeated
A condition that causes the repetition to stop
Let’s look back at our dragging example and see how it complies with these requirements. When you drag the mouse beyond the top of a word-processor window or click the down arrow, the word processor needs to move down in the document, redraw the window, wait to see if you have released the mouse, and then repeat the process. This is exactly the procedure that programs like Microsoft Word for Windows follow, and as a result, they have an annoying problem: as computers have gotten faster, these programs have scrolled faster. That was fine when PC users were moving from a 100-MHz to a 200-MHz Pentium processor. But now that PC users have 1.4-GHz Pentium processors, Word scrolls so fast that it’s difficult to control.
Cocoa takes a different approach to scrolling. When you drag the mouse off the window or press the mouse on the down arrow, the Application Kit creates a timer to manage the scrolling. The timer triggers a sequence of instructions that moves the contents of the window down and redraws the screen. The timer is registered with the program’s main event loop, so that it is run on a periodic basis — typically 10 times a second. This provides for smooth, continuous scrolling that doesn’t get faster when you switch to a faster computer. (We wish that Microsoft had taken this approach with Word!)
Timers are implemented with Cocoa’s NSTimer class, which is part of Cocoa’s Foundation. The most common way to create a timer is to use the NSTimer class method. The declaration of this method is:
@interface NSTimer : NSObject
...
+ (NSTimer *)scheduledTimerWithTimeInterval:(NSTimeInterval)ti
target:(id)aTarget
selector:(SEL)aSelector
userInfo:(id)userInfo
repeats:(BOOL)yesOrNo;When you create a timer, you specify four arguments:
The fire time for the timer — that is, how long from now it should be fired. This argument is expressed in floating-point seconds.
The target of the timer — that is, the object that will receive the message when the timer fires.
The selector to call in the target.
Data to be provided to the handler each time it is called.
A Boolean flag indicating whether the timer should repeat.
Two things are guaranteed about timers: they will not fire early and they can fire only when the event loop has control. Beyond that, you’re on your own. If you ask that your handler be called every 5 seconds, it may actually be called every 5.3 seconds as a result of all of the other things going on in your Mac. Thus, your handler might be called at 5 seconds, then at 10.3 seconds, then at 15.7 seconds, then at 21 seconds. Your program must be tolerant of this issue.
When the timer is no longer needed, you should get rid of it by invoking its invalidate method:
[aTimer invalidate];
Timed entries are ideal for animation, because they let your program animate some motion in a manner that is independent of the computer’s speed. Even better, the program can still accept events from the user while the animation is taking place.