Полный список
Раньше мы для View-компонентов использовали OnClickListener и ловили короткие нажатия. Теперь попробуем ловить касания и перемещения пальца по компоненту. Они состоят из трех типов событий:
— нажатие (палец прикоснулся к экрану)
— движение (палец движется по экрану)
— отпускание (палец оторвался от экрана)
Все эти события мы сможем ловить в обработчике OnTouchListener, который присвоим для View-компонента. Этот обработчик дает нам объект MotionEvent, из которого мы извлекаем тип события и координаты.
На этом уроке рассмотрим только одиночные касания. А мультитач – на следующем уроке.
Project name: P1021_Touch
Build Target: Android 2.3.3
Application name: Touch
Package name: ru.startandroid.develop.p1021touch
Create Activity: MainActivity
strings.xml и main.xml нам не понадобятся, их не трогаем.
MainActivity реализует интерфейс OnTouchListener для того, чтобы выступить обработчиком касаний.
В onCreate мы создаем новый TextView, сообщаем ему, что обработчиком касаний будет Activity, и помещаем на экран.
Интерфейс OnTouchListener предполагает, что Activity реализует его метод onTouch. На вход методу идет View для которого было событие касания и объект MotionEvent с информацией о событии.
Методы getX и getY дают нам X и Y координаты касания. Метод getAction дает тип события касания:
ACTION_DOWN – нажатие
ACTION_MOVE – движение
ACTION_UP – отпускание
ACTION_CANCEL – практически никогда не случается. Насколько я понял, возникает в случае каких-либо внутренних сбоев, и следует трактовать это как ACTION_UP.
В случае ACTION_DOWN мы пишем в sDown координаты нажатия.
В случае ACTION_MOVE пишем в sMove координаты точки текущего положения пальца. Если мы будем перемещать палец по экрану – этот текст будет постоянно меняться.
В случае ACTION_UP или ACTION_CANCEL пишем в sUp координаты точки, в которой отпустили палец.
Все это в конце события выводим в TextView. И возвращаем true – мы сами обработали событие.
Теперь мы будем водить пальцем по экрану (курсором по эмулятору) в приложении, и на экране увидим координаты начала движения, текущие координаты и координаты окончания движения.
Все сохраним и запустим приложение.
Ставим палец (курсор) на экран
Если вчерашний вечер не удался, голова не болит, рука тверда и не дрожит :), то появились координаты нажатия.
Если же рука дрогнула, то появится еще и координаты перемещения.
Продолжаем перемещать палец и видим, как меняются координаты Move.
Теперь отрываем палец от экрана и видим координаты точки, в которой это произошло
В целом все несложно. При мультитаче процесс немного усложнится, там уже будем отслеживать до 10 касаний.
Если вы уже знакомы с техникой рисования в Android, то вполне можете создать приложение выводящее на экран геометрическую фигуру, которую можно пальцем перемещать. Простейший пример реализации можно посмотреть тут: http://forum.startandroid.ru/viewtopic.php?f=28&t=535.
На следующем уроке:
— обрабатываем множественные касания
Присоединяйтесь к нам в Telegram:
— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.
— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование
— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня
— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме
Источник
26 сентября 2016 г. Овладение жестами в Android
Что же происходит в системе, когда пользователь касается экрана? И самое главное — как с этим обращаться? Пора разобраться с этим раз и навсегда. Вашему вниманию представляется заметка об обретенном понимании и опыте использования Android Touch System.
1. Внешность обманчива
Недавно передо мной встала задача разработать FrescoImageViewer — библиотеку для просмотра фотографий, загружаемых при помощи Fresco. Помимо этого необходимо было реализовать «pinch to zoom», переключение посредством ViewPager , а так же некое подобие «swipe to dismiss» — возможность закрыть изображение вертикальным свайпом. Собрав вместе основные компоненты я столкнулся с основной проблемой — конфликтом жестов.
Поскольку у меня был довольно скромный опыт в этой сфере, то первое решение, которое пришло мне в голову было таким: анализировать события в onTouchEvent() внутри моего CustomView и в нужный момент передавать управление. Но на деле поведение оказалось не таким очевидным, как я того ожидал.
В документации указано, что onTouchEvent() должен возвращать true, если событие было обработано, и false в противном случае. Однако, по каким-то причинам, там не указано, что если вернуть true, а потом изменить значение обратно на false — поведение не изменится до окончания жеста. Т.е. сообщив системе из onTouchEvent() , что элемент заинтересован в происходящем — это решение неизменно. Именно этот нюанс заставил меня потрепать себе нервы, а после открыть Google и погрузиться в изучение, как оказалось, целого фреймворка управления жестами.
2. Что же под капотом?
Итак, для понимания происходящего, предлагаю шаг за шагом разобрать, что происходит внутри этого нехитрого механизма на примере Activity с ViewGroup и дочерним View внутри, на который мы только что опустили палец:
- Событие ввода оборачивается системой в объект MotionEvent , в котором находится вся полезная информация (тип действия, текущие и предыдущие координаты касания, время события, количество пальцев на экране и их порядок и т. д.).
- Сформированный объект попадает в Activity.dispatchTouchEvent() (который всегда вызывается первым). Если активность не возвращает true (не заинтересована в обработке события на своем уровне), то событие отправляется корневому View .
- Корневой элемент вызывает dispatchTouchEvent() у всех причастных дочерних элементов в обратном порядке их добавления. А те, в свою очередь, делают то же со своими дочерними элементами, таким образом «пропуская» событие вниз по вложенности до тех пор, пока на него кто-то не отреагирует (вернет true).*
- Дойдя до dispatchTouchEvent() самого нижнего View , цепочка идет в обратную сторону путем метода onTouchEvent() , который так же возвращает результат своей заинтересованности.
- Если же никто не заинтересован — событие вернется в Activity.onTouchView() .
Так же во ViewGroup и View перед вызовом onTouchEvent() проверяется наличие OnTouchListener. Если он был задан — вызовется OnTouchListener.onTouch() , в противном же случае — onTouchEvent() .
*Здесь есть одна оговорка — у ViewGroup после dispatchTouchEvent() дополнительно вызывается onInterceptTouchEvent() , давая возможность перехватить событие, не оповещая вложенные элементы, тем самым изменив поведение ViewGroup на идентичное View :
- Если при перехвате жеста ViewGroup сообщит о своей заинтересованности — все дочерние элементы получат ACTION_CANCEL .
- В случае, когда внутри View нужно избежать перехватывания родительским контейнером и его предками, необходимо вызвать requestDisallowInterceptTouchEvent(true) у ViewGroup .
3. Системные детекторы жестов и касаний
Благо, при работе с жестами не нужно изобретать велосипеды и обрабатывать все вручную. Во многом помогает зашитый в SDK GestureDetector . Он включает в себя интерфейсы OnGestureListener , OnDoubleTapListener и OnContextClickListener для уведомлений о произошедшем событии и его типе. Вот как они выглядят:
Как видно из названий методов, с помощью GestureDetector мы можем распознать singleTap , doubleTap , longPress , scroll и fling (подробное описание каждого из методов можно найти в Javadoc или официальной документации Android).
Но этого мало! Есть еще ScaleGestureDetector и у него всего лишь один listener:
Он распознает жест «щепок» (или «pinch») и оповещает о его начале, конце и продолжительности. Кроме слушателя присутствуют вспомогательные методы для получения всей необходимой информации (см. документацию).
Со встроенными классами мы теперь знакомы, но как же их использовать? Да очень просто! Необходимо просто создать экземпляр нужного нам детектора:
. и передавать в него полученный MotionEvent. К примеру, в onTouchEvent() :
Готово! Все распознаваемые жесты будут попадать в переданный listener.
4. Свой детектор жестов
К сожалению, стандартными средствами мы можем узнать только о касании и о движении указателя ( MotionEvent.ACTION_DOWN и MotionEvent.ACTION_MOVE ), но иногда (хотя, мне кажется, намного чаще), при обработке жестов, необходимо знать их направление. В этом нам не в силах помочь даже стандартные детекторы, а потому придется написать собственный.
Назовем его SwipeDirectionDetector . Его задача единоразово оповестить слушателя о выявлении направления свайпа. Логика простая: запоминаем координаты события на ACTION_DOWN , а после измеряем длину до точки на ACTION_MOVE . Как только дистанция достаточная для определения направления — вычисляем угол и на его основании получаем направление.
Для начала определим метод onTouchEvent() , принимающий MotionEvent , и опишем в нем логику вычислений:
Объект Direction мы определим как enum и добавим туда методы get() для определения направления в зависимости от угла и inRange() для проверки его попадания в заданный диапазон.
Теперь дело за малым — создать экземпляр детектора и, как было показано в примере выше, передавать в него полученные MotionEvent :
5. Перехватывай и делегируй!
Теперь давайте рассмотрим простой кейс — custom view с ViewPager и контейнером для «swipe to dismiss» внутри. Если просто совместить компоненты — жест будет обрабатываться одновременно, что не есть хорошо с точки зрения UX.
Для решения проблемы необходимо переопределить dispatchTouchEvent() и в нем оповещать написанный нами детектор. Возвращать метод должен true, так как нам нужно перехватить управление на себя. Как только направление определено, мы можем передавать события нужному виджету и делать это нужно только посредством dispatchTouchEvent() .
Теперь конфликт жестов решен, а самое главное — чисто и красиво 🙂
6. Напоследок
Для большего понимания и примеров советую посмотреть исходный код упомянутой библиотеки. Надеюсь, что кому-то эта заметка даст больше понимания системы жестов и сэкономит драгоценное время и нервы 🙂
P. S. А вот отличнейшая лекция на английском языке от Дейва Смита (Dave Smith), с помощью которой мне удалось разобраться в этой непростой головоломке.
Нужен MVP, разработка под iOS, Android или прототип приложения? Ознакомьтесь с нашим портфолио и сделайте заказ уже сегодня!
Источник
Как использовать View.OnTouchListener вместо onClick
Я разрабатываю приложение для Android 2.2.2 для клиента и он хочет сделать следующее:
Теперь у меня есть кнопка с событием onClick, но ему не нравится, он хочет dectect, когда пользователь отпустит кнопку.
Я нашел вид.OnTouchListener который я думаю, что это то, что мне нужно использовать, но есть ли возможность добавить это событие в xml, как я сделал с onClick?
у меня есть еще два вопроса:
что событие, связанное с тем, когда пользователь отпускает палец?
есть ли какие-либо рекомендации, которые запрещают использование View.OnTouchListener вместо onClick ?
3 ответов
событие, когда пользователь отпускает палец — MotionEvent.ACTION_UP . Я не знаю, есть ли какие-либо рекомендации, которые запрещают использование View.OnTouchListener вместо onClick (), скорее всего, это зависит от ситуации.
вот пример кода:
предположительно, если кто-то хочет использовать OnTouchListener , а не OnClickListener , то дополнительная функциональность это. Это дополнительный ответ, чтобы показать более подробную информацию о том, как OnTouchListener можно использовать.
определить слушателя
поместите это где-нибудь в своей деятельности или фрагменте.
установить слушателя
установите слушателя в onCreate (для деятельности) или onCreateView (для a Фрагмент.)
Примечания
- getX и getY дайте вам координаты относительно вида (то есть левый верхний угол вида). Они будут отрицательными при движении выше или слева от вашего взгляда. Использовать getRawX и getRawY если вы хотите абсолютные экранные координаты.
- вы можете использовать x и y значения для определения таких вещей, как направление салфетки.
OnClick запускается, когда пользователь отпускает кнопку. Но если вы все еще хотите использовать TouchListener, вам нужно добавить его в код. Это просто:
Источник
Gestures and Touch Events
Gesture recognition and handling touch events is an important part of developing user interactions. Handling standard events such as clicks, long clicks, key presses, etc are very basic and handled in other guides. This guide is focused on handling other more specialized gestures such as:
- Swiping in a direction
- Double tapping for zooming
- Pinch to zoom in or out
- Dragging and dropping
- Effects while scrolling a list
You can see a visual guide of common gestures on the gestures design patterns guide. See the new Material Design information about the touch mechanics behind gestures too.
At the heart of all gestures is the onTouchListener and the onTouch method which has access to MotionEvent data. Every view has an onTouchListener which can be specified:
Each onTouch event has access to the MotionEvent which describe movements in terms of an action code and a set of axis values. The action code specifies the state change that occurred such as a pointer going down or up. The axis values describe the position and other movement properties:
- getAction() — Returns an integer constant such as MotionEvent.ACTION_DOWN , MotionEvent.ACTION_MOVE , and MotionEvent.ACTION_UP
- getX() — Returns the x coordinate of the touch event
- getY() — Returns the y coordinate of the touch event
Note that every touch event can be propagated through the entire affected view hierarchy. Not only can the touched view respond to the event but every layout that contains the view has an opportunity as well. Refer to the understanding touch events section for a detailed overview.
Note that getAction() normally includes information about both the action as well as the pointer index. In single-touch events, there is only one pointer (set to 0), so no bitmap mask is needed. In multiple touch events (i.e pinch open or pinch close), however, there are multiple fingers involved and a non-zero pointer index may be included when calling getAction() . As a result, there are other methods that should be used to determine the touch event:
- getActionMasked() — extract the action event without the pointer index
- getActionIndex() — extract the pointer index used
The events associated with other pointers usually start with MotionEvent.ACTION_POINTER such as MotionEvent.ACTION_POINTER_DOWN and MotionEvent.ACTION_POINTER_UP . The getPointerCount() on the MotionEvent can be used to determine how many pointers are active in this touch sequence.
Within an onTouch event, we can then use a GestureDetector to understand gestures based on a series of motion events. Gestures are often used for user interactions within an app. Let’s take a look at how to implement common gestures.
For easy gesture detection using a third-party library, check out the popular Sensey library which greatly simplifies the process of attaching multiple gestures to your views.
You can enable double tap events for any view within your activity using the OnDoubleTapListener. First, copy the code for OnDoubleTapListener into your application and then you can apply the listener with:
Now that view will be able to respond to a double tap event and you can handle the event accordingly.
Detecting finger swipes in a particular direction is best done using the built-in onFling event in the GestureDetector.OnGestureListener .
A helper class that makes handling swipes as easy as possible can be found in the OnSwipeTouchListener class. Copy the OnSwipeTouchListener class to your own application and then you can use the listener to manage the swipe events with:
With that code in place, swipe gestures should be easily manageable.
If you intend to implement pull-to-refresh capabilities in your RecyclerView, you can leverage the built-in SwipeRefreshLayout as described here. If you wish to handle your own swipe detection, you can use the new OnFlingListener as described in this section.
If you are interested in having a ListView that recognizes swipe gestures for each item, consider using the popular third-party library android-swipelistview which is a ListView replacement that supports swipe-eable items. Once setup, you can configure a layout that will appear when the item is swiped.
Check out the swipelistview project for more details but the general usage looks like:
and then define the individual list item layout with:
Now front will be displayed by default and if I swipe left on an item, then the back will be displayed for that item. This simplifies swipes for the common case of menus for a ListView.
Another more recent alternative is the AndroidSwipeLayout library which can be more flexible and is worth checking out as an alternative.
Supporting Pinch to Zoom in and out is fairly straightforward thanks to the ScaleGestureDetector class. Easiest way to manage pinch events is to subclass a view and manage the pinch event from within:
Using the ScaleGestureDetector makes managing this fairly straightforward.
One of the most common use cases for a pinch or pannable view is for an ImageView that displays a Photo which can be zoomed or panned around on screen similar to the Facebook client. To achieve the zooming image view, rather than developing this yourself, be sure to check out the PhotoView third-party library. Using the PhotoView just requires the XML:
and then in the Java:
Check out the PhotoView readme and sample for more details. You can also check the TouchImageView library which is a nice alternative.
Scrolling is a common gesture associated with lists of items within a ListView or RecyclerView . Often the scrolling is associated with the hiding of certain elements (toolbar) or the shrinking or morphing of elements such as a parallax header. If you are using a RecyclerView , check out the addOnScrollListener. With a ListView , we can use the setOnScrollListener instead.
With Android «M» and the release of the Design Support Library, the CoordinatorLayout was introduced which enables handling changes associated with the scrolling of a RecyclerView . Review the Handling Scrolls with CoordinatorLayout guide for a detailed breakdown of how to manage scrolls using this new layout to collapse the toolbar or hide and reveal header content.
Dragging and dropping views is not particularly difficult to do thanks to the OnDragListener built in since API 11. Unfortunately, to support gingerbread managing drag and drop becomes much more manual as you have to implement it using the onTouch handlers. With API 11 and above, you can leverage the built in drag handling.
First, we want to attach an onTouch handler on the views that are draggable which will start the drag by creating a DragShadow with the DragShadowBuilder which is then dragged around the Activity once startDrag is invoked on the view:
If we want to add «drag» or «drop» events, we should create a DragListener that is attached to a drop zone for the draggable object. We hook up the listener and manage the different dragging and dropping events for the zone:
Check out the vogella dragging tutorial or the javapapers dragging tutorial for a detailed look at handling dragging and dropping. Read the official drag and drop guide for a more detail overview.
Detecting when the device is shaked requires using the sensor data to determine movement. We can whip up a special listener which manages this shake recognition for us. First, copy the ShakeListener into your project. Now, we can implement ShakeListener.Callback in any activity:
Now we just have to implement the expected behavior for the shaking event in the two methods from the callback.
For additional multi-touch events such as «rotation» of fingers, finger movement events, etc., be sure to check out libraries such as Sensey and multitouch-gesture-detectors third-party library. Read the documentation for more details about how to handle multi-touch gestures. Also, for a more generic approach, read the official multitouch guide. See this blog post for more details about how multi-touch events work.
This section briefly summarizes touch propagation within the view hierarchy. There are three distinct touch related methods which will be outlined below:
| Order | Method | Invoked On | Description |
|---|---|---|---|
| 1st | dispatchTouchEvent | A, VG, V | Dispatch touch events to affected child views |
| 2nd | onInterceptTouchEvent | VG | Intercept touch events before passing to children |
| 3rd | onTouchEvent | VG, V | Handle the touch event and stop propogation |
«Order» above defines which of these methods gets invoked first when a touch is initiated. Note that above in «invoked on» A represents Activity , VG is ViewGroup , V is View describing where the method is invoked during a touch event.
Keep in mind that a gesture is simply a series of touch events as follows:
- DOWN. Begins with a single DOWN event when the user touches the screen
- MOVE. Zero or more MOVE events when the user moves the finger around
- UP. Ends with a single UP (or CANCEL) event when the user releases the screen
These touch events trigger a very particular set of method invocations on affected views. To further illustrate, assume a «View C» is contained within a «ViewGroup B» which is then contained within «ViewGroup A» such as:
Review this example carefully as all sections below will be referring to the example presented here.
When a touch DOWN event occurs on «View C» and the view has registered a touch listener, the following series of actions happens as the onTouchEvent is triggered on the view:
- The DOWN touch event is passed to «View C» onTouchEvent and the boolean result of TRUE or FALSE determines if the action is captured.
- Returning TRUE: If the «View C» onTouchEvent returns true then this view captures the gesture
- Because «View C» returns true and is handling the gesture, the event is not passed to «ViewGroup B»‘s nor «ViewGroup A»‘s onTouchEvent methods.
- Because View C says it’s handling the gesture, any additional events in this gesture will also be passed to «View C»‘s onTouchEvent method until the gesture ends with an UP touch event.
- Returning FALSE: If the «View C» onTouchEvent returns false then the gesture is propagated upwards
- The DOWN event is passed upward to «ViewGroup B» onTouchEvent method, and the boolean result determines if the event continues to propagate.
- If «ViewGroup B» doesn’t return true then the event is passed upward to «ViewGroup A» onTouchEvent
In addition to the onTouchEvent , there is also a separate onInterceptTouchEvent that exists only on ViewGroups such as layouts. Before the onTouchEvent is called on any View , all its ancestors are first given the chance to intercept this event. In other words, a containing layout can choose to steal the event from a touched view before the view even receives the event. With this added in, the series of events from above become:
- The DOWN event on «View C» is first passed to «ViewGroup A» onInterceptTouchEvent , which can return false or true depending on if it wants to intercept the touch.
- If false, the event is then passed to «ViewGroup B» onInterceptTouchEvent can also return false or true depending on if it wants to intercept the touch.
- Next the DOWN event is passed to «View C» onTouchEvent which can return true to handle the event.
- Additional touch events within the same gesture are still passed to A and B’s onInterceptTouchEvent before being called on «View C» onTouchEvent even if the ancestors chose not to previously intercept.
The takeaway here is that any viewgroup can choose to implement onInterceptTouchEvent and effectively decide to steal touch events from any of the child views. If the children choose not respond to the touch once received, then the touch event is propagated back upwards through the onTouchEvent of each of the containing ViewGroup as described in the previous section.
As the chart much earlier shows, all of this above behavior of touch and interception is being managed by «dispatchers» via the dispatchTouchEvent method invoked on each view. Revealing this behavior, as soon as a touch event occurs on top of «View C», the following dispatching occurs:
- The Activity.dispatchTouchEvent() is called for the current activity containing the view.
- If the activity chooses not to «consume» the event (and stop propagation), the event is passed to the «ViewGroup A» dispatchTouchEvent since A is the outermost viewgroup affected by the touch.
- «ViewGroup A» dispatchTouchEvent will trigger the «ViewGroup A» onInterceptTouchEvent first and if that method chooses not to intercept, the touch event is then sent to the «ViewGroup B» dispatchTouchEvent .
- In turn, the «ViewGroup B» dispatchTouchEvent will trigger the «ViewGroup B» onInterceptTouchEvent and if that method chooses not to intercept, the touch event is then sent to the «ViewGroup C» dispatchTouchEvent .
- «ViewGroup C» dispatchTouchEvent then invokes the «ViewGroup C» onTouchEvent .
To recap, the dispatchTouchEvent is called at every level of the way starting with the Activity . The dispatcher is responsible for identifying which methods to invoke next. On a ViewGroup , the dispatcher triggers the onInterceptTouchEvent , before triggering the dispatchTouchEvent on the next child in the view hierarchy.
The explanation above has been simplified and abridged for clarity. For additional reading on the touch propagation system, please review this detailed article as well as this doc on ViewGroup touch handling and this useful blog post.
Источник
