Commit Graph
2 Commits
Author SHA1 Message Date
Alby96andClaude Opus 5 91f9ac0fbf Animate the radar timeline with a double-buffered overlay
Completes milestone 3: frames render over the map, play as a loop, and can be
scrubbed, with the legend drawn from the manifest rather than a constant that
could drift from what the worker actually rendered.

The overlay alternates two MapLibre image sources. Updating one source in place
flickers, because the layer briefly shows a half-written texture; adding every
frame as its own layer avoids that but pins them all in GPU memory, and twenty
512x512 RGBA frames is about 80 MB. Two buffers cost the same whether the
timeline holds six frames or sixty. Platform-channel work is serialised because
`show` is called faster than the round trip completes during playback, and
overlapping updates would swap visibility out of order and strobe.

Prefetching loads a window around the playhead, nearest first and forward
before backward, since playback moves forward and that frame is needed
soonest. `FrameCache` is byte-budgeted rather than entry-counted because frame
size tracks how much precipitation is on screen, and it evicts by distance from
the playhead: plain LRU would keep frames the prefetcher touched a moment ago
even after the playhead moved to the far end of the timeline.

Also adds DpcRadarSource, which reads published frames from our CDN and never
from the DPC API. Without it, the `dpc` adapter would have had to fall back to
mock, putting demo frames on screen under the label of live data — exactly the
confusion the adapter split exists to prevent. It now fails naming the missing
setting instead.

Running it on the emulator caught three things the tests had not:

- The notifier wrote to `state` from inside `build()`, which Riverpod rejects
  as an uninitialised provider. That broke startup, not just tests.
- Eight-month-old demo frames rendered as "Aggiornato 342535 minuti fa". The
  age formatter now steps up to hours and days.
- Demo mode sat permanently behind a stale-data warning and so never showed the
  working state it exists to demonstrate. MockRadarSource now shifts the
  bundled timestamps onto the present, leaving images, order and spacing
  untouched, so the timeline behaves exactly as it would on live data.

Corrects docs/stack-decisions.md, which described a disk cache that was not
built: mock frames already live in the asset bundle, so a disk layer belongs
with the network adapter where it would save a real request.

Verified: analyze clean, 129 tests passing, and on the emulator the loop
advances, wraps, and reports "Aggiornato ora".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-10 12:57:16 +02:00
Alby96andClaude Opus 5 71557a02d7 Add the radar data layer with the offline mock adapter
Introduces the RadarSource seam and the manifest it speaks, plus the demo
frames that make the app runnable with no network and no credentials.

MockRadarSource is a real adapter rather than test scaffolding, and that is
what makes the rest of milestone 3 testable: the timeline, prefetching, cache
eviction and every degraded path can be exercised offline because the demo
frames parse the same manifest document the Python worker will publish. Its
assets come from tool/generate_mock_frames.py — committed so the app runs from
a clone, generated by a script so they can be regenerated instead of
hand-edited. Twenty-four 512x512 frames total 108 KB, and the generator is
pure standard library so nobody needs Pillow to build the app.

The manifest parser rejects three things that would otherwise fail silently and
look plausible:

- A CRS other than EPSG:3857. The map overlays each PNG on a lat/lng quad,
  which only lines up if the image is already in Web Mercator; anything else
  renders visibly skewed with no error to explain why.
- A missing attribution. The frames are a derived product of CC BY-SA data, so
  the credit has to travel with them rather than be remembered at render time.
- Legend stops that do not ascend, which would silently mislabel intensities.

The legend travels in the manifest rather than living as a constant here,
because the worker chose those colours when it rendered the PNGs and a local
copy could drift. RadarLegend.colorFor returns null below the lowest stop:
"no precipitation" has to be transparent, not the first colour of the ramp, or
a dry region renders as drizzle everywhere.

Every failure reaches the caller as a single RadarUnavailableException
regardless of cause, because the app's response is the same in all of them —
hold the last good frame and say how old it is — and branching on cause would
only invite divergence.

ArpaRadarSource is a stub whose every method throws. It is named by the region
config as unavailable and must fail loudly: quietly serving something else
would misreport where the data came from.

Verified: analyze clean, 95 tests passing, including a check that every frame
the manifest lists exists and is a real PNG, and that its bbox matches the
region config.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-10 12:04:22 +02:00