Future of plugins repository

[fynngodau]

I had been discussing with @louwers also re. maplibre/maplibre-native#1151 (comment) how to structure the Android-specific code.

I notice that there is currently some deprecated annotations code in maplibre native, and a non-deprecated (but highly confusingly essentially duplicate) implementation here in the plugins. Most of the maplibre plugins are currently also unmaintained.

It can also be confusing for developers that there's two separate sample apps (one for maplibre-plugins-android and one for maplibre-native android).

For these reasons we think that the current situation is rather messy and should be cleaned up. One possibility would be to move the plugins into maplibre-native.

Possible benefits (if done correctly):

• remove deprecated code and replace it with working one
• less confusing structure
• tighter integration has benefits regarding APIs for users (more sensical structure)

[fynngodau]

Let me elaborate what I mean with a "tighter integration": currently a user of the annotations plugin has to maintain one instance of AnnotationManager per type of annotation – see https://github.com/microg/GmsCore/blob/80780737726416d7924ba28a5c26acfa17fb1520/play-services-maps-core-mapbox/src/main/kotlin/org/microg/gms/maps/mapbox/GoogleMap.kt#L116-L131 for a real-world example. This is not something that users should be bothered with, it just adds to their boilerplate code. If there was a manager for each annotation managed inside the map object (e.g. a lazy kotlin object), this would reduce the amount of work that would need to be done to add a marker to the map. The other way seems very tedious.

[birkskyum]

Just to be clear - is it suggested here to move the annotations plugin (the ticket maplibre/maplibre-native#1154) or all the plugins (the mention above of "move the plugins") into Native?

[fynngodau]

@birkskyum I think it is up for discussion for which plugins this makes sense. For instance we would also want to integrate the marker view plugin (again¹).

¹ MapLibre has an InfoWindow implementation, made to imitate Google's info windows, that works similarly but not exactly the same. See also #28.

[birkskyum]

Okay - I think whatever we don't bring over now could easily end up in a dusty archive without the important annotations plugin to keep it just a bit alive. Probably best to bring over anything that could hold value, even it it might seem as "too much", so that this repo won't need to be resurrected down the line.

[louwers]

Just to be clear - is it suggested here to move the annotations plugin (the ticket maplibre/maplibre-native#1154) or all the plugins (the mention above of "move the plugins") into Native?

We will move Annotations first, which is arguably the most important, and then we look at the others.

My suggestion

Move to Core

Probably best to bring over anything that could hold value

MarkerView: Add map markers that are Android views.

Probably good to move over.

Scale bar: Provide a visual map scale bar for your users to determine distance.

Probably good to move over.

Maybe, but only if someone asks

Building: Add extruded "3D" buildings in your map style.

Probably we can get rid of this.

Offline: Download maps tiles and manage downloaded regions for situations when a user's device doesn't have an internet connection.

Already part of the core, but maybe this plugin offers some convenience?

Get rid of

Traffic: Adds a real-time traffic layer to any Mapbox base map.

Tied to proprietary API.

Location layer: [Deprecated] Add a location marker on your map indicating the user's location.

Already part of the Core SDK.

Places: Add location search to your app with beautiful UI.

Tied to Mapbox.

Localization: Have your map's text automatically match the device's default language setting.

Tied to Mapbox.

[avalanchas]

As a general question, do you have a clear outline of which things are confusing / duplicate / wrong with the other plugins? You have a very clear outline for annotations, but which of the other ones are actually troublesome? Which changes are needed and how would integrating benefit the plugins?

Now a little more specific: As you might have already seen I'm working on a fork of the download plugin to breathe some new life into it, I personally (without ever having had the big picture view or any trouble with the issues you describe above) think it stands quite well as an external plugin. It's quite clearly optional and easily distinguished from the core code. Also this made my getting into maintaining it super easy.

You write that the offline plugin is already part of the core? Well kinda, yes, it calls the OfflineRegion and OfflineManager classes, but it functions as a wrapper. How do you see the roadmap here?

[louwers]

@avalanchas Right now we only have a roadmap / plan for Annotations thanks to Fynn.

When it comes to the Offline plugin, we'd be happy to link to your fork from the Android README at maplibre/maplibre-native. Feel free to submit a PR.

[alexmercerind]

Hello,

I am using MapLibre's MarkerOptions, PolylineOptions. Both of which are marked as "Deprecated". My question is:

• What is the recommended API presently (with latest version)?
• What will be the recommended API (with upcoming version(s))?

https://maplibre.org/maplibre-native/docs/book/android/annotation-guide.html

What's the recommended approach to be future proof.

Thankyou.

[louwers]

@alexmercerind This Annotations plugin is not going anywhere and various users showed interest to keep it up to date. We're also not going to remove the Annotations functionality from the core in the upcoming release even though they are deprecated. So don't worry choosing either option.

The future is the to-be-implemented Kotlin API that @fynngodau is working on. Likely the internals of MapLibre Native will be overhauled at some point to support more flexible and performant annotations.