UIGestureRecognizer состояния. Почему нет такого состояния, как «холостой»? - PullRequest
4 голосов
/ 03 марта 2012

Кто-нибудь знает, почему Apple разработала UIGestureRecognizer способ, которым состояние по умолчанию является "возможным" ( Распознаватель жестов еще не распознал свой жест, но может оценивать события касания. Этосостояние по умолчанию. ), а не что-то вроде «бездействия»?

Состояние «бездействия», по моему мнению, имело бы больше смысла и смысла, исключив «», но может оценивать события касания " часть.«Idle» - когда UIGestureRecognizer не получил никаких касаний и не выполняет никакого анализа (касания, таймеры ...).Как только он получает первое касание, он меняет свое состояние на «возможное», что указывает на то, что он выполняет какой-то анализ (логика распознавания).


* Контекст: я пишу аналогичную архитектуру для другой платформы,Поэтому это состояние поможет отделить распознаватели жестов, которые на самом деле что-то делают, от тех, которые не получили никаких касаний или просто игнорировали их (для реализации метода requireGestureRecognizerToFail).

1 Ответ

3 голосов
/ 13 марта 2012

Мы должны думать с точки зрения конечных автоматов . Текст моего автомата колледжа: Автоматы и вычислимость Декстера Козена.

Распознаватели жестов - это набор состояний, включая possible (P), cancelled (C) и ended (E). P - это начальное состояние, C и E - это конечные состояния. Между P на одном конце и C и E на другом существует ряд состояний, назовем их семейством S*. И есть переходы, вызванные событиями касания и событиями таймера, между всеми различными состояниями. Конкретное расположение P, S*, C, E и переходы между ними - вот что дает определенному распознавателю жестов его функциональность.

Например, допустим, мы хотим, чтобы распознаватель одним касанием вызывал метод, если пользователь выполняет однократное касание (1td), а затем однократное касание (1tu) в течение 0,5 секунд. И в противном случае мы хотим отменить. Итак, мы получаем следующую машину:

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

прописано:

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

Именно когда мы достигаем состояния ended, распознаватель жестов выполняет наш обратный вызов. Таким образом, эти двое были бы хороши, за исключением того, что есть требование времени - пользователь должен отпустить свое прикосновение в течение 0,5 секунд после приземления, иначе жест не будет действительно единственным прикосновением. Итак, у нас есть 3-е производство:

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

Кроме того, у нас может быть целый ряд других вещей, которые могут произойти, например, событие «три касания» (3td). Все эти другие вещи немедленно переведут машину в состояние cancelled. Таким образом, мы могли бы иметь (среди многих других) эту продукцию:

(P,3td) -> C

и т. Д.

Таким образом, мы можем визуализировать распознаватель жестов как большую машину, которая принимает в качестве входных «букв» из алфавита входных событий, принимает (заканчивает) некоторый набор строк в этом алфавите и отклоняет (отменяет) другие. Для тех из вас, кто еще не знает - это теоретическая основа регулярных выражений. Это верно - распознаватели жестов - это просто парсеры регулярных выражений в алфавите касания и времени событий. И распознаваемые ими жесты - это просто строки, написанные на этом алфавите.

Итак, мы подошли к сути вопроса - почему бы не иметь в начале состояние простоя I, которое «запускает» распознаватель жестов в его состояние possible? Причина в том, что для перехода с I на P требуется событие ввода. Внезапно строка, которая является распознаваемым жестом, становится на одну букву длиннее - и, таким образом, распознанный жест - это не тот жест, к которому мы стремимся, а, например, касание и затем жест, или касание, а затем жест .

Это изменяет распознаваемый жест и, таким образом, наносит ущерб нашей цели.

...