Closed GoogleCodeExporter closed 9 years ago
Sorry, this is not a defect but an enhancement, I hope.
Cheers,
Thomas
Original comment by thomas.f...@gmail.com
on 21 Mar 2010 at 6:35
This looks like a nice enhancement, but it requires SDK 2.0. I'm reluctant to
up the
requirements for osmdroid at this time.
Coincidentally I was just looking at how to factor out the zoom controls so
that the
dependency for OpenStreetMapView can be reduced to 1.5.
You could easily write a new class which extends OpenStreetMapView to add this
extra
bit of functionality, and at some point in the future when osmdroid is updated
to 2.0
this can be merged in.
I made such a class and attached it. Anyone can use this in a project that is
dependent on 2.0.
Original comment by neilboyd
on 23 Mar 2010 at 3:46
Attachments:
Definitely the refactoring into a different class is the better solution.
I'll try to find out a way for coexistence of the new functions within the old
SDK.
Anyone a better idea than reflection?
Original comment by thomas.f...@gmail.com
on 25 Mar 2010 at 9:26
I tried to introduce the multi touch mode, facing the problem of too many
locations
where new OpenStreetMapView is created using different constructors. It can be
done,
but it does not really make the code nicer...
The solution would be to introduce a factory, creating a view depending of the
version. This looks a little bit overengineered for this tiny piece of code.
A possible solution, which could be acceptable, is to integrate the stuff like
in the
first version and always build with the latest SDK.
Then, check Build.Version
http://developer.android.com/reference/android/os/Build.VERSION.html#SDK_INT
against the version code
http://developer.android.com/reference/android/os/Build.VERSION_CODES.html
and do not enter the code where the later method unavailable on the current
version
could be used. The overhead should be small.
By looking for the Build.VERSION in the code, you can easily trace the parts,
which
are version dependend.
IMHO this would make enhancements easier without the necessity use a split code
base.
What do you think about this solution?
Cheers,
Thomas
Original comment by thomas.f...@gmail.com
on 5 Apr 2010 at 9:47
It's also discussed here:
http://android-developers.blogspot.com/2009/04/backward-compatibility-for-androi
d.html
As I have multitouch backported in cyanogen-mod for my G1, but the SDK version
is
still at Android 1.6, I'd prefer reflection ;)
Original comment by ThyMythos@googlemail.com
on 17 Apr 2010 at 10:46
Easiest is to check
http://developer.android.com/reference/android/os/Build.VERSION_CODES.html, but
more
general under any circumstances is to test the existence of the required
function by
reflection.
My current problem is, that the I have to replace the new
OpenStreetMapView(...) by
new MultiTouchOpenStreetMapView(...) everwhere in the code, which does not make
the
code nicer than without inheritance.
So I would need a factory method or some of the other sucking OO crutches. The
easiest seems to be to put the decision back into
OpenStreetMapView.onTouchEvent...
If this view is accepted in general, I would test with reflecton like the link
above
on the existence of MotionEvent.getX(0) which is a perfect indication of access
to
the multitouch api.
Original comment by thomas.f...@gmail.com
on 18 Apr 2010 at 8:36
Original comment by neilboyd
on 22 Apr 2010 at 7:09
I've done the reflection change in revision 143.
I've tested it on my 1.6 G1 and it works in the sense that it doesn't work ;-)
Runs okay on a 2.0.1 emulator but I don't know how to do multi-touch events on
the
emulator.
Please can the people who commented on this issue test it on their 2.0+ devices.
Original comment by neilboyd
on 22 Apr 2010 at 8:13
No comments from the other people :-(
But I just received my free Nexus One from Google :-)
How is this fix supposed to work? Multi-touch is new to me. I tried what I
understand
by pinch-to-zoom but nothing happened. Probably I understood it wrong.
Original comment by neilboyd
on 3 May 2010 at 8:00
Cool. I did not recognize the ironic remark in comment 8 ;-)
Than we have aligned all versions in a common code base and I can drop my extra
changes.
Thanks a lot!
Original comment by thomas.f...@gmail.com
on 3 May 2010 at 4:01
I fixed the reflection invoke in revision 160, but it still doesn't work.
The events I get when spreading are:
ACTION_DOWN
ACTION_POINTER_2_DOWN
a whole load of ACTION_MOVE
ACTION_POINTER_2_UP
ACTION_UP
This doesn't match what the code handles.
Original comment by neilboyd
on 4 May 2010 at 7:37
I will try it in the next days.
Original comment by thomas.f...@gmail.com
on 4 May 2010 at 8:05
Any news on this? If it's not working then I'll remove this code.
The code seems to be trying to do a constant zoom. Shouldn't it only do the
zoom on
mouse up?
Original comment by neilboyd
on 21 May 2010 at 8:25
I'll have a look soon. I am very busy in two customer projects.
Sorry for the delay...
Thomas
Original comment by thomas.f...@gmail.com
on 21 May 2010 at 8:32
I also created issue 58. It's not directly related to this issue, but this one
demonstrates it.
Original comment by neilboyd
on 2 Jun 2010 at 7:29
[deleted comment]
There's some activity in AndNav2 regarding this:
http://groups.google.com/group/andnav/browse_thread/thread/5360a830b22d70ef/
Actually I think our implementation is better, and I think it works okay as it
is now.
Please could someone confirm.
I also raised issue 59. An extra enhancement.
Original comment by neilboyd
on 2 Jun 2010 at 8:31
Here's an interesting article:
http://android-developers.blogspot.com/2010/06/making-sense-of-multitouch.html
In Android 2.2 they've added android.view.ScaleGestureDetector which handles
the pinch.
Original comment by neilboyd
on 10 Jun 2010 at 9:26
Hi,
I've just added MultiTouch support for OpenSatNav (that use osmdroid).
I use an external class, more info and a test version here:
https://bugs.launchpad.net/opensatnav/+bug/579388
If you're interested I could make you a patch for OpenStreetMapView.java :)
I've tested on many real devices from 1.6 to 2.2, and also Emulator 1.5.
Original comment by Murphy2...@gmail.com
on 21 Jun 2010 at 10:32
I'd be very interested in a patch :-)
Otherwise I can try and figure it out for myself.
The source doesn't seem to be in the OSN repository yet.
Original comment by neilboyd
on 22 Jun 2010 at 9:52
I don't find
OpenStreetMapViewer/src/org/andnav/osm/views/OpenStreetMapView.java, should I
use osmdroid-android/src/org/andnav/osm/views/OpenStreetMapView.java ?
Original comment by Murphy2...@gmail.com
on 22 Jun 2010 at 10:50
Yes.
Original comment by neilboyd
on 22 Jun 2010 at 11:27
I added my MT class in OpenStreetMapView but there's many differences with the
version I use in OpenSatNav so it's quite complicated to have the same behavior.
Here's my files:
- my OpenStreetMapView file from OpenSatNav,
- the MultitouchController class I used for both projects,
- the OpenStreetMapView file (OpenStreetMapView-MT) I customized for
osmdroid-android.
Original comment by Murphy2...@gmail.com
on 23 Jun 2010 at 8:05
Attachments:
Thank you very much for that. I've included it as revision 238.
I also tidied up a bit in revision 239.
Original comment by neilboyd
on 23 Jun 2010 at 9:13
I notice you also commented out the call to onTouchEvent on the overlays? Was
that deliberate?
Original comment by neilboyd
on 23 Jun 2010 at 9:20
No, but this code was still a work in progress!
Sorry I wasn't clear about that.
Are you happy with it?
I didn't find how to block the spanning while using MT (it's quite strange in
that case).
Original comment by Murphy2...@gmail.com
on 23 Jun 2010 at 9:31
Okay, I've put back the call to overlays onTouchEvent.
The previous version was also a work in progress ;-)
It works for me on my Nexus One :-) I'll try it later on my G1.
What do you mean by spanning? Do you mean the way the map moves when you're
trying to zoom?
I'm not sure if the order of the calls to onTouchEvent is correct. Why did you
nest the call to mGestureDetector.onTouchEvent inside the if
mMultiTouchController.onTouchEvent? Why not just call one after the other,
including the overlays?
Original comment by neilboyd
on 23 Jun 2010 at 10:11
"Do you mean the way the map moves when you're trying to zoom?"
Yes, this causes strange movements while zooming.
"Why did you nest the call to mGestureDetector.onTouchEvent inside the if
mMultiTouchController.onTouchEvent?"
I tried to block the map moving (mGestureDetector) when using multitouch.
Original comment by Murphy2...@gmail.com
on 23 Jun 2010 at 10:25
I guess we need to get rid of mGestureDetector and handle everything in
setPositionAndScale.
The multitouch demo looks so simple ;-)
Original comment by neilboyd
on 23 Jun 2010 at 12:10
In OpenSatNav I couldn't handle well a simple map move using
setPositionAndScale, so I let the MotionEvent.ACTION_DOWN and
MotionEvent.ACTION_UP in onTouchEvent, but I need to simplify this.
Original comment by Murphy2...@gmail.com
on 23 Jun 2010 at 12:30
Revision 243 lets multi-touch controller handle only multi-touch events, and
gesture detector handle single-touch events. Seems to work.
Original comment by neilboyd
on 23 Jun 2010 at 1:22
Good job!
Original comment by Murphy2...@gmail.com
on 23 Jun 2010 at 2:32
By the way, it could be nice to be able to disable it if the user of
osmdroid.jar wants to.
I couldn't see a reason for that before I played "Parallel Kingdom" on Android:
they use Google Map as a map terrain and have disabled zoom buttons... but on a
recent GMaps update multitouch was on and it was like an easter egg to see all
the world :)
Original comment by Murphy2...@gmail.com
on 23 Jun 2010 at 2:59
Yes, I already made issue 59 for that.
Original comment by neilboyd
on 23 Jun 2010 at 7:26
This issue was closed by revision r278.
Original comment by neilboyd
on 5 Jul 2010 at 11:21
When I zoom using two fingers in and out, specially inside fragments, the whole
map image moves up before it starts zooming, making the user experience really
awkward.
Original comment by hju...@gmail.com
on 6 Aug 2012 at 2:00
Original issue reported on code.google.com by
thomas.f...@gmail.com
on 21 Mar 2010 at 6:35Attachments: