Mobile track

Imad builds both Flutter apps — the reseller app (application revendeur) and the delegate app (application délégué, for the field sales representatives) — in his own repository hoco-mobile. They talk only to the central API (https://api.hoco.dz/v1) and are designed by Akram in Claude Design. This section is the engineering guide for that repository: decisions already taken, recommendations with their reasons, and the procedures that connect the mobile track to Anis's contract and Akram's handoff.

Library choices below are recommendations: the final pick is Imad's, unless the choice changes the API contract (then it is agreed with Anis in SRV-03).

The two appsCopy Anchor Link

Android comes first, on mid-range phones (cahier §9, NFR-04). iOS is built only if HOCO decides it (decision D-10) and only after the pilot (MOB-16, phase P3), so it can never delay the go-live: keep the ios/ folders compiling, but spend no V1 time on them.

Product decisions that shape the Flutter codeCopy Anchor Link

These are binding (team decisions of 17 Oct 2026). Each one has a home in this guide.

Imad's planCopy Anchor Link

V1 has a three-month frame from design to deployment: production at the start of January, then a two-week pilot; generalisation, iOS and V2 come after. The mobile lane is the tightest one inside that frame — both apps are feature-complete only shortly before staging integration, the field test and store readiness, with no slack before acceptance. Dates are computed by the scheduler; the timeline shows all three lanes.

3-month frame: design → development → deployment — deadline 17 Jan 2027.

44 tasks · 69.75 d of open effort. Dates are computed — Sunday–Thursday weeks, holidays excluded.

Imad also takes part in tasks owned by others: the cadrage workshop PRJ-03, the screen-inventory validation DES-05, the contract SRV-03 (as its first reviewer), end-to-end testing QA-01, acceptance QA-02, go-live LCH-01 and generalisation LCH-05.

Working in parallel with AnisCopy Anchor Link

Anis defines services, then the database, then the API contract in the first week (SRV-01 → SRV-02 → SRV-03). The mobile track never waits for server code:

1. Before the contract — foundations that need no API: the repository, flavors and CI (MOB-01); hoco_core with the interceptors and the error envelope, which are already fixed by the API conventions (MOB-02); localisation and formatting (MOB-07); then the Flutter design system as soon as Akram's day-3 mobile components exist (DES-03 → MOB-04). Meanwhile Imad reviews contract drafts with the Dart-generation checklist.
2. Contract published (milestone API contract v1 published) — generate hoco_api, start the Prism mock server and build every screen against it (MOB-03). Stateful flows (cart, tour day) use in-memory fakes behind the same repository interfaces, because Prism does not keep state.
3. Modules land on staging — switch endpoint groups one by one from the mock to staging (progressive switch); full integration in MOB-12 with Anis.

What each feature task waits forCopy Anchor Link

Every feature task starts when its design day is done; it is built against the mock and becomes real when the server modules in the last column are on staging (checked in MOB-12).

The delegate app's offline engine is the riskiest piece: it is built in MOB-09 against the mock, but only SRV-23 on staging proves it, and the field test MOB-13 proves it under real network conditions. Ask Anis to deploy sync.batch and sync.delta to staging as early as SRV-23 allows, even before the delegate screens are finished.

First week checklistCopy Anchor Link

No application code is written before these specification pages are done and reviewed; the first week below is the first week of code, in the order of the plan. Time is tight — anything that slips here pushes every feature task, because the mobile lane has no buffer before acceptance.

Repository and tooling (MOB-01):

• Private repository hoco-mobile created under Imad's account, Anis and Akram invited, GitHub Pro active so branch protection applies (repository).
• Flutter stable pinned with FVM; Android SDK, JDK 17, Node 22 (Prism, commitlint) and gh installed.
• Pub workspace with apps/reseller, apps/delegate, apps/gallery and the seven hoco_* packages; melos run analyze and melos run test green.
• Flavors dev, staging, prod build on Android with their own application id suffix, name and icon; env/*.json read at start.
• CI on pull requests: format, analyze, test. lefthook with dart format and commitlint.

Core, localisation, design system:

• hoco_core (MOB-02): dio with the header, auth, idempotency, retry and gate interceptors; error-envelope parsing unit-tested against the examples of the error registry; secure storage for the token and the install id; Sentry in staging and prod.
• hoco_l10n (MOB-07): app_fr.arb as template, ar and en scaffolded, enum labels generated from enums.json, money, date, phone and distance formatters with tests.
• hoco_ui (MOB-04): token JSON received from Akram after day 2, theme generated after day 3, gallery app running on a phone.

Accounts and decisions to request through Anis at the cadrage workshop (PRJ-03) — most have lead times:

• Google Play Console organisation account owned by HOCO (D-U-N-S number and identity verification take time) — Imad gets admin rights for releases (build and release).
• Firebase projects dev, staging, prod created under HOCO's Google account; Imad and Anis editors.
• Google Cloud billing account for the Maps SDK key (maps provider pending, ADR-015).
• Store names of the two apps (working names HOCO Revendeur and HOCO Délégué), privacy policy owner, iOS yes/no (D-10 — needed only for the post-pilot iOS task).
• Background location: not requested unless HOCO insists — the foreground-service design covers tours (location).

Design and contract:

• Day 5 inventory session (DES-05): every RA/DA screen has a route in the route tables and its states listed (loading, empty, error, offline, guest, pending validation).
• Contract drafts of SRV-03 reviewed with the Dart-generation checklist; the mock server running the day the contract is published.
• Two physical test phones identified: one current mid-range Android (reference for the 3-second budget) and one older low-RAM phone.

Pages in this sectionCopy Anchor Link