Event Handling Best Practices
When handling events, both touch events and motion events, there are a few recommended techniques and patterns you should follow.=> Always implement the event-cancellation methods.
In your implementation, you should restore the state of the view to what it was before the current multi-touch sequence, freeing any transient resources set up for handling the event. If you don’t implement the cancellation method your view could be left in an inconsistent state. In some cases, another view might receive the cancellation message.
=> If you handle events in a subclass of UIView, UIViewController, or (in rare cases) UIResponder,
❏ You should implement all of the event-handling methods (even if it is a null implementation).
❏ Do not call the superclass implementation of the methods.
=> If you handle events in a subclass of any other UIKit responder class,
❏ You do not have to implement all of the event-handling methods.
❏ But in the methods you do implement, be sure to call the superclass implementation. For example,
[super touchesBegan:theTouches withEvent:theEvent];
=> Do not forward events to other responder objects of the UIKit framework.
The responders that you forward events to should be instances of your own subclasses of UIView, and all of these objects must be aware that event-forwarding is taking place and that, the the case of touch events, they may receive touches that are not bound to them.
=> Custom views that redraw themselves in response to events should only set drawing state in the event-handling methods and perform all of the drawing in the drawRect: method.
=> Do not explicitly send events up the responder (via nextResponder); instead, invoke the superclass implementation and let the UIKit handle responder-chain traversal.
No comments:
Post a Comment