The state of the UIGestureRecognizer. Why is there no such condition as "idle"?

Question

Does anyone have any idea why Apple developed the UIGestureRecognizer in a way that the default state is “possible” (the gesture recognizer has not yet recognized its gesture, but can evaluate touch events. This is the default state.), And not something like “idle time” ?

The “idle” state, in my opinion, will have more meaning and meaning, eliminating the “but can evaluate tangent events” part. "Idle" - when the UIGestureRecognizer has not received any touches and does not perform any analysis (concerns, timers ..). As soon as he receives the first touch, he changes the state to "possible", indicating that he is doing some kind of analysis (recognition logic).

---

* Context: I am writing a similar architecture for another platform. Thus, this state will help to separate gesture recognizers that actually do something from those that did not receive any touches or simply ignored them (to implement the requireGestureRecognizerToFail method).

Answer 1

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

gesture recognizers are a collection of states, including possible ( P ), cancelled ( C ), and ended ( E ). P is the initial state, C and E are the final states. Between P at one end and C and E at the other, there are a number of states, let's call them the family S* . And there are transitions caused by touch events and timer events between all different states. The specific layout of P , S* , C , E and the transitions between them are what give a certain sign of gesture recognition its functionality.

For example, let's say we want a unidirectional recognizer to call a method if the user performs a single press ( 1td ), then a single press ( 1tu ) for 0.5 seconds. Otherwise, we want to cancel it. So, we get the following machine:

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

Highlighted:

 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`. 

When we move to the ended state, the gesture recognizer performs our callback. Thus, these two would remain in order, except that there is a time requirement - the user must release his touch within 0.5 seconds after touching, otherwise the gesture will not be one touch. So, we have the 3rd statement:

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

In addition, we can have a whole bunch of other things that can happen, such as the three-touch event ( 3td ). All these other things will immediately put the machine into a cancelled state. Thus, we could have (among many others) this production:

 (P,3td) -> C 

And so on.

Thus, we can visualize the gesture recognizer as a large machine that accepts as input "letters" from the alphabet of input events, accepts (finishes) a certain set of lines in this alphabet and rejects (cancels) the rest. For those of you who don't know yet, this is the theoretical basis of regular expressions. These right gesture recognizers are just regular expression parsers for the touch alphabet and time events. And the gestures that they recognize are just lines written in this alphabet.

So, we are solving the question: why at the beginning there was no state of inactivity I , which the gesture recognizer "drops" into it a possible state? The reason is that the transition from I to P requires an input event. Suddenly, a line, which is a recognized gesture, becomes longer than one letter, and thus, the recognized gesture is not the gesture we perform, but, for example, a tap, and then a gesture or touch, and then a gesture.

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