search

avlsocialconnect / osmdroid

Automatically exported from code.google.com/p/osmdroid
0 stars 0 forks source link

r1129 'Fix for dispatchTouchEvent' breaks touches #387

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Regarding the:
http://code.google.com/p/osmdroid/source/detail?r=1129
r1129: Fix for dispatchTouchEvent - if child view handles motion event, don't 
pass to gesture detector.

This change makes the mapview to consume touch events at 
super.dispatchTouchEvent(event) and I cannot pan the map.

Original issue reported on code.google.com by devemu...@gmail.com on 13 Dec 2012 at 6:31

GoogleCodeExporter commented 9 years ago 
This change basically says:

If there is a child view of the MapView that handles touch events, don't pass 
them down to the MapView. For instance, if you add a popup window to the maps 
that has a scroll view and you slide your finger on that scroll view, don't 
also scroll the maps. I believe this is the proper behavior.

If you have a view on the maps that is preventing you from scrolling the maps, 
you need to configure your view to not accept touches. I believe 
view.setClickable(false) may do the trick.

Original comment by kurtzm...@gmail.com on 19 Dec 2012 at 2:32

GoogleCodeExporter commented 9 years ago 
I may be understand it wrong, but isn't super.dispatchTouchEvent(event) passes 
the touch events to the parent of the map view and not to the children?
And I don't have any children added on the map view. But I have the map view 
added in another ViewGroup (a RotateView) and the latest in an ViewAnimator.

Original comment by devemu...@gmail.com on 20 Dec 2012 at 9:29

GoogleCodeExporter commented 9 years ago 
From the API documentation: "Pass the touch screen motion event down to the 
target view, or this view if it is the target." And if you check the 
ViewGroup.java source it appears that it iterates through the children view and 
calls dispatch on each child. From the source comments: "We know we want to 
dispatch the event down, find a child who can handle it, start with the 
front-most child."

What I would do is set a breakpoint when super.dispatchTouchEvent is set to 
true (line 790) to see if that is getting hit. If so, step into the 
super.dispatchTouchEvent calls and see why that is returning true. If you have 
no child views then it should always return false.

Original comment by kurtzm...@gmail.com on 26 Dec 2012 at 8:13

GoogleCodeExporter commented 9 years ago 
What Android version is the ViewGroup.java source that you have the comment "We 
know we want to dispatch the event down, find a child who can handle it, start 
with the front-most child." ?
Because I google it to find it. At latest Jelly Bean source this comment 
doesn't exist and the dispatchTouchEvent method is different.

Original comment by devemu...@gmail.com on 27 Dec 2012 at 1:06

GoogleCodeExporter commented 9 years ago 
Yes, that comment was from an earlier API but the Jellybean version is 
basically the same (see comment "Find a child that can receive the event. Scan 
children from front to back.")

Maybe try to build the sample app with the trunk osmdroid and see if that works 
for you.

Original comment by kurtzm...@gmail.com on 28 Dec 2012 at 2:18

GoogleCodeExporter commented 9 years ago 
Well after the creation of the map view I have at my code:
mapView.setClickable(true);
as I also have with Google map view. This seems to have caused all the trouble 
with touch events consumption after dispatchTouchEvent change.
If I remove this statement the pan works again.

Original comment by devemu...@gmail.com on 28 Dec 2012 at 6:08

GoogleCodeExporter commented 9 years ago 
Okay, that makes sense - the dispatch tries all children views and then it 
tries the ViewGroup itself which is typically not a gesture target. The MapView 
uses a GestureDetector to handle gestures.

It sounds like this issue is resolved so I will close it.

Original comment by kurtzm...@gmail.com on 28 Dec 2012 at 7:40