nicolas2k / google-glass-api

Automatically exported from code.google.com/p/google-glass-api
1 stars 0 forks source link

GestureDetector doesn't track TAP Gestures and gets LONG_PRESS instead when hosting a CardScrollView that had an item tapped #401

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Setup an immersion activity with a CardScrollView as per 
https://developers.google.com/glass/develop/gdk/ui/theme-widgets#creating_scroll
ing_cards_in_activities
2. Setup a GestureDetector and BaseListener as per 
https://developers.google.com/glass/develop/gdk/input/touch and 
https://developers.google.com/glass/develop/gdk/reference/com/google/android/gla
ss/touchpad/GestureDetector
3. Tap one of the items in the CardScrollView and notice how the 
GestureDetector.BaseListener's onGesture is invoked a second later with a 
LONG_PRESS gesture. It works fine with a TWO_TAP gesture (two finger one tap) 
and TWO_LONG_PRESS (two finger long press). The correct thing happens if you 
TAP+HOLD the view as expected. I tried performing a "cancelLongPress()" on both 
the CardScrollView and the actual Card view, but nothing helped.

What is the expected output? What do you see instead?
The activity-level GestureDetector.BaseListener should receive a TAP Gesture, 
even if I have set a OnItemClickListener on the CardScrollView. Only if I 
TAP+HOLD the CardScrollView should I get a LONG_PRESS. I should never get the 
LONG_PRESS Gesture if I single finger tap a view within the activity.

What version of the product are you using? On what operating system?
XE12

Please provide any additional information below.

Original issue reported on code.google.com by roberto.andrade on 8 Feb 2014 at 4:36

GoogleCodeExporter commented 8 years ago
Hello,

Could you share with us how you instantiate both the GestureDetector and the 
CardScrollView? When using both at the same time, you also need to make sure 
that gestures are bubbled up from the CardScrollView to the hosting Activity 
like so:

        mView = new CardScrollView(this) {
            @Override
            public final boolean dispatchGenericFocusedEvent(MotionEvent event) {
                if (mDetector.onMotionEvent(event)) {
                    return true;
                }
                return super.dispatchGenericFocusedEvent(event);
            }
        };

You can check the Timer sample for more information:
  https://github.com/googleglass/gdk-timer-sample/blob/master/src/com/google/android/glass/sample/timer/SelectValueActivity.java

Best,
Alain

Original comment by ala...@google.com on 10 Feb 2014 at 5:06

GoogleCodeExporter commented 8 years ago
The CardScrollerView is being inflated from a layout XML file, the
GestureDetector is exactly as the one from the samples.

Original comment by roberto.andrade on 10 Feb 2014 at 5:29

GoogleCodeExporter commented 8 years ago
Could you try instantiating the CardScrollView in the onCreate method instead 
of inflating an XML layout?

This would explain why the events are not passed to your main GestureDetector.

Original comment by ala...@google.com on 10 Feb 2014 at 5:33

GoogleCodeExporter commented 8 years ago
Well, the events are passed just fine, just the TAP even is not and
instead a LONG_PRESS is passed. That�s the issue.

On 2/10/14, 12:33 PM, "google-glass-api@googlecode.com"
<google-glass-api@googlecode.com> wrote:

Original comment by roberto.andrade on 10 Feb 2014 at 5:52

GoogleCodeExporter commented 8 years ago
I understood that in your first comment, my reply in comment #2 was that the 
TAP gesture is consumed by the CardScrollView and not bubbled up to your 
Activity or GestureDetector.

That is why you need to make sure to process such MotionEvent as shown in the 
code snippet and the Timer sample: TAP gestures are properly passed and 
processed in this sample.

Best,
Alain

Original comment by ala...@google.com on 10 Feb 2014 at 5:54

GoogleCodeExporter commented 8 years ago
Ok, I understood that :) my problem is I don�t want to handle the TAP, I
just don�t want the misplaced LONG_PRESS to bubble up. Wouldn�t that be a
fix in the CardScrollView itself?

