-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[iOS] desynchro on user annotation #7910
Comments
One way would to allow tap recognizer to handle the tap if the tracking mode is not none and state is began. This way, the map knows the user stopped the map from scrolling then fall back to tracking state none. |
I fall in a problem: a touch is detected, the map engine stop the movement and the fly camera completion is called before the tap gesture recognizer is fired. So the fly camera completion does not inform us if the animation completed or has been interrupted by user tap... |
the completion handler of the MGLMapView.mm method _flyToCamera:::: should have a boolean parameter indicating if the animation fully finish or has been interrupted by the _mbglMap->cancelTransitions() call (from touchBegan:). |
I succeeded into getting a correct behavior here by adding simples lines before `- (void)touchesBegan:(__unused NS_SET_OF(UITouch *) *)touches withEvent:(__unused UIEvent *)event }` I'm not sure if you like it. |
Related to #4781. |
Another one may be to ignore user interaction until animation is complete. |
I disagree, a user must be able to stop a map scrolling by a tap.
Romain
… Le 7 févr. 2017 à 14:35, Eimantas ***@***.***> a écrit :
Another one may be to ignore user interaction until animation is complete.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#7910 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHzNfUDIJ_eOVSal7fe7fqzfDiQqCkE2ks5raHMugaJpZM4LyyUk>.
|
Fixed in #7916 |
Platform: iOS 9, 10
**Mapbox SDK version: 3.4.1 **
Steps to trigger behavior
Expected behavior
The map should starts to fly to your location. The tap on screen stops the map and the user location is not visible (as it is far from the bounding box)
Actual behavior
The map starts to fly to the user location. The tap on screen stops the map but the user location is shown on the middle of the map where it should not be. It stays there as long a new location is received.
The bug comes from the user location considered as centered from the start of the action but it is not yet centered before the end of animation.
I don't know yet how to correct that.
The text was updated successfully, but these errors were encountered: