Navigation API and View implementation registry

@LukasPaczos commented on Wed Jan 27 2021

Refs https://github.com/mapbox/mapbox-navigation-android-internal/pull/82#discussion_r565260639.

To increase the discoverability of UI SDK components, the Nav SDK base module could ship with an empty object, where all default API and View implementations could register their instances. This way, all of the possible components will be discoverable in the IDE from a single entry point. Example below.
We have:

package com.mapbox.navigation.base

object MapboxNavigationApiRegistry

and we have:

class MapboxSnapshotterApi(
    val context: Context,
    private val mapboxMap: MapboxMap,
    private var options: MapboxSnapshotterOptions,
    private val mapView: MapView
) : SnapshotterApi { ... }

fun MapboxNavigationApiRegistry.createSnapshotterApi(
    context: Context,
    mapboxMap: MapboxMap,
    options: MapboxSnapshotterOptions,
    mapView: MapView
): MapboxSnapshotterApi = MapboxSnapshotterApi(context, mapboxMap, options, mapView)

and we have:

class MapboxSignboardApi(
    private val accessToken: String
) : SignboardApi { ... }

fun MapboxNavigationApiRegistry.createMapboxSignboardApi(
    accessToken: String
): MapboxSignboardApi = MapboxSignboardApi(accessToken)

then we can do:

val snapshotterApi = MapboxNavigationApiRegistry.createSnapshotterApi(...)
val signboardApi = MapboxNavigationApiRegistry.createSignboardApi(...)

Using code completion on MapboxNavigationApiRegistry would reveal all possible components.

We could do the same with MapboxNavigationViewRegistry or even expose both Apis and Views under the same object.

What do you think @mapbox/navigation-android?

@cafesilencio commented on Wed Jan 27 2021

+1 this would facilitate a factory pattern which i'm a fan of.