Motion Events | iPhone Apps Tutorial pdf

Motion Events

An iPhone or iPod touch device generates motion events when users move the device in a certain way, such as shaking it. Motion events have their origin in the device accelerometer. The system evaluates the accelerometer data and, if it meets certain criteria, interprets it as a gesture. It creates a UIEvent object representing this gesture and sends the event object to the currently active application for processing.
Note: Motion events were introduced in iPhone OS 3.0. In this version, only shaking motions are interpreted as gestures and become motion events.

Motion events are much simpler than touch events. The system only tells an application when the motion starts and when it stops, and not when each individual motion occurs. Moreover, whereas a touch event includes a set of touches and their related state, a motion event carries with it no state other than the event type, event subtype, and timestamp. The system interprets motion gestures in such a way as to not conflict with orientation changes.
To receive motion events, the responder object that is to handle them must be the first responder.
Becoming first responder
- (BOOL)canBecomeFirstResponder {
return YES;
}
- (void)viewDidAppear:(BOOL)animated {
[self becomeFirstResponder];
}
To handle motion events, a class inheriting from UIResponder must implement either the motionBegan:withEvent: method or motionEnded:withEvent: method, or possibly both of these methods (see “Event Handling Best Practices” (page 96)). For example, if an application wants to give horizontal shakes and vertical shakes different meanings, it could cache the current acceleration axis values in motionBegan:withEvent:, compare those cached values to the same axis values in motionEnded:withEvent:, and act on the results accordingly. A responder should also implement the motionCancelled:withEvent: method to respond to events that the system sends to cancel a motion event; these events sometimes reflect the system’s determination that the motion is not a valid gesture after all.
Program shows code that handles a shaking-motion event by resetting views that have have been altered
(by translation, rotation, and scaling) to their original positions, orientations, and sizes.
Handling a motion event
- (void)motionBegan:(UIEventSubtype)motion withEvent:(UIEvent *)event
{
}
- (void)motionEnded:(UIEventSubtype)motion withEvent:(UIEvent *)event
{
[UIView beginAnimations:nil context:nil];
[UIView setAnimationDuration:0.5];
self.view.transform = CGAffineTransformIdentity;
for (UIView *subview in self.view.subviews) {
subview.transform = CGAffineTransformIdentity;
}
[UIView commitAnimations];
for (TransformGesture *gesture in [window allTransformGestures]) {
[gesture resetTransform];
}
}
- (void)motionCancelled:(UIEventSubtype)motion withEvent:(UIEvent *)event
{
}
An application and its key window deliver a motion event to the window’s first responder for handling. If the first responder doesn’t handle it, the event progresses up the responder chain in a way similar to touch events until it is either handled or ignored. (See “Event Delivery” (page 78) for details.) However, there is one important difference between touch events and shake-motion events. When the user starts shaking the device, the system sends a motion event to the first responder in a motionBegan:withEvent: message; if the first responder doesn’t handle the event, it travels up the responder chain. If the shaking lasts less than a second or so, the system sends a motionEnded:withEvent: message to the first responder. But if the shaking lasts longer, or if the system determines the motion is not a shake, the first responder receives a motionCancelled:withEvent: message.
If a shake-motion event travels up the responder chain to the window without being handled, and the applicationSupportsShakeToEdit property of UIApplication is set to YES, iPhone OS displays a sheet with Undo and Redo commands. By default, this property is set to YES.