[Camera Animations] Introduce short-lived camera view

[nishant-karajgikar]

PRs must be submitted under the terms of our Contributor License Agreement CLA.

Pull request checklist:

• Briefly describe the changes in this PR.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality. If tests were not written, please explain why.
• Add example if relevant.
• Document any changes to public APIs.
• Apply changelog label ('breaking change', 'bug 🪲', 'build', 'docs', 'feature 🍏', 'performance ⚡', 'testing 💯') or use the label 'skip changelog'
• Add an entry inside this element for inclusion in the mapbox-maps-ios changelog: <changelog></changelog>.
• Update the migration guide, API Docs, Markdown files - Readme, Developing, etc

Summary of changes

CameraView

• The role of the CameraView has been significantly curtailed with this PR.
• The CameraView will only exist (i.e. be part of the view hierarchy) for the duration of an animated transition.
• All business logic has been pulled out of the cameraView.

CameraManager

• The makeCameraAnimator* methods have been updated to accept CameraAnimations as required arguments.
• The makeCameraAnimator* methods have been renamed to makeAnimator* methods

CameraTransition (new)

• The CameraTransition is a new construct that allows better control on the "from" and "to" values of a camera animation
• An instance of this type is passed into each animation block and is designed to be mutated by the developer.
• The mutated value is then used to construct the interpolation

FlyToCameraAnimator (new)

• flyTo has been re-implemented to rely solely on the FlyToInterpolator. There is no interaction with keyframe animations any more.

BasicCameraAnimator (renamed from CameraAnimator)

• Apart from a rename, this construct now represents a singular transition.

CameraAnimator (new)

• Both FlyToCameraAnimator and BasicCameraAnimator conform to CameraAnimator
• The protocol is designed as a way for SDK consumers to interrupt animations and check on the state of those animations.

CameraAnimatorInterface(new)

• Internal facing protocol that both FlyToCameraAnimator and BasicCameraAnimator conform to
• Used to update the camera on each tick of the display link

Gestures

• Gestures now directly call __map.setCamera() instead of going via CoreAnimation
• This results in a nice bump in gesture performance due to the greater frequency of touch events as opposed to screen refresh rate.

User Impact

1. The call site for camera animators now looks like:

   mapView.camera.makeAnimator(duration: 3, curve: .easeOut) { (transition) in 
       transition.center.toValue = CLLocationCoordinate2D(latitude: 10, longitude: 10)
       transition.zoom.toValue = 14
       transition.bearing.toValue = -35
   }

2. Animations can only be added to an animator at init-time. They must be passed into one of the makeAnimator* functions.

3. The addAnimation(_ animations: () -> Void, delayFactor: CGFloat) method has been removed in favor of constructor injecting animations.

Videos:

FlyTo

RPReplay_Final1618957459.MP4

Animations

RPReplay_Final1618957647.MP4

Animated Padding

padding.mov

[macdrevx]

My mistake 😬

[macdrevx]

I think we should consider splitting up the responsibilities of this protocol. Some of them could be fulfilled by injecting each animator with the MapboxMap. The rest (the ones that are UIView-related could be contained in a more focused protocol.

[nishant-karajgikar]

I agree with this. Could we perhaps do it as part of subsequent PR?

[nishant-karajgikar]

Ticketed : https://github.com/mapbox/mapbox-maps-ios-internal/issues/643