A launch that opens in brand, and a sheet that stops resizing

── The splash, in three beats ──

Crimson edge to edge with the truck running across it in white; the invert;
then the mark.

The red starts before Flutter does. Four surfaces painted white before any
Dart runs — launch_background at both API levels, windowSplashScreenBackground
on Android 12+ in light and dark, and the iOS launch storyboard — and leaving
any one of them white makes the launch a white flash followed by a red one.
That flash is the only part of a launch a customer consciously notices.

The invert is one gesture rather than a fade. A white truck on a background
turning white is an invisible truck, so the ground lightens as the truck
darkens, off one controller, and the screen turns itself inside out with the
truck still on it. Fading it would have left the screen empty for the moment
before the mark.

The truck's colour is no longer its own: it is painted through srcIn, so the
file's palette is discarded and only alpha survives. A replacement Lottie now
needs no preparation, and tool/lottie_brand.py is off this path.

`splash.json` is a seamless 3.9s loop — frame 0 is frame 60, the truck never
arrives or departs — so there is no completion to hand over on. _truckBeat is
a decision about how long a launch may hold somebody, not a property of the
file. The comment claiming six seconds was wrong on both counts.

── Three things the splash was getting wrong quietly ──

It showed the wrong logo: doormile-icon.png, the previous mark, to a customer
who had just tapped the new one. tool/icons.py now cuts doormile-mark.png from
the same master alpha as the launcher icon, so they cannot drift again.

The fallback loader was invisible on red. _RoadLoader painted in DmColors.brand
on what used to be a white screen; on crimson that is crimson on crimson, and
it drew nothing at all on exactly the devices that had fallen back to it.

The mark appeared and left in the same frame — _minimum was the sum of the
beats exactly, so the clock ran out as the entrance finished. Hence _markHold.

── The truck was not in the middle ──

Not a layout bug: both beats sit in a Center and always did. The artwork is
drawn low and to the right inside its own 500x500 composition, so a centred
widget rendered an off-centre picture — 30pt right, 36pt down.

splash_centring_test.dart renders a frame at phone size and density, finds the
ink and fails if either beat drifts. It is the only form of test that could
have caught this, and the one that will catch it again when the Lottie is
replaced, which is when the correction goes stale. Two things it taught:
one enormous pump does not let the splash's async start-up chain advance, and
capturing at pixelRatio 1 rasterizes the speed lines too faintly to detect,
which truncates the bounding box and moves the measured centre by 12pt.

── The destination sheet stops resizing ──

Tapping ONE TOUCH opened a tall sheet that snapped shorter a few frames later.
DmAsyncList renders four skeleton rows while it loads — 302pt — and the states
that replace them are nearer 200; the sheet was Flexible, so it was as tall as
whichever state its content happened to be in, and the modal is still
animating up while that swap happens.

The list now lives in a box of one height. That also removes a second resize:
the sheet grew from 48% of the screen to 74% when a state was picked. Both
steps now measure 64% and it never changes size again.

And DmAsyncList takes initialItems, fed by AppState.cachedCities: FutureBuilder
reports `waiting` on its first build even for an already-complete future, so a
warm cache still flashed a skeleton over data it already had.

Three skeleton rows here rather than four — sheet_stability_test caught that
302pt overflows the smallest box the clamp can produce.
This commit is contained in:
2026-09-28 12:54:03 +05:30
parent 49b0de0d8f
commit 8427824951
41 changed files with 772 additions and 132 deletions

View File

@@ -1,11 +1,11 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Shown from process start until the first Flutter frame.
Deliberately empty. It used to centre a mark on it, which meant the
customer saw a logo, then Flutter's own splash animation, then the logo
again — the same image twice with a jump between them. The window
background is now the surface the Flutter splash opens on, so the handover
is a single continuous screen. -->
Deliberately empty, and deliberately crimson. Empty because it used to
centre a mark, which meant the customer saw a logo, then Flutter's splash,
then the logo again. Crimson because the Flutter splash now opens on
crimson: paint this white and the launch is a white flash followed by a
red one, which is the seam this file exists to remove. -->
<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
<item android:drawable="@color/dm_surface" />
<item android:drawable="@color/dm_splash_bg" />
</layer-list>

View File

@@ -1,11 +1,11 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- Shown from process start until the first Flutter frame.
Deliberately empty. It used to centre a mark on it, which meant the
customer saw a logo, then Flutter's own splash animation, then the logo
again — the same image twice with a jump between them. The window
background is now the surface the Flutter splash opens on, so the handover
is a single continuous screen. -->
Deliberately empty, and deliberately crimson. Empty because it used to
centre a mark, which meant the customer saw a logo, then Flutter's splash,
then the logo again. Crimson because the Flutter splash now opens on
crimson: paint this white and the launch is a white flash followed by a
red one, which is the seam this file exists to remove. -->
<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
<item android:drawable="@color/dm_surface" />
<item android:drawable="@color/dm_splash_bg" />
</layer-list>

View File

@@ -3,13 +3,13 @@
<!-- Android 12+ uses the platform splash screen API, and it cannot be
switched off: leave the icon unset and the platform draws the launcher
icon instead. So it is set to a fully transparent one, over the same
white the Flutter splash opens on, which makes the system beat a blank
white screen indistinguishable from the frame after it.
crimson the Flutter splash opens on, which makes the system beat a
blank red screen indistinguishable from the frame after it.
The customer sees two screens, not three: the truck, then the mark. -->
<style name="LaunchTheme" parent="@android:style/Theme.Light.NoTitleBar">
<item name="android:windowBackground">@drawable/launch_background</item>
<item name="android:windowSplashScreenBackground">@color/dm_surface</item>
<item name="android:windowSplashScreenBackground">@color/dm_splash_bg</item>
<item name="android:windowSplashScreenAnimatedIcon">@drawable/dm_splash_blank</item>
</style>
<style name="NormalTheme" parent="@android:style/Theme.Light.NoTitleBar">

View File

@@ -9,7 +9,7 @@
The customer sees two screens, not three: the truck, then the mark. -->
<style name="LaunchTheme" parent="@android:style/Theme.Light.NoTitleBar">
<item name="android:windowBackground">@drawable/launch_background</item>
<item name="android:windowSplashScreenBackground">@color/dm_surface</item>
<item name="android:windowSplashScreenBackground">@color/dm_splash_bg</item>
<item name="android:windowSplashScreenAnimatedIcon">@drawable/dm_splash_blank</item>
</style>
<style name="NormalTheme" parent="@android:style/Theme.Light.NoTitleBar">

View File

@@ -7,4 +7,11 @@
tool/icons.py, not typed here: if the logo is redrawn in a
different crimson, the adaptive background follows it. -->
<color name="dm_icon_bg">#BD0921</color>
<!-- What the window is painted while the process starts, and what the
Flutter splash opens on. The same crimson as the launcher icon, on
purpose: the customer taps a red icon and the screen fills with that
red, which reads as one gesture rather than as an app loading. It
hands over to white before any UI appears, so this and dm_brand never
sit side by side. -->
<color name="dm_splash_bg">#BD0921</color>
</resources>