Doormile/doormile_customer_app
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Redesign: Poppins, a two-step destination, and a splash that says what the app does

Browse Source 
The effort pass, end to end. Every screen was run through one test — if I
remove this sentence, does the customer make a worse decision? — and the parts
that failed it are gone.

The flow

  Home ▸ BOOK ▸ Where is it going? ▸ When shall we collect? ▸ details ▸ booked

BOOK opens a sheet, not a form. The destination is browsed state-then-district
because a flat list of every serviceable district survives twelve and not
sixty, and search cuts across states because somebody who knows they are
sending to Chennai should not have to know which state it is in. Districts
multi-select, but only where the server allows it: BookingLimits advertises
maxDestinations: 1 until the Miler build keys on consignmentid, and a sheet
that ignored that would sell a booking the network cannot complete.

The pickup window is now a step the customer answers rather than a slot chosen
for them. A pickup window is a promise about somebody's afternoon.

What the screens stopped saying

Home lost the orb caption for returning customers and a four-cell live card.
Send lost the city strip, both address fields, the optional disclosure and
three sentences about charging — the route, the packages and the button are
what is left. Tracking lost a radar with a bike in it, a Milers-in-your-zone
count, a "Step 2 of 7" and a sentence describing the screen you were looking
at. The window sheet lost "Fastest pickup", "4 Milers nearby" and "Relaxed
evening handover".

Type

Poppins, which has no variable release — four static cuts, and the sans styles
set fontWeight alone because fontVariations on a static font is ignored in
silence. Every weight dropped a step and the tracking went deeper: Poppins is
built on near-circles and carries more ink than the humanist faces before it.

Objects

One lit sphere on Home, and the primary button now takes its gradient and rim
because a committing action that is not lit like the hero reads as a different
material. The tracking rail's connector is crimson as far as the parcel has
come, so the line is the progress bar. Confirmation is a white tick on green:
crimson is this app's action colour and that screen has nothing left to do.

Bugs found on the way

The OTP screen dropped digits. Four fields passing focus along lose a keystroke
that arrives mid-transition, so "1234" became "124" and the screen answered
"That code did not match" — blaming the customer for its own race. One field
now, four boxes that only draw.

Nothing ever asked for the customer's location: detectPickupLocation was the
OTP screen's job, so a restored session or an auto-login never triggered the
permission prompt and the pickup map had nothing to centre on.

The launcher icon and both splash screens pointed at a house drawn as two
vector paths — a placeholder that shipped.

The splash clock started when the widget was built rather than when it was
visible, so the truck got 0.45s of a 1.8s beat behind Android's own splash.
It waits on waitUntilFirstFrameRasterized now, raced against a timeout so a
binding that never reports one cannot strand the app.

Also: design/screens/ holds all 19 screens under readable names, tool/ has the
scripts that refresh them and rebrand the Lottie, and DESIGN.md is current.

flutter analyze clean. 88 tests, 1 skipped.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EqVJPB9B4QuieZnBAAKgYQ
This commit is contained in:
Thiru-tenext
2026-09-22 17:45:54 +05:30
parent 8207e27a97
commit 06fa6b797a
107 changed files with 4597 additions and 2071 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
lib/state/app_state.dart
View File

@@ -93,7 +93,7 @@ class AppState extends ChangeNotifier {
final restored = await api.restoreSession();
if (restored != null) {
customer = restored;
unawaited(refreshOrders());
_afterSignIn();
} else if (AppConfig.devAutoLogin) {
// ── Offline builds open on Home, not on a login screen ──
//
@@ -106,7 +106,7 @@ class AppState extends ChangeNotifier {
// Real builds are untouched: `useDevData` is false in every one of
// them, so the login screen a customer meets is the real one.
customer = await api.verifyOtp('+91 9876543210', '1234');
unawaited(refreshOrders());
_afterSignIn();
} else if (AppConfig.hasAutoLogin) {
await _autoSignIn();
}
@@ -146,7 +146,7 @@ class AppState extends ChangeNotifier {
// fails once on a cold Redis and falls through to the request below.
try {
customer = await api.verifyOtp(identifier, code);
unawaited(refreshOrders());
_afterSignIn();
debugPrint('[AUTH] DM_LOGIN_AS — signed in as $identifier');
return;
} catch (_) {
@@ -156,7 +156,7 @@ class AppState extends ChangeNotifier {
try {
await api.sendOtp(identifier);
customer = await api.verifyOtp(identifier, code);
unawaited(refreshOrders());
_afterSignIn();
debugPrint('[AUTH] DM_LOGIN_AS — signed in as $identifier after a request');
} catch (e) {
debugPrint(
@@ -166,6 +166,20 @@ class AppState extends ChangeNotifier {
}
}
/// The two things every signed-in session needs, whichever door it came in
/// through.
///
/// Finding the customer's own location was the OTP screen's job, which meant
/// it only happened on the one path that shows an OTP screen. A restored
/// session, a dev auto-login and `DM_LOGIN_AS` all skipped it — so the app
/// opened on Home reading "Set a pickup address", never asked for the
/// location permission, and the pickup map had nothing to centre on. It is
/// not the entrance's job; it is the session's.
void _afterSignIn() {
unawaited(refreshOrders());
unawaited(detectPickupLocation());
}
/// Called by the API layer when a refresh fails — the chain is dead, so the
/// customer is signed out wherever they happen to be standing.
void onSessionLost() {
@@ -473,6 +487,13 @@ class AppState extends ChangeNotifier {
}
}
/// Who the Miler asks for at the pickup door.
///
/// Null means the signed-in customer, which is the answer nearly every time
/// — so the field on the pickup screen opens prefilled with their number and
/// this stays null until they change it.
String? draftContactPhone;
Future<Booking> confirmBooking() async {
final key = _bookingIdempotencyKey ??= _newIdempotencyKey();
try {
@@ -481,6 +502,7 @@ class AppState extends ChangeNotifier {
destinations: draftDestinations,
slotId: draftSlotId,
fare: draftFare,
contactPhone: draftContactPhone,
idempotencyKey: key,
);
// The intent is spent. A further booking needs a new key or the server
@@ -764,6 +786,23 @@ class AppState extends ChangeNotifier {
selectDistrictFor(index, city.district);
}
/// Replaces the draft's destinations with exactly these, in order.
///
/// The destination sheet answers with a list — one place, or several out of
/// one Miler visit — and this is the only thing that writes it onto the
/// draft. Clamped to [BookingLimits.maxDestinations] rather than trusted:
/// the sheet already obeys the cap, but the cap is a server answer that can
/// change between the sheet opening and this being called, and a draft that
/// exceeds it is a booking the network will refuse.
void setDestinations(List<CityOption> cities) {
if (cities.isEmpty) return;
final take = cities.take(limits.maxDestinations).toList();
draftDestinations = [for (var i = 0; i < take.length; i++) DestinationGroup()];
for (var i = 0; i < take.length; i++) {
selectCity(take[i], index: i);
}
}
/// Names of districts in this state that are not open yet, for a quiet
/// "Coming soon" line. Empty until the districts have been fetched.
List<String> upcomingDistricts(String stateCode) => (districtCache[stateCode] ?? const [])