Let’s now return to the very beginning of the touch reporting process, when the system sends the app a UIEvent containing touches, and tease apart in full detail the entire procedure by which a touch is delivered to views and gesture recognizers.
When the user puts a finger to the screen and a touch event arrives at the app, the app follows a standard procedure for delivering touches:
The application calls the UIView instance method
hitTest:withEvent:on the window, which returns the view (called, appropriately, the hit-test view) that will be associated with this touch. This method uses the UIView instance method
hitTest:withEvent:recursively down the view hierarchy to find the deepest view containing the touch’s location and capable of receiving a touch.
Having determined the hit-test view of every touch in an event, the application calls its own
sendEvent:, which in turn calls the window’s
sendEvent:. The window delivers the touches by calling the appropriate
touches...method(s), as follows:
- As a touch first appears, it is delivered to the hit-test view’s swarm of gesture recognizers. It is then also delivered to that view.
The logic of withholding touches is implemented for views (but not for gesture recognizers). For example, additional touches won’t be delivered to a view if that view currently has a touch and has
multipleTouchEnabledset to NO (but they will be delivered to that view’s swarm of gesture recognizers).