One of the main features FieldIn provides to its customers is the ability to report pests, disease and other points of interests on a map. In addition, we allow our users to set traps and manage them in the field – pests traps are a method for monitoring your field pest damage and an average field can contain hundreds of traps.
One of the key features of the Scouting app is the ability to show multiple points of interest over a map – I.E, polygons shapes, hot locations, vehicle tracking and much much more.
Our challenge began with the need to provide our App users with Google Maps Imagery (as they are the most updated and reasonably priced maps out there) while still getting good performance when showing huge amounts of data on the map. In addition we had to keep it consistent with the maps shown in our web platform.
We went out and explored Google SDK and Mapbox which are the top map libraries providers – obviously as we are using RN, we looked into RN options.
Mapbox Maps SDK for RN, “unofficial React Native library for building maps with the Mapbox Maps SDK for iOS and Mapbox Maps SDK for Android”.
This library by default works with Mapbox maps. It is super fast, very easy to use and with a built in clustering feature.
Clustering is highly important when displaying multiple points/shapes on the map. It reduces the number of rendered objects significantly based on the zoom level, which is a boost in the performance and provides a better UX – I.E 1k traps points could be rendered as just a few clustered points, and the clusters spread out as the users zoom in to give more accurate locations.
“The actual map implementation depends on the platform. On Android, one has to use Google Maps, which in turn requires you to obtain an API key for the Android SDK. And On iOS, one can choose between Google Maps or the native Apple Maps implementation”.
Another quick side note – we excluded react-native-webview-leaflet (another RN Maps library), since it is still a lot less maintained (at least for now)
We Tested the two libraries on many IOS and Android devices focusing on the following main key points, and this is what we discovered.
#Map images Quality:
Google Maps is the obvious better option when it comes to Map images qualities, when comparing it with Mapbox maps, especially in the non urban areas such as farm fields – our customers main interest. In that regard, Since react-native-maps use Google Maps SDK it is the better option .
While testing performance we took into consideration the need to load a lot of polygons, polylines and especially markings on the map (traps). we found out that both libraries did not perform well when passing the 1k unclustered markers and about the same number of shapes. But @react-native-mapbox-gl/maps was quite a lot better than react-native-maps. It simply performed smoother and faster rendering while react-native-maps was clunky and took a lot more time to load.
React-native-maps is by far the most used and most maintained RN map library, with more than 80k npm weekly downloads. Compared to @react-native-mapbox-gl/maps which have about 6k npm weekly downloads. But the RN community is highly active in both of these libraries .
@react-native-mapbox-gl/maps has a built-in clustering feature while it is still a feature in request in react-native-maps, although there are already external libraries that implement this feature. Clustering holds a huge importance when it comes to performance.
In a high zoom level a 1k points could be reduced to just a few, and it breaks to more points and the user zooms in to show the accurate points location.
This boils down to Performance vs Map Imagery Quality. Choosing mapbox will give us a better performance but without Google maps, and choosing react-native-maps will give us Google maps at the cost of a clunky performance, also we would have to write our own clustering feature.
Before we continue I would like to make it clear that both of these libraries are still the best options out there, and for many cases it would be sufficient to just use either as is. Moreover I didn’t discuss the many other features of the two libraries since we weren’t using them, and my main focus in performance was testing it under tons of markers ,shapes and polylines – traps.
Unfortunately, we could not find a solution that satisfies all of our demands. We are currently looking into an option to combine both worlds, very similar to our web solution. We will definitely write another post about it when we will have all the details.