── The full-address path was reaching the Miler empty ──
`DestinationGroup.toBookingJson` spread its details FLAT across the
destination. The contract nests them under `details{}`, and a destination
carrying keys the server does not recognise is accepted without a word — so
every building number, street, landmark, recipient name, recipient phone and
pin a customer typed was written, answered 201, and thrown away. The Miler
arrived with a district.
Four more on the same call. The destination pin spelled `latitude`/`longitude`
— the same spelling that answered 422 unserviceable for months on the pickup
before it was fixed there and missed here. A PATCH that sent `null` to clear a
field, with a comment saying so, when the server writes only non-nil values, so
a landmark could be added and never removed. Per-destination `instructions`
folded into the visit's one `remarks` line on the belief the contract had no
per-destination note; it has one. And `contactName`/`contactPhone` on the
pickup object, which the create contract has no room for and drops.
The fix ships unverified, deliberately. If `details{}` is also the wrong shape
the fields drop exactly as they do today — it cannot be worse, and holding it
costs every full-address booking in the meantime. docs/BACKEND_CHANGES.md asks
for the confirmation; tool/verify_booking.sh runs it in one command.
── Who the Miler rings ──
One number reaches the rider and it is the account's: `GET /miler/bookings`
returns a single `customerphone`, verified against production and written down
in the rider app's own stop_contact.dart. So "Someone else is handing it over?"
was collecting a number that reached nobody.
Review now shows the number that will actually be dialled, and the handover
person travels in `remarks` with a name, labelled for whoever reads it. Both
screens say plainly that the rider's call button still dials the account —
better than letting somebody hand their parcel to a neighbour believing
otherwise.
── Account's rows led nowhere ──
Two had no `onTap` at all — a chevron pointing at a page that did not exist —
and three answered with a toast. Five rows making a promise, one keeping it.
Notifications, Payment, Help and About are real screens now, written to one
rule: say only what is true of this app today. There is no notification
endpoint, no stored payment instrument and no push SDK wired in, so none of
them pretends to manage any of that. Support shows no contact block at all
rather than a number that rings nowhere — AppConfig carries the fields empty
until somebody fills them in.
── ONE TOUCH is one sheet ──
It was two in sequence with a dismissal between them, and the destination step
made you open a state to see any city — two levels of navigation for something
its own search already flattened. One flat list headed by state, which is also
the answer to "where do you deliver?", and one surface that changes its
question instead of closing so another can open.
Home says the reach in a line, and it needed two fixes to appear at all:
`cachedCities` walked closed states looking for districts that are only fetched
for open ones, and `loadCities` filled two caches while notifying nobody.
── Sending a second parcel ──
`maxDestinations` is 1 in production, so two parcels for two places means
booking twice — and that cost the whole flow twice, re-answering a door the
customer had not moved from. `startBookingFrom` carries the door, carries the
destination only when asked, and never carries the window: a slot fills up, and
a second booking pinned to one that is now full is refused at confirm with
nothing the customer can act on.
Review also says why there is no "add another destination", so a cap reads as a
limit rather than a missing button.
── Bundle ──
pubspec named its images one by one. Declaring `assets/images/` as a folder
shipped a 974 KB launcher-icon master to every customer for a file no code
opens.
199 lines
7.5 KiB
Dart
199 lines
7.5 KiB
Dart
import 'app_config.dart';
|
|
import 'dev_doormile_api.dart';
|
|
import 'live_doormile_api.dart';
|
|
import 'models.dart';
|
|
|
|
export 'api_exception.dart';
|
|
|
|
/// The service surface the app is written against.
|
|
///
|
|
/// **[LiveDoormileApi] is what ships,** against `/customer/*` on
|
|
/// `api.doormile.com`. When the server cannot be reached the screens show their
|
|
/// designed error state, which is the only honest answer.
|
|
///
|
|
/// [DevDoormileApi] answers instead when [AppConfig.useDevData] is set — under
|
|
/// `FLUTTER_TEST`, or a debug build given `--dart-define=DM_MOCK=true`. That
|
|
/// getter is `false` in a release whatever is passed, so a shipped build has
|
|
/// one implementation and a booking a customer makes is one the server
|
|
/// accepted.
|
|
///
|
|
/// ── Why this is guarded so tightly ──
|
|
///
|
|
/// An offline build was deleted from this app on 15 Sep 2026 after it cost two
|
|
/// rounds of hunting for bookings in the admin console that had never left the
|
|
/// phone. What made that expensive was not the fake existing — it was that the
|
|
/// fake was reachable without announcing itself, and that nothing stopped it
|
|
/// reaching a release. Both are closed now: the release guard above, and the
|
|
/// Account screen printing DEV DATA (offline) the whole time it is on.
|
|
///
|
|
/// Screens never see this type at all — they call [AppState], which holds it.
|
|
///
|
|
/// A method the backend owns but no screen drives yet has a default here that
|
|
/// does nothing rather than throwing.
|
|
abstract class DoormileApi {
|
|
DoormileApi();
|
|
|
|
static DoormileApi? _instance;
|
|
|
|
/// The API this build talks to.
|
|
///
|
|
/// [LiveDoormileApi] unless the build asked for offline data, which a
|
|
/// release build cannot do — see [AppConfig.useDevData]. The check is here
|
|
/// rather than at the call sites so there is exactly one place that decides,
|
|
/// and nothing downstream has to know which one it got.
|
|
static DoormileApi get instance =>
|
|
_instance ??= AppConfig.useDevData ? DevDoormileApi() : LiveDoormileApi();
|
|
|
|
/// Replaces the singleton. Tests inject their double through here.
|
|
static void overrideInstance(DoormileApi? api) => _instance = api;
|
|
|
|
/// Called when the refresh chain dies and the customer must sign in again.
|
|
/// Set by [AppState].
|
|
void Function()? onSessionLost;
|
|
|
|
// --------------------------------------------------------------------- auth
|
|
|
|
/// Asks for a code. The answer describes the challenge — how many digits it
|
|
/// has and how long before it can be resent — so the screen is built from
|
|
/// what the server said rather than from constants.
|
|
Future<OtpChallenge> sendOtp(String identifier);
|
|
|
|
/// Creates the account **and** sends the first code, so it answers with the
|
|
/// same challenge [sendOtp] does.
|
|
Future<OtpChallenge> signUp({
|
|
required String name,
|
|
required String phone,
|
|
String? email,
|
|
});
|
|
|
|
/// [name] is set when verifying a freshly created account.
|
|
Future<Customer> verifyOtp(String identifier, String code, {String? name});
|
|
|
|
/// Restores a persisted session at launch, or null when there is none.
|
|
Future<Customer?> restoreSession() async => null;
|
|
|
|
/// Revokes the refresh token and unregisters the push token.
|
|
Future<void> signOut() async {}
|
|
|
|
/// Re-reads the signed-in customer — `GET /customer/auth/me`.
|
|
Future<Customer?> me() async => null;
|
|
|
|
// ----------------------------------------------------------- serviceability
|
|
|
|
Future<List<ServiceArea>> getServiceableStates();
|
|
|
|
Future<List<District>> getServiceableDistricts(String stateCode);
|
|
|
|
/// Synchronous district lookup for a code we already hold, backed by
|
|
/// whatever [getServiceableDistricts] last returned.
|
|
District? districtByCode(String? code);
|
|
|
|
// -------------------------------------------------------------------- slots
|
|
|
|
Future<List<PickupSlot>> getPickupSlots({Place? pickup});
|
|
|
|
PickupSlot? slotById(String? id);
|
|
|
|
// ----------------------------------------------------------------- location
|
|
|
|
Future<Place> reverseGeocode({double? lat, double? lng});
|
|
|
|
/// An empty query returns the customer's saved and recent places, which is
|
|
/// what the search sheet shows the moment it opens.
|
|
///
|
|
/// [lat]/[lng] bias the results towards where the customer is looking —
|
|
/// "MG Road" is in most Indian cities, and the one they mean is the near one.
|
|
Future<List<Place>> searchPlaces(String query, {double? lat, double? lng});
|
|
|
|
// ------------------------------------------------------------------- limits
|
|
|
|
Future<BookingLimits> getBookingLimits({Place? pickup});
|
|
|
|
// --------------------------------------------------------------------- fare
|
|
|
|
Future<FareEstimate> estimateFare({
|
|
required Place pickup,
|
|
required List<DestinationGroup> destinations,
|
|
});
|
|
|
|
// ------------------------------------------------------------------ booking
|
|
|
|
/// Creates the pickup booking. No tracking number yet — those are minted per
|
|
/// destination when the Miler completes the pickup.
|
|
///
|
|
/// [idempotencyKey] must be **held across retries of the same intent**. A new
|
|
/// key is a new booking, which is exactly what a double tap must not create.
|
|
///
|
|
/// [contactPhone] is who the Miler calls at the pickup door. Null means the
|
|
/// signed-in customer, which is what it was always sending — the parameter
|
|
/// exists because the person handing over the parcel is not always the
|
|
/// person who booked it.
|
|
Future<Booking> createBooking({
|
|
required Place pickup,
|
|
required List<DestinationGroup> destinations,
|
|
required String? slotId,
|
|
FareEstimate? fare,
|
|
String? contactPhone,
|
|
String? contactName,
|
|
String? idempotencyKey,
|
|
});
|
|
|
|
Future<void> cancelBooking(String reference, String? reason);
|
|
|
|
/// One page of the customer's bookings, newest first.
|
|
Future<BookingPage> getBookingPage({
|
|
BookingStatus? status,
|
|
String? cursor,
|
|
int limit = 20,
|
|
});
|
|
|
|
/// One booking, fresh. Null means the server answered `304` — nothing has
|
|
/// changed since the last read, so the caller keeps what it has.
|
|
Future<Booking?> getBooking(String reference);
|
|
|
|
/// One order by its tracking number — for a push deep link.
|
|
Future<Booking?> getOrder(String trackingId) async => null;
|
|
|
|
/// Adds the optional address and recipient after booking, up to collection.
|
|
Future<void> updateDestinationDetails(
|
|
String reference,
|
|
int index,
|
|
DeliveryDetails details,
|
|
) async {}
|
|
|
|
/// Backend policy decides this; the UI only asks.
|
|
bool isCancellable(JourneyStage stage);
|
|
|
|
// ------------------------------------------------------------------ ops QA
|
|
|
|
/// Moves a booking to [stage] through the backend's own non-production QA
|
|
/// helper — `POST /customer/ops/bookings/{reference}/stage`.
|
|
///
|
|
/// It exists so the tracking screen's stepper can walk a **real** staging
|
|
/// booking. The stage that then appears on screen is the one the server
|
|
/// recorded, not one the client wished for. Refused on production.
|
|
Future<void> setStage(String reference, JourneyStage stage) async {}
|
|
|
|
// ------------------------------------------------------------------ devices
|
|
|
|
Future<void> registerDevice(String token) async {}
|
|
|
|
Future<void> unregisterDevice(String token) async {}
|
|
|
|
// ------------------------------------------------------- profile & addresses
|
|
|
|
Future<Customer?> getProfile() async => null;
|
|
|
|
Future<Customer?> updateProfile({String? name, String? email}) async => null;
|
|
|
|
Future<List<SavedPlace>> getSavedLocations() async => const [];
|
|
|
|
Future<SavedPlace?> addSavedLocation(Place place, {String? label}) async =>
|
|
null;
|
|
|
|
Future<SavedPlace?> updateSavedLocation(SavedPlace place) async => null;
|
|
|
|
Future<void> deleteSavedLocation(String id) async {}
|
|
|
|
}
|