Fitting the map to a set of supplied markers

The MapView component also makes it easy to focus the map on a set of markers and animate it smoothly to show the corresponding area of the map with every update, using its fitToSuppliedMarkers method.

Unfortunately though, the method doesn’t allow for any padding (unlike its fitToCoordinates counterpart) to make sure the markers don’t overlap with other elements on the screen.

Luckily, the community provides a solution that’s very easy to implement:

fitToSuppliedMarkersCustom(coordinates) {

const markers = [];

markers.push(this.vehicleCoordinates());

markers.push(coordinates); this.map.fitToCoordinates(markers, {

edgePadding: {

bottom: 200, right: 50, top: 150, left: 50,

},

animated: true,

});

}

All you have to do is store the markers’ reference using React’s ref attribute, push them to an array and use the fitToCoordinates method instead.

Update: I recently created a pull request on the react-native-maps repo that fixes this behaviour and allows you to pass the edgePadding object directly into fitToSuppliedMarkers . The PR has been approved and merged into master.

Testing our scrappy solution

As you can imagine, the first few attempts of properly syncing the API responses with the UI were pretty unsuccessful. That’s not a big deal when you use a testing environment and your requests don’t have any impact on the real world. Our case though was that every time we “tested” the API, we’d request a real vehicle.

What worked in our favour though was that the ride-sharing service provides a 30-second courtesy time of cancelling a ride, not the most ideal feature for drivers, but at least it would allow us to adjust and fine-tune our system, with the minor downside of sending drivers to random destinations all the time.

I actually ended up in the car of a driver who complained about our request/cancel approach of bulletproofing their service’s API. But despite making some drivers really mad at us and even though we didn’t develop the most elegant solution (using polling, testing in production, relying on cron jobs), it actually works solidly now, and we managed to bootstrap our way through limited resources and unexpected constraints to a production-ready app.