The Responder Chain
A responder is an object that knows how to receive UIEvents directly (see the previous section). It knows this because it is an instance of UIResponder or a UIResponder subclass. If you examine the Cocoa class hierarchy, you’ll find that just about any class that has anything to do with display on the screen is a responder. A UIView is a responder. A UIWindow is a responder. A UIViewController is a responder. Even a UIApplication is a responder.
If you look in the documentation for the UIResponder class, you’ll find that it implements four low-level methods for receiving touch-related UIEvents: touchesBegan:withEvent:
, touchesMoved:withEvent:
, touchesEnded:withEvent:
and touchesCancelled:withEvent:
. These are called to notify a responder of a touch event. No matter how your code ultimately hears about a user-related touch event — indeed, even if your code never hears about a touch event (because Cocoa reacted in some automatic way to the touch, without your code’s intervention) — the touch was initially communicated to a responder through one of these methods.
The mechanism for this communication starts by deciding which responder the user touched. The UIView methods hitTest:withEvent:
and pointInside:withEvent:
are called until the correct view (the hit-test view) is located. Then UIApplication’s sendEvent:
method is called, which calls UIWindow’s sendEvent:
, which calls the correct method of the hit-test view (a responder). I’ll cover all this again in full detail ...
Get Programming iOS 4 now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.