[android] - move camera logic to dedicated transform class

[tobrun]

WIP - closes #6532 - This PR moves camera logic to a dedicated java class.

Todo

• remove/decouple Mapbox/MapView dependencies from class
• call into NativeMapView directly
• fixup camera invalidation logic from onCameraChange calls during camera animation (by touch) #4746

After this we can look into integrating #4746

Review @ivovandongen.

[mention-bot]

@tobrun, thanks for your PR! By analyzing the history of the files in this pull request, we identified @clydebarrow, @cammace and @vkurchatkin to be potential reviewers.

[ivovandongen]

Looks great. Only some JavaDoc on the new class/methods

[tobrun]

Been looking into remove/decouple Mapbox/MapView dependencies from class while the class members were removed, I will not be able to exclude MapboxMap in total. Primary reason behind this is the usage of CameraUpdateFactory. This class takes in a MapboxMap and uses the following items from that class:

• CameraPosition
• UiSettings
• TrackingSettings
• Projection
• minZoom
• maxZoom

In a normal case, we would refactor those items into constructor and replace references. For this case, I'm thinking about just leaving MapboxMap and have these dependencies resolved from that object instead. The relation between CameraUpdateFactoy and MapboxMap is a bit too complex to extract and simplify.

[tobrun]

Side note: I had to remove the unit tests related to camera. This is because we aren't able to mock out NativeMapView in the newly introduced Transform class. I recently wrote instrumentation tests on our camera API #6803, these will cover both the old unit tested implementation as the core interaction behind it.

[tobrun]

2 more changes have been introduced:

• wrap camera update around a runnable, this is needed to be able to call an new CameraUpdate from a onFinish callback from another CameraUpdate. What currently occurs is that the second animation is started but is automatically canceled because the other animation wasn't fully finished.
• simplify the internal workings on transfrom: using 1 callback instead of 2, only one method for each nativecall.

[ivovandongen]

We probably should batch this so that we do only one invalidate per render instead of one per marker added

[tobrun]

Done with 07ae553

[sddamico]

@tobrun this breaks the existing contract that the new camera position will be query-able immediately and might have weird consequences in regards to "when this event occurs relative to activity lifecycle" because of the way the main thread works (lifecycle events are posted as items in the main thread handler).

Do you have a recommended strategy then for monitoring when this camera move event has been completed?