This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
Encapsulate gesture and tracking mode behaviour #6557
Projects
Milestone
Comments
tobrun
pushed a commit
that referenced
this issue
Oct 5, 2016
with touch gestures. This fixes issues #6549 and #6567. Also pertinent to #6557. Additional code has been added to the test app (Activity "User Tracking Mode") to test. A potential race condition in the MapboxMap#easeCamera() methods where a camera change generated by tracking which could have reset the tracking modes has been eliminated by factoring out a new method MapboxMap#easeCameraInternal().
|
Happened with #7189 |
|
additional implementation notes here is that we now have an Interface that is responsible for changing the focal point -> FocalPointChangeListener. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
tldr: Current system around gestures and tracking modes introduces state management in the code (ie. if-else checks). Let's refactor this out.
Gestures
The Android SDK contains zoom, scroll, rotate and tilt gestures. These items can be enabled/disabled by users through xml and code and introduce a first layer of state management.
Tracking settings
Tracking settings allow the user to track location/heading. Users can configure tracking settings that impacts certain gestures (eg. setting bearing gps, disables rotate gesture). On top of that we also allow to hook into gesture code that results in disabling tracking modes.
Proposal
We have a complex system around gestures and tracking modes. It now introduces boilerplate and is a source of bugs (ref. #6549). Proposal is to look into refactoring this out into a design pattern and make it more testable.
The text was updated successfully, but these errors were encountered: