Question

Does anyone have any idea why Apple designed UIGestureRecognizer the way that default state is “possible” (The gesture recognizer has not yet recognized its gesture, but may be evaluating touch events. This is the default state.) rather then something like “idle”?

The “idle” state in my opinion would make more sense and meaning by eliminating “but may be evaluating touch events” part. “Idle” — when UIGestureRecognizer hasn’t received any touches and doesn’t perform any analysis (touches, timers..). As soon as it receives first touch it changes it’s state to “possible”, indicating that it performs some sort of analysis (recognition logic).

---

*Context:
I’m writing similar architecture for another platform. So this state would help to separate gesture recognizers which are actually doing something from those which haven’t received any touches or just ignored them (for implementing requireGestureRecognizerToFail method).

Answer 1

We must think in terms of finite state machines. My college automata text: Automata and Computability by Dexter Kozen.

Gesture recognizers are a set of states, including possible (P), cancelled (C), and ended (E). P is the start state, C and E are final states. Between P on one end and C and E on the other, there is a series of states, let’s call them the family S*. And there are transitions, triggered by touch events and timer events, between all of the various states. The particular arrangement of P, the S*, C, E, and the transitions between them all, are what give a particular gesture recognizer its functionality.

For example, let’s say we want a single-touch recognizer to call a method if the user performs a single-touch down (1td), then single-touch up (1tu) within .5 seconds. And otherwise we want it to cancel. So we get the following machine:

(P,1td) -> S
(S,1tu) -> E
(S,.5s) -> C

Spelled out:

When in state `possible`, upon receipt of a single touch-down event, transition to state `S`.
When in state `S`, upon receipt of a single touch-up event, transition to state `ended`.

It is when we get to the state ended that the gesture recognizer executes our callback. So those two alone would be fine, except that there’s a time requirement – the user must release his touch within .5 seconds of the touch-down, or else the gesture is not truly a single touch. So we have a 3rd production:

When in state `S`, if a .5 second timer triggers (`.5s`), then enter state `cancelled`.

Also, we might have a whole bunch of other things which could happen, such as a ‘three touch-down’ (3td) event. All of these other things would immediately move the machine into the cancelled state. So we might have (among many others) this production:

(P,3td) -> C

And so on.

Thus we can visualize a gesture recognizer as a big machine that takes as input “letters” from an alphabet of input events, accepts (ends) some set of strings in that alphabet, and rejects (cancels) the others. For those of you who don’t already know – this is the theoretic underpinning of regular expressions. That’s right – gesture recognizers are just parsers of regular expressions over an alphabet of touch and timing events. And the gestures that they recognize are just strings written in that alphabet.

So we get to crux of the question — why not have an idle state I at the beginning, one which ‘kicks off’ the gesture recognizer into it’s possible state? The reason is that to transition from I to P requires an input event. Suddenly, the string that is the gesture being recognized becomes one letter longer — and thus the gesture recognized is not the gesture we are after, but, for example, a tap and then the gesture, or a touch-down and then a gesture.

This changes the gesture that is recognized and thus defeats our purpose.