Physics & Collisions - Learn SpriteBuilder for iOS Game Development - page 97

Listing 4-2 . Stopping acceleration when there's no active touch
-(void) touchEnded:(UITouch *)touch withEvent:(UIEvent
*)event
{
_acceleratePlayer = NO;
}
-(void) touchCancelled:(UITouch *)touch withEvent:(UIEvent
*)event
{
[self touchEnded:touch withEvent:event];
}
The cancelled variant is sent rarely—for instance, when a gesture recognizer recognizes a
touch pattern. But when it does get called, it's important that it behaves the same as
touchEnded: or else the player will be stuck in the acceleration mode even though the
user may not have a finger on the screen.
Tip Instead of replicating the functionality of touchEnded: in touchCan-
celled: I just forward the message. In this case, it's a one-liner either way,
but generally it's good practice to avoid writing the same code more than once.
It's called the DRY principle : Don't Repeat Yourself. It's single-handedly the
most important programming principle, even more important than premature
optimization, which is the root of all evil, in case you didn't know. Premature
optimization can be paraphrased as follows: Make it work—make it
right—make it fast. In that order. But I'm digressing. If you want to conduct an
exercise, do a web search for these phrases and read some of the top articles.
Now the update: method also needs to be amended by calling the accelerateTar-
get: method as long as the _acceleratePlayer ivar is YES . This is shown in List-
ing 4-3 .
Listing 4-3 . Accelerate the player node as needed
-(void) update:(CCTime)delta
{
if (_acceleratePlayer)
{