Closed Lonami closed 8 years ago
Can confirm. I tested this with the firefox widget
Even when onInterceptTouchEvent(MotionEvent ev)
(under LauncherAppWidgetHostView.java) returns always false
, the widget selection is still triggered. So we probably need to focus on the widget_area
FrameLayout
instead. Maybe intercept the touch events in a custom way as we did with the widget host view? But that is currently using the default setOnLongClickListener
, it should work well... Awkward.
What if we simply remove any click listeners from the widget_area
after a widget has been placed there?
That's probably a good option.
Try it. If it works make a PR
Will play with it ASAP 👍
It couldn't be that easy... Didn't work. I've added widget_area.setOnLongClickListener(null);
on placeWidget(AppWidgetHostView hostView)
here and it still fires. Even with a single tap. Isn't that supposed to prevent longClick from being fired?
The problem must be somewhere else.
This is the responsible. But it shouldn't be the case since it is not a longClick!
OK, ACTION_UP
events are not fired for a simple reason:
If you return false from
onTouch
method, no further events get delivered to the listener. You should return true at least in case ofevent.getAction()
==MotionEvent.ACTION_DOWN
.
From this question. Let's see if that does the trick.
Steps to recreate
Find a widget which doesn't take all the space in the widget area or one that doesn't take any action. Perform a tap somewhere not occupied by the widget.
What happens
The widget selection triggers.
Proof