Fix camera method and address deprecations

[naftalibeder]

Description

Fixes camera bounds-with-padding bug in v11 described in mapbox/mapbox-maps-ios#2134.

Checklist

• I've read CONTRIBUTING.md
• I updated the doc/other generated code with running yarn generate in the root folder
• I have tested the new feature on /example app.
  • In V11 mode/ios
  • In New Architecture mode/ios
  • In V11 mode/android
  • In New Architecture mode/android
• I added/updated a sample - if a new feature was implemented (/example)

[naftalibeder]

@mfazekas What would be required to get this merged?

[mfazekas]

I'm not sure about this on remove. Maybe just mapView?.viewport

[naftalibeder]

I don't understand the comment exactly - mapView doesn't need optional chaining if acquired in the withMapView callback. What's the concern?

[mfazekas]

First it should be map.withMapView { } we're in remove so we have a RNMBXMapView we're removing from, passed in as argument .

Second if mapView of RNMBXMapView is null then what was the satusObserver was attached to? Why do we need to remove?

So I think withMapView is unnecessary in this case. Likely not harmful but you have the check carefully as it could easily keep the camera object alive, until we'll have a mapView. Which doesn't sound right, but probably no leak here.

[naftalibeder]

I don't have a strong sense of the implications of the callback architecture (_mapCallbacks.append(callback), etc.).

We can do

map._mapView.viewport.removeStatusObserver(self)

but since _mapView is force-unwrapped, I'm not sure if it could be nil when acquired that way. It'd be the only place in the camera module where map.mapView is referenced that way. Do you prefer the map._mapView syntax?