mapViewDidFinishRenderingFrameFullyRendered not called in MLNMapView for iOS since 6.x.x update

[mindthefish]

Description
When interacting with the map using gestures like panning or flinging, the mapViewDidFinishRenderingFrameFullyRendered should be called in MLNMapView in order to adapt to the updated view. The NavigationMapView of maplibre-navigation-ios inherits from MLNMapView and overrides the function to update the puck position for certain cases. Since the 6.0.0 update, the function is not called, which causes massive problems with the behavior of the puck movement during active navigation.

To Reproduce

1. Run any iOS application with a MLNMapView
2. Add a breakpoint to the mapViewDidFinishRenderingFrameFullyRendered
3. pan or fling the map

Expected behavior
mapViewDidFinishRenderingFrameFullyRendered is called with each update caused by the gesture.

Actual behavior
mapViewDidFinishRenderingFrameFullyRendered is not called.

Screenrecording

puck.mp4

Platform information :

• OS: iOS 16.7.4 onwards
• Device: Simulator and physical

Additional context
The related issue for maplibre-navigation-ios: maplibre/maplibre-navigation-ios#27

[michaelkirk]

I think this was fixed in maplibre/maplibre-navigation-ios#53

The title of this issue might be misleading, because this was actually in the context of NavigationMapView in maplibre-navigation-ios which is a subclass of MLNMapView.

The method signature for MLNMapView.mapViewDidFinishRenderingFrameFullyRendered changed in
76469a0 and then again in
8ad5f9c

The reason this occurred without anyone noticing, is that this is a private method. maplibre-navigation-ios was only able to call it because we've copied in part of the private header. When the method signature change, our copied header became stale, and our "overridden" method was no longer being called.

An immediate fix would be to copy in an updated version of the private header like I did in maplibre/maplibre-navigation-ios#53

Longer term, I'm not really sure what the right solution is. I think this is a frequent point of tension trying to reconcile inheritance and delegation.

Some alternatives:

• We could make this method public and use the public header instead of the private one.
• We could utilize mapView.delegate in the NavigationMapView implementation. This seems tricky though, since we also want downstream users to be able to implement their own MLNMapViewDelegate for the NavigationMapView.

[louwers]

Thanks for the clarification. Private methods do not have a stable API of course.

Feel free to create a new issue or design proposal for the needed API changes.