Skip to main content

Driver App developer reference

Build and maintain delivery workflows while keeping app, Ordering.co Components, Ordering.co API, operating-system, and provider responsibilities separate. Start with the product experience, then select the narrowest integration or engineering contract for the work.

Product workflows​

  • Driver App product guide — understand startup, availability, delivery requests, active deliveries, maps, communication, account management, and history from the driver's perspective.

Product documentation describes observable outcomes and current limitations. It does not make internal routes, client state, or server implementation details public contracts.

Integrations​

  • Permissions and integrations — distinguish requested, declared, effective, platform, lifecycle, and provider states.
  • Notifications — separate permission, provider setup, token registration, delivery, and push-open routing.
  • Realtime — handle connection, rooms, events, ordering, reconnect, and cleanup without using transport as authority.
  • Location — protect collection, foreground/background use, validation, publication, and cleanup boundaries.
  • Maps — separate order data, device position, map rendering, position writes, and external navigation.
  • Communication — separate reads, writes, receipts, sockets, media, and external contact.
  • Media — distinguish selection or capture from authorization, upload, storage, and proof.
  • Background execution — own AppState, background-location, permission, session, and listener cleanup.

These integrations can create server, provider, device, or physical effects. Use an approved isolated environment, purpose-minimal synthetic data, a single-attempt budget, and an observable cleanup plan.

Engineering​

Foundations​

  • Driver App engineering guide — set up the repository, understand its layers, run the native apps, verify changes, and prepare a release handoff.
  • Architecture — use the reviewed application structure and navigation responsibility boundaries.
  • Configuration — keep public inputs, ownership, transport, and secret boundaries explicit.
  • Authenticated bootstrap — maintain the boundary from restored session state to authenticated navigation.
  • Authentication — separate configured sign-in branches, Driver role checks, and local session state.
  • Language — maintain persistence, dictionary, fallback, loading, and partial RTL boundaries.
  • Session management — maintain session listing, activation, deletion, logout guard, and local cleanup boundaries.
  • Profile — maintain profile, photo, availability, schedule, session, logout, and deletion boundaries.
  • Schedule gate — interpret the local schedule gate and its missing-value and return behavior.

Orders, logistics, and financial display​

  • Order queries — define list and detail reads, filters, tabs, pagination, grouping, events, and currentness.
  • Order state — separate client display categories, server state, availability, grouping, and logistics requests.
  • Order details — maintain read, presentation, sensitive-data, mount-effect, grouping, and action boundaries.
  • Order mutations — define authorization, locks, reasons, media, location, grouped partiality, follow-ons, and idempotency.
  • Logistics requests — separate discovery, eligibility, decisions, grouped effects, and per-order follow-ons.
  • Proof of delivery — audit delivery status, PIN, image, location, parser, and result integrity.
  • Offline actions — apply the current exclusion and fail-closed requirements for offline replay.
  • Payment display — interpret payment labels and summaries without making financial completion claims.
  • History and support — keep history reads, display, order-specific help, and payment boundaries separate.
  • Customer reviews — separate visibility, input, relation checks, duplicate handling, persistence, and local follow-ons.

Available capabilities depend on the app build, API revision, provider configuration, and background permissions enabled for the target deployment.