On 2/10/14, 12:54 PM, "google-glass-api@googlecode.com"
<google-glass-api@googlecode.com> wrote:

Original comment by roberto.andrade on 10 Feb 2014 at 6:02

GoogleCodeExporter commented 8 years ago
Hello,

I used a modified version of the Timer to log events on the onGesture callback 
and successfully retrieved both TAP and LONG_PRESS events regardless of the 
events being processed.
I would suggest that you try instantiating the CardScrollView as mentioned in 
comment #2 as this would fix your issue.

Best,
Alain

Original comment by ala...@google.com on 10 Feb 2014 at 10:50

GoogleCodeExporter commented 8 years ago
I think you guys are missing the point here. Yes there�s a workaround, I
get that and I can work with that for right now, but the point of the
issue was to report it so you guys knew of the oddity and fixed it at the
CardScrollView level as you can�t possibly expect that to be the default
way in which people will instantiate this view and have to hack it this
way in order to avoid having to receive the INCORRECT event of LONG_PRESS
on the activity when you simply TAP a CardScrollView�s item, wouldn�t you
agree?

On 2/10/14, 5:50 PM, "google-glass-api@googlecode.com"
<google-glass-api@googlecode.com> wrote:

Original comment by roberto.andrade on 10 Feb 2014 at 10:52

GoogleCodeExporter commented 8 years ago
And to your point on comment #2, you're not only NOT bubbling up the event to 
the activity (because you're giving the activity the opportunity to handle the 
event BEFORE the view has a chance to do it, bubbling it up would mean letting 
the activity handle it AFTER the view had a chance to do it AND in case it DID 
NOT handle it itself).

Additionally, you're resorting to anonymous subclassing of the View just to be 
able to "correct" the issue with the workaround. The View should handle the 
TAP, which it does, not a problem and if it's not going to "bubble up" the TAP 
(which I'm fine with), it SHOULD NOT bubble up a LONG_PRESS given you released 
the TAP once the view handled it. Seems like a classic onTouchUp/Down return 
true/false for "handled" mistake to me.

Original comment by roberto.andrade on 10 Feb 2014 at 10:57

GoogleCodeExporter commented 8 years ago
Hello,

Please forgive me for not understanding your issue on the first post. I thought 
you were looking for a way to retrieve the TAP event from a CardScrollView 
which is the current way to do it.

Before I go make another misinterpretation, could you confirm that this new 
issue summary matches the report:
  Single `TAP` on a CardScrollView triggers a `LONG_PRESS` in a BaseGestureListener.onGesture callback

Thanks!
Alain

Original comment by ala...@google.com on 10 Feb 2014 at 11:28

GoogleCodeExporter commented 8 years ago
Sure, that's the main issue anyways. 

The fact the Activity-level GestureListener doesn't get the TAP event, even 
when I don't have a OnClickListener/OnItemClickListener set on the 
CardsScrollView could be overlooked as either another issue (to be filed 
separately) or a "by design" decision of the GDK team.

As a seasoned Android developer I'd expect the TAP to bubble up automatically 
without me having to resort to anything on the view (subclass, inflate 
differently) if the view is not "actually handling" the tap (given nothing 
happens by default on a CardScrollView if you tap on it, unless you set the 
appropriate Click Listener, which in turn would make is so the TAP gesture is 
consumed by the view and NOT bubble up to the activity).

But I'm fine treating this report as a simple fix for the LONG_PRESS issue, and 
we still wouldn't get the TAP even on the GestureListener callback unless we 
hack it the suggested way (:S). 

Original comment by roberto.andrade on 10 Feb 2014 at 11:41

GoogleCodeExporter commented 8 years ago
Let's use this issue to track both:
 * A LONG_PRESS should not be triggered when the user taps on a CardScrollView.
 * A TAP should be triggered there are no onItemClickListener.

Original comment by ala...@google.com on 10 Feb 2014 at 11:47

GoogleCodeExporter commented 8 years ago
Much appreciated. Sorry for the back and forth.

Original comment by roberto.andrade on 10 Feb 2014 at 11:51