To figure out what’s going on as touches are received by a view, your code must essentially function as a kind of state machine. You’ll receive various
touches... method calls, and your response will partly depend upon what happened previously, so you’ll have to record somehow, such as in instance variables, the information that you’ll need in order to decide what to do when the next
touches... method is called. Such an architecture can make writing and maintaining touch-analysis code quite tricky. Moreover, although you can distinguish a particular UITouch or UIEvent object over time by keeping a reference to it, you mustn’t retain that reference; it doesn’t belong to you.
Thanks to the existence, starting in iOS 3.2, of gesture recognizers (the subject of the next section), in most cases you won’t have to interpret touches at all; you’ll let a gesture recognizer do most of that work. Even so, it is beneficial to be conversant with the nature of touch interpretation; this will help you interact with a gesture recognizer, write your own gesture recognizer, or subclass an existing one. Furthermore, not every touch sequence can be codified through a gesture recognizer; sometimes, directly interpreting touches is the best approach. Therefore, even though you might not write the sort of code discussed in this section, you should read the section anyway.
To illustrate the business of interpreting touches, we’ll start with a view that can be dragged with the user’s ...