[Android Auto] Allow early initialization

[kmadsen]

Summary of changes

The MapboxCarMap has boilerplate to setup in android auto because it cannot be initialized until the CarContext has received an onCreate lifecycle callback. There is a clear pattern in any session or screen that can be resolved with an extension.

Here is the current solution. You keep a nullable or lateinit var of the MapboxCarMap. You then init a lifecycle observer which will create MapboxCarMap after the onCreate lifecycle callback. The MapboxCarMapObserver is an asynchronous callback, so it does not make sense to require asynchronous construction of the MapboxCarMap

class MapSession : Session() {
  private val carMapShowcase = CarMapShowcase()
  private var mapboxCarMap: MapboxCarMap? = null

  override fun onCreateScreen(intent: Intent): Screen {
    return MapScreen(mapboxCarMap!!)
  }

  override fun onCarConfigurationChanged(newConfiguration: Configuration) {
    carMapShowcase.loadMapStyle(carContext)
  }

  init {
    lifecycle.addObserver(object : DefaultLifecycleObserver {
      override fun onCreate(owner: LifecycleOwner) {
        mapboxCarMap = MapboxCarMap(MapInitOptions(carContext))
          .registerObserver(carMapShowcase)
          .registerObserver(CarMapWidgets())
      }

      override fun onDestroy(owner: LifecycleOwner) {
        mapboxCarMap?.clearObservers()
        mapboxCarMap = null
      }
    })
  }
}

Synchronous construction

This change separates construction from initialization. To make it easier to configure the MapboxCarMap before session is created. This is still lazy loading data, but is making the syntax and data management easier.

class MapSession : Session() {
  private val carMapShowcase = CarMapShowcase()
  private var mapboxCarMap = MapboxCarMap()

  override fun onCreateScreen(intent: Intent): Screen {
    return MapScreen(mapboxCarMap)
  }

  override fun onCarConfigurationChanged(newConfiguration: Configuration) {
    carMapShowcase.loadMapStyle(carContext)
  }

  init {
    lifecycle.addObserver(object : DefaultLifecycleObserver {
      override fun onCreate(owner: LifecycleOwner) {
        mapboxCarMap = mapboxCarMap.setup(carContext)
          .registerObserver(carMapShowcase)
          .registerObserver(CarMapWidgets())
      }

      override fun onDestroy(owner: LifecycleOwner) {
        mapboxCarMap?.clearObservers()
        mapboxCarMap = null
      }
    })
  }
}

New installers

After the MapboxCarMap can be initialized before onCreate, this makes it so you can initialize a Session or Screen with a specified configuration. This removes the need to add a lifecycle observer, but still allows you to do so . And you can specify which lifecycle your observers should be attached to (on every app open? only when the session is created? and so on).

class MapSession : Session() {
  private val carMapShowcase = 
  private val mapboxCarMap = mapboxMapInstaller()
    .created(CarMapWidgets())
    .started(carMapShowcase)
    .install {
      // Create custom map init options here.
      MapInitOptions(it)
    }

  override fun onCreateScreen(intent: Intent): Screen = MapScreen(mapboxCarMap)

  override fun onCarConfigurationChanged(newConfiguration: Configuration) {
    carMapShowcase.loadMapStyle(carContext)
  }
}

Screens are also simple, this allows you to specify controllers like a gesture handler without thinking. The focus is put on designing MapboxCarObserver implementations that create the desired experiences.

class MapScreen(
  mapboxCarMap: MapboxCarMap
) : Screen(mapboxCarMap.carContext) {
  private var isInPanMode: Boolean = false
  private val carCameraController = CarCameraController()

  init {
    mapboxMapInstaller(mapboxCarMap)
      .created(carCameraController)
      .gestures(carCameraController.gestureHandler)
      .install()
  }

...

Pull request checklist:

• Briefly describe the changes in this PR.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality. If tests were not written, please explain why.
• Optimize code for java consumption (@JvmOverloads, @file:JvmName, etc).
• Add example if relevant.
• Document any changes to public APIs.
• Run make update-api to update generated api files, if there's public API changes, otherwise the verify-api-* CI steps might fail.
• Update CHANGELOG.md or use the label 'skip changelog', otherwise check changelog CI step will fail.
• If this PR is a v10.[version] release branch fix / enhancement, merge it to main firstly and then port to v10.[version] release branch.

Fixes: < Link to related issues that will be fixed by this pull request, if they exist >

PRs must be submitted under the terms of our Contributor License Agreement CLA.

[evil159]

LGTM :D

[pengdev]

In general looks good to me, besides a few nits.