main
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  Alby96andClaude Opus 5
|
f434a68155 |
Replace the default Flutter icon with a stylised cloud
The app shipped the Flutter template's blue F, which said nothing about what it does and did not match the interface. The launcher icon is now a white cloud on the same seed blue the app themes itself with, so the two read as one product. The icon is drawn rather than hand-edited: tool/generate_icon.py renders it from signed distance fields — a union of three circles and a rounded box — using only the standard library, so regenerating it needs no image toolchain. The shape's framing is derived from its own bounding box, which is what keeps it centred; maintaining the bounds separately from the shape had it drifting off-centre. Adds the adaptive icon and the Android 13 monochrome layer, which were missing entirely. The generator frames the cloud against the 72dp the launcher mask always keeps and adaptive_icon_foreground_inset is 0, so the layer is not shrunk twice and the icon reads at the same size as its neighbours on a home screen. Verified on the emulator: the cloud appears in the app drawer and holds its shape down to 48px. docs/architecture.md records how to regenerate it, including the flutter_launcher_icons 0.14.4 bug that writes a string into a boolean Xcode setting and needs reverting by hand afterwards. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Alby96andClaude Opus 5
|
b4b8d089e6 |
Add municipality and coordinate search, and a map target selector
Puts the controls that change what the map is looking at over the map itself, where they act, and gives them something to search. Search is one field, not two. A string either parses as coordinates or it does not, and the answer is obvious from the text, so making the user declare up front which kind of thing they are looking for would be asking them to do the program's job. Coordinates accept decimal and degrees-minutes-seconds, comma or space separated, with hemisphere letters — including the Italian O for ovest, because someone reading an Italian map will type it and silently reading it as east would put them the wrong side of Greenwich. The 1180 Piedmont municipalities are bundled rather than geocoded online. The app is region-scoped, so a list of one region's towns is small enough to ship (100 KB) and beats a geocoder on every axis that matters: instant, offline, no API key, no rate limit, and it cannot return a result somewhere the app has no radar for. Matching folds accents, so "aglie" finds "Agliè", and prefix matches outrank substring ones — typing "tor" should surface Torino, not the first alphabetical name that happens to contain those letters. tool/generate_places.py derives the list from Istat boundary shapefiles (CC BY 4.0). Two properties of that file cost time and are now written down: the geometry is UTM 32N rather than degrees, and the DBF is UTF-8 despite one bilingual Friulian record that makes strict cp1252 fail. A terminal renders utf-8 and latin-1 output identically, so the encoding cannot be settled by looking at printed text — it took dumping codepoints. A guard in the generator and a test against the shipped asset both check for mojibake now, and the guard caught a real mistake the moment it was written. The target selector switches between following the device, a saved place, and the whole region, and the selection doubles as what the app reopens on: "the place I marked" and "what I see when I open the app" are one idea to the person using it. Dragging the map while it is following stops the camera chasing them but leaves that preference alone, because looking somewhere else now is not the same as changing their mind about next launch. The position marker and the following are MapLibre's own, driven by onCameraTrackingDismissed, so there is no second location stream to keep in step with the map. A test asserts that all 1180 municipalities fall inside the region bounds, which is what actually validates the UTM-to-degrees conversion end to end. Verified on the emulator: the dropdown lists follow, region and both saved places; "aglie" finds Agliè; "44.3841 7.5426" offers the coordinate jump and lands on Cuneo at town-reading zoom; selecting follow moves the map to the device position with the blue dot on it and changes the recentre button to match. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Alby96andClaude Opus 5
|
75c4c55f81 |
Add VS Code run-and-debug configurations for the Android emulator
F5 now builds, installs and attaches the debugger on the emulator, with the emulator booted automatically first, so there is no manual setup step between opening the project and stepping through code. tool/start_emulator.ps1 backs the preLaunchTask and is idempotent: it returns in about three seconds when a device is already attached, so re-launching the debugger cannot stack emulator instances. It fails with a useful message when the AVD is missing rather than hanging until a timeout. Five configurations rather than one, because they answer different questions. The profile-mode entry matters most for what comes next: debug builds run the Dart VM unoptimised, so the radar animation always looks worse than it is, and milestone 3's acceptance criterion is about whether it runs smoothly. The Windows entry trades the map away for a launch that takes seconds, which is worth it for pure UI work. Verified on this machine: the script cold-boots the AVD and waits for sys.boot_completed, and a second run exits immediately. Also removes the broken pixel_7_-_api_35 AVD, which could not boot because its system image was never installed. That returned 4.8 GB, taking free disk from 3.5 GB to 10.7 GB. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
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> |
||
|
Alby96andClaude Opus 5
|
3fcbb9f1c4 |
Add monorepo scaffolding and project documentation
Sets up the Nuvolari monorepo layout (app/, backend/, docs/, tool/) with the groundwork that does not depend on the Flutter toolchain: gitignore covering Flutter, Python and every secret file shape; env.example.json as the template for --dart-define-from-file; a verification script that skips stages whose target does not exist yet so it is runnable from day one; and a CI workflow in GitHub Actions syntax so it runs unchanged on Gitea or GitHub. The documentation records facts verified against the live services rather than restated from the brief. Two of them change the design: - DPC VMI rasters are 1200x1400 Float32 on a 1 km grid in a custom projection centred on Italy, not EPSG:4326 or EPSG:3857, and their GeoKeys are internally inconsistent. Reprojection is mandatory and the source CRS must be read from each file rather than hardcoded. - The ARPA CAP feed carries six level values, not four: BIANCO for the avalanche scale out of season and "-" for no data. Collapsing either into VERDE would report "no alert" where the bulletin reports "not assessed". Also documents why the frames we publish inherit CC BY-SA from the DPC source, and why rain notifications subscribe to cell topics from the device so no user location ever reaches a server. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |