MGLMapView location/course tracking should be overrideable

[1ec5]

MGLMapView should publicly expose the methods it uses to track the user’s location or course and position the user dot or user puck. A subclass can override methods such as -didUpdateLocationWithUserTrackingAnimated: for its own needs.

A common use case for MGLMapView is to turn on course tracking mode and add a route line as a polyline annotation. Ideally, the user puck would snap to that line, sliding along it. MGLMapView could provide an API by which an application could designate a particular polyline annotation as the line to slide along. But there are other use cases that require fine-grained custom behavior, such as navigation simulation, so we should instead add open-ended customization hooks.

First, we should perform any necessary refactoring and cleanup of user tracking, because it’ll be very difficult to refactor this logic after it becomes part of the public API.

/ref #5645
/cc @bsudekum @boundsj @friedbunny

[1ec5]

The iOS navigation SDK is currently working around this issue by redeclaring CLLocationManagerDelegate conformance on a category of MGLMapView (mapbox/mapbox-navigation-ios#57) and suppressing the compiler warnings that result (mapbox/mapbox-navigation-ios#190).

[1ec5]

We should also expose -edgePaddingForFollowing and -edgePaddingForFollowingWithCourse publicly, or some variation on them that allows a subclasser to customize the user dot/puck’s location beyond the userLocationVerticalAlignment property’s simplistic options.

/cc @ericrwolfe

[1ec5]

The iOS navigation SDK is currently working around this issue by redeclaring CLLocationManagerDelegate conformance on a category of MGLMapView (mapbox/mapbox-navigation-ios#57) and suppressing the compiler warnings that result (mapbox/mapbox-navigation-ios#190).

The navigation SDK is completely moving off of this SDK’s user tracking implementation in mapbox/mapbox-navigation-ios#402. The refactoring proposed here would still be desirable for developers who aren’t using the navigation SDK but still need to swap in their own user tracking logic (whether to accommodate a custom location manager or to simulate user movement).

[1ec5]

The iOS navigation SDK is currently working around this issue by redeclaring CLLocationManagerDelegate conformance on a category of MGLMapView (mapbox/mapbox-navigation-ios#57) and suppressing the compiler warnings that result (mapbox/mapbox-navigation-ios#190).

By way of a belated update, the navigation SDK no longer uses the map SDK’s built-in course tracking. Instead, it implements its own course tracking feature using an overlaid view and custom camera logic: mapbox/mapbox-navigation-ios#402.

[1ec5]

#12203 proposes a delegate method as an alternative to the instance method proposed here.

[1ec5]

#12013 implemented a custom location manager API that technically addresses the use cases envisioned by the feature proposed here. Unfortunately, setting up a custom location manager can be more complicated than simply overriding -didUpdateLocationWithUserTrackingAnimated: or implementing a value transformer as proposed in #12280. But with the custom location manager API now in place, exposing -didUpdateLocationWithUserTrackingAnimated: may introduce too many ways to do the same thing.

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.