Разрабатывая ответ hackbod, вы, вероятно, должны иметь в качестве последнего утверждения метода return super.onTouchEvent(event);
.
Полагаю, что если вы не обработаете событие и не вызовете поведение просмотра по умолчанию, то никто ничего не сделает, и ничего не произойдет.
Точка возвращаемого значения может, например, вызывать поведение по умолчанию некоторого предка и сообщать производному классу, обработал ли предок событие или нет.
После поиска в Android Developer, обращаясь к теме , переопределяем существующий метод обратного вызова для View здесь он говорит:
Это позволяет вам определять поведение по умолчанию для каждого события в вашем настраиваемом представлении и определять, следует ли передавать это событие другому дочернему представлению.
Следовательно, основная идея возвращаемого значения состоит в том, чтобы сообщить Android, должно ли событие быть передано дочерним представлениям или нет.
НТН
Edit:
Что касается "указаний", которые вы упоминаете в своем комментарии, то, вообще говоря (т.е. не только в Android) процесс обработки событий в пользовательском интерфейсе происходит примерно так:
В какой-то момент ваш производный пользовательский элемент управления получает событие. В вашей реализации перехвата событий вам решать, будет ли включать поведение вашего предка или нет. Это все, что у вас есть относительно направления наследования классов .
Затем есть другое направление, связанное с иерархией элементов управления UI . Ваш пользовательский элемент управления может содержаться в одном большем контейнере элемента управления, а ваш элемент управления может также содержать другие внутренние элементы управления (текстовые поля, кнопки, ...). Что касается этого направления, если вы объявите, что не обрабатываете событие (возвращает false), тогда механизм обработки событий пользовательского интерфейса передаст контейнер элементу управления , содержащему (?) (Например, тот, что на вашем фоне).