Modularization

VERSION 1.19.0
PUBLIC PREVIEW

Navigation SDK for Android is only available upon request. Contact us to get started.

The architecture of TomTom SDKs is modular, meaning that each navigation component is independent of the others.

As a result of this modularization, components are easily replaced with ones from other sources or omitted when they are not needed. Modularity makes it easier to change the standard SDK to address a specific use case.

These replaceable components are referred to as engines.

Orchestrator

The Navigation module depends on engines to orchestrate a pipeline after each location update. The location updates are supplied by the LocationProvider. Read more about the LocationProvider used by the navigation in the Location tracking guide. If the LocationProvider doesn’t provide a new location, the system falls back to dead reckoning after few seconds.

On each processing pipeline the snapshot of engines is taken and those engines are used during different parts of the navigation flow, as shown in the following figure.

ss navigation flow

Engines

The orchestrator works with the following engines:

  • DataStoreSelectionEngine - Decides what navigation data store to use in the next navigation cycle. This is only relevant for hybrid mode.
  • [Internal] RouteProjectionEngine - Responsible for projecting the input route to obtain map references.
  • MapMatchingEngine - This improves the accuracy of a position by attempting to match it to a map or a route.
  • HorizonEngine - Provides horizon data for the given location, based on a list of registered sets of horizon options.
  • RouteProgressEngine - This determines the progress made so far along the routes.
  • RouteTrackingEngine - This detects whether the driver follows or deviates from the routes.
  • ArrivalDetectionEngine - Engine which determines the arrival status of the route destination or the next waypoint during navigation.
  • GuidanceEngine - This generates guidance for upcoming road maneuvers.
  • RouteReplanningEngine - This replans routes.
  • DataStoreMaintenanceEngine - Instantiates the update of the data store used for navigation.

Customized engines are specified in two ways:

  • During creation of the configuration object for the selected mode:
  • Dynamically on an existing TomTomNavigation object using NavigationEngineRegistry.
    1tomTomNavigation.navigationEngineRegistry.updateEngines(
    2 mapMatchingEngine = mapMatchingEngine,
    3 guidanceEngine = guidanceEngine,
    4 routeProgressEngine = routeProgressEngine,
    5 routeTrackingEngine = routeTrackingEngine,
    6 arrivalDetectionEngine = arrivalDetectionEngine,
    7)

Navigation session data is passed between different engines and pipeline iterations using NavigationSnapshot.

The snapshot doesn’t contain all session data, just what other engines need as input (e.g., the RouteProgressEngine uses the MapMatchingResult to calculate the progress along the route). You can see the order that engines use data in the description of the orchestrator.

Because it provides other engines with input data, the navigation snapshot always contains current information about the navigation session, such as current location, matched location, and progress along a route. It is updated whenever new values are available.

The data is divided into the following classes:

The current navigation snapshot can be accessed using the TomTomNavigation.navigationSnapshot property. Note that the snapshot is null if the navigation is not yet started, is started but the first location is not yet provided, or has already been stopped.

Next steps

Since you have learned about our modular architecture, here are recommendations for the next steps: