Introduction

The “enviroCar: Mapbox to MapLibre migration” project aims to add support for multiple map providers/libraries (primarily MapLibre) into the enviroCar Android application. This is done by introducing a new extensible and independent map module. This map module will allow the users to select the preferred map provider/library based on their requirements. It brings several benefits to the project, such as:

1. Risk Mitigation: Reduce dependency on a single provider, mitigating risks from policy changes or price hikes.
2. Customization: Users & developers can choose their preferred map provider.
3. Enhanced Coverage: Different providers may offer better coverage in specific areas.
4. Increased Reliability: Ensure continuous service by switching providers if one fails.

Different map providers/libraries also have different advantages & disadvantages.

You may read my earlier blog post for more details about the project. This mid-term blog post will provide an overview of the progress that has been made so far.

Project Goals

We set four major goals for this project, progress on each one is shared below:

1. Source-Code Maintenance

This goal had three sub tasks, all of which have been completed as part of different pull requests.

1. #1000: Updating the project dependencies, Android Target/Compile SDK, Gradle, Android Gradle Plugin etc. to their latest available versions.
2. #1001: Migrating the project to utilize Gradle Version Catalog. It is the recommended way of specifying dependencies in Android projects, which allows to specify dependencies and plugins in a scalable way. It makes dependency management easier for projects involving multiple modules (such as enviroCar).
3. #1002: Migrating to Jetpack View Binding from now deprecated Butter Knife. This is necessary in order to run the project on newer Android Studio and JDK versions.

2. Map Module Implementation

The map module has been introduced in #1003. Support for multiple underlying providers/libraries will be added into this module in the remaining coding period, including MapLibre. Currently, only Mapbox support is added.

The following code snippet provides an idea how the module can be used to display a map and interact with it.

The final implementation of the map module is slightly different from the one I initially anticipated. A few changes have been made to the API in order to fulfill the usage requirements inside the enviroCar application.  The following UML diagram provides a better idea.

There are multiple model classes in the module: Animation, Marker, Point, Polygon and Polyline, which improve the overall API. Annotations such as Marker, Point, Polygon and Polyline provide a builder interface, which allows one to easily set multiple attributes. I have also added a new CameraState API to listen to camera updates, e.g. change in position, bearing, tilt or zoom, etc.

Before starting to refactor the enviroCar application right away, I created a minimal example application to test various functionalities of the map module. The following video provides an idea about the same.

Location Indicator

Introduction

Another challenge has been to display live user location, which will be used in the recording screen of the enviroCar application. The current enviroCar Android application relies on an internal Mapbox SDK implementation, which updates the user location on the map. Because this technique is strongly coupled within the Mapbox SDK, it is necessary to find a more loosely coupled method for passing user location updates to the MapView.  As part of the project, we evaluated different approaches:

1. Use Google’s LocationManager.
2. Use Google’s new Fused Location Provider API.
3. Use dedicated provider/library specific location providers.

A comparison between the three approaches is provided below.

LocationManager	Fused Location Provider API	Provider specific location provider
Advantages Built-in Android API. Highly accurate and used by other options internally one way or another. Can be used in a provider independent manner to display live location using markers & polygons API in MapController. It is already used in the enviroCar application. Disadvantages May require more work since markers & polygons for displaying the location need to be drawn separately.	Advantages Battery efficient Disadvantages Available as a separate library. Depends upon Google Play Services. May require more work since markers & polygons for displaying the location need to be drawn separately.	Advantages Comes built-in with the map provider. Best viewing experience since it is optimized by the provider. Disadvantages May not be available on some providers e.g. OsmDroid. The behavior may be different on each provider.

We went ahead with the first option, since it allows us to display the live user location in a provider independent manner.

Implementation

A new class called LocationIndicator has been added. The LocationIndicator uses an existing provider/library independent API from the MapController interface, making it compatible with all of the underlying provider/library specific implementations for MapController and MapProvider.

The classes listed below are involved in displaying the location updates on the map view.

The LocationIndicator may be used to display the current location on the map. It internally creates an instance of LocationManager from Android to listen to the location updates from the device. It inherits from another class called BaseLocationIndicator, which can be used to display the supplied location on the map through the notifyLocation method. The LocationManager inside the LocationIndicator requests the location updates from the device, causing onLocationChanged callback to be invoked, which internally calls notifyLocation from BaseLocationIndicator to display the current location.

Inside the enviroCar application, it makes more sense to use BaseLocationIndicator directly, since location updates are already sent through the event bus and creating another LocationManager will be redundant.

3. Application Refactor and Update

There are primarily 3 types of views, which display a map view one way or another:

• Track list
• Track details
• Recording screen

The following is a comparison between two different styles used in the MapboxMapProvider.

mapbox://styles/mapbox/streets-v12	https://api.maptiler.com/maps/basic/style.json

The MapTiler style makes the map look identical to the original implementation (before the map module introduction).

I have migrated the track list and track details views to the new map module in the pull requests #1004 & #1005 respectively. In the next weeks, I will work on refactoring the recording screen, which then will also make use of the new location update approach.

4. Testing

This is the final goal of this project, which is to maintain a stable experience for the users by doing proper testing of the implemented features. We also want to make sure that the look and feel of the new map module relates to the old Mapbox specific mapping functionality.

Next Steps

We have made significant progress on the project so far. With that being said, following tasks remain:

• Refactoring the recording screen views in the enviroCar application to use the map module.
• Adding support for MapLibre and other providers into the map module.
• Adding option in the enviroCar application to select the map provider/library on deployment time and on runtime.
• Documenting the map module e.g. implementation, configurations and usage etc.

It is now the midpoint of the Google Summer of Code journey and I look forward to completing the above tasks in the remaining coding period.