Widget system

[tobrun]

On Android we have a couple of overlain widgets on a map:

• Compass
• Logo
• Attribution
• Scale (proposal PR in [android] Added dynamic scale widget to map view. #6555)
• MyLocationView (-> more ViewMarker?)

We currently expose restricted API to configure these: eg.

• setEnabled (hides/shows)
• setMargins
• setGravity

Some of these widgets are static, others need to hook into callbacks to update themselves (mapchange/surface-update events). We need to look into a system where a user can provide their own view implementation and subscribe to these update events. Users should be able query existing views and manipulate these.

Sidenote: it's currently possible for users to add views to the view hierarchy through MapVIew#addView and listen to mapchange events. They need to write some boilerplate to set this up. Users can also get a reference of current exposed widget views by using findViewById and thus bypassing our restricted API. Introducing a framework that gives our users more freedom that reflect the current capabilities seems like a great step here. Besides improving our API here, we can extract code from mapview and refactor it into smaller unit testable classes.

[clydebarrow]

I was thinking about this a little earlier in relation to a feature I need in one of my apps. The current MyLocationView is currently always anchored to the center of the view in tracking mode. I want to be able to move it towards the bottom of the view in conjunction with bearing tracking, to present a "Forward" style of view. There are several ways this could be done, but one would be to allow the user to supply an instance of a subclass of MyLocationBehavior which implements whatever it likes. This is currently not possible because that class is nested inside MyLocationView but it could easily be split out. More generally as you alluded to there could be a framework to add arbitrary widgets to the map. This probably requires an interface definition for a widget, a standard set of extensible widgets and a mechanism for adding and removing them. Maybe something like:

abstract class MapboxWidget extends android.view.View implements WidgetBehavior;
class AttributionWidget extends MapboxWidget;
class CompassWidget extends MapboxWidget;
class LogoWidget extends MapboxWidget;
class LocationViewWidget extends MapboxWidget;
class LocationTrackingWidget extends LocationViewWidget;
class ScaleWidget extends MapboxWidget;

MapView#addWidget(MapboxWidget);
MapView#removeWidget(MapboxWidget);
MapView#getWidgets();
MapView#removeAllWidgets();
MapView#getWidget(???);

with appropriate xml attributes and defaults to preserve current default behaviour but allow it to be customised. So for example the current API calls to enable location tracking would add a LocationViewWidget or LocationTrackingWidget, preserving existing behaviour, but alternatively the user could supply their own widget rather than using e.g. setMyLocationTrackingMode(). Those API calls might in the future be deprecated.

This is a different capability from MarkerView particularly in that these widgets are, for the most part, anchored to specific screen locations, not geographical locations, and that they react to location changes and gestures.

While MapView is an extension of FrameLayout IMHO that should not be relied upon externally, so using findViewById() and addView() isn't a good solution.

[tobrun]

General thinking is to start introducing a plugin concept. This will result in moving widgets into seperate components. This makes this issue obsolete for now. Closing.