AdminConsole
Tutorials/Intermediate
Intermediate50 minWeb + REST

Build a traffic-aware commute assistant

Compare departure choices, refresh bounded route alternatives, and explain when an ETA becomes stale.

By the endA route comparison experience that communicates freshness and uncertainty.
Real-world scenario

Build against an explicit contract

A commuter must compare leave-now choices using traffic-aware routes whose freshness and uncertainty are visible.

A Mappls developer projectA restricted Web applicationFixture data with no production credentialsA request, aggregate, or correlation ID strategy
Step 1

Define the user and system contract

A commuter must compare leave-now choices using traffic-aware routes whose freshness and uncertainty are visible. Record the region, data freshness, latency budget, privacy purpose, credential owner, and fallback before choosing an SDK or endpoint.

Step 2

Hold trip intent constant

Resolve endpoints, profile, exclusions, arrival/departure semantics, and user preferences once so comparisons do not mix different requests.

Routes & Navigation · SDK or product slice
val route = MapplsDirections.builder()
  .origin("MMI000")
  .destination("MMI001")
  .profile(DirectionsCriteria.PROFILE_DRIVING)
  .resource(DirectionsCriteria.RESOURCE_ROUTE)
  .steps(true)
  .build()

route.enqueueCall(object : Callback<DirectionsResponse> {
  override fun onResponse(call: Call<DirectionsResponse>, response: Response<DirectionsResponse>) {
    val primaryRoute = response.body()?.routes()?.firstOrNull()
  }
  override fun onFailure(call: Call<DirectionsResponse>, error: Throwable) = Unit
})
Step 3

Version every refresh

Store route/request identity, observation time, traffic horizon, geometry, duration, distance, and incidents; cancel obsolete requests and never merge alternatives across revisions.

Step 4

Communicate change

Explain the meaningful delta, highlight changed segments accessibly, set a refresh threshold, and show the last successful estimate during temporary provider failure.

Step 5

Prove the production behavior

Automate the happy path and every named failure. The release is ready only when alternatives are compared within one revision; stale estimates show their age; refresh does not flicker or reorder without explanation. Capture provider request identity without logging credentials or unnecessary precise location.

Recovery design

Failure modes you must exercise

traffic data becomes stale

Fail fast with a typed, user-safe outcome and preserve the original request identity.

route changes during user selection

Keep the last verified state, mark freshness honestly, and retry only within the documented idempotency boundary.

provider returns a slower partial response

Reconcile durable local and provider evidence before declaring success or issuing a compensating command.

Never turn uncertainty into success

Timeout after a stateful command is an unknown outcome. Query by provider/idempotency identity or wait for authoritative events; do not blindly retry a new command.

Acceptance criteria

Definition of done

alternatives are compared within one revisionstale estimates show their agerefresh does not flicker or reorder without explanation

Web production checks

Origin restrictions include every deployed hostnameMap lifecycle follows the framework lifecycleLarge datasets are tiled, clustered, or progressively loadedKeyboard, touch, reduced-motion, and failure states are tested
Grounded implementation

Continue from source, contracts, and a full app

These links resolve to repository-derived evidence; unsupported package names and endpoints are not filled in from guesswork.

Study the complete Coordinated incident response state machine
Tutorial complete

Run it, break it, then observe it

Start with fixture credentials, execute the failure plan, and use request logs, usage, webhook evidence, and operational metrics before promoting traffic.