main
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  Alby96andClaude Opus 5
|
a686f7625e |
Mark the place the map is pointed at, and make following work
Choosing a town moved the camera and then left the reader to work out which of the settlements now on screen was the one they asked for. A town has no precise position, so the map now marks its centre: a white disc under a coloured dot, drawn as a style layer so the native renderer keeps it pinned through every pan and zoom. The radar frames are inserted below it, because a band of rain must not paint over the one thing that says which town this is. A searched municipality becomes a PointTarget rather than being thrown away as "the whole region". It is marked, the recentre button returns to it, and the chip names it - but it is never persisted, so looking something up no longer costs the user the place their app opens on. That was a real defect: searching went through select(FreeTarget), which wrote null over the stored preference. Following the device was broken outright. MapLibre reports a camera animation the app started exactly as it reports the user grabbing the map, so engaging follow and then animating to the position cancelled the follow it had just started; the resulting FreeTarget then re-framed the whole region. Follow now moves the camera first and switches tracking on second, and FreeTarget no longer moves the camera as a reaction to the state changing - framing the region is an action, so panning away while following keeps the view the user panned to. Verified on the emulator with a fix in Turin: a searched town is marked and saveable, the app reopens on it with the marker in place, following centres on the blue dot, and panning stops the chase without yanking the map away. 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
|
06ab816ebe |
Add saved places and optional device location
A saved place is a named point the user keeps: it frames the map now, and once the worker publishes station data it is what the nearest-station readings and, later, the rain notifications will hang off. Free points rather than stations, because people think in terms of home and work, not in terms of which weather station happens to represent them. Everything stays on the device. Places live in SharedPreferences under a versioned key, and there is no account to attach them to and no server that would accept them. That is what keeps the Data safety declaration able to say no location is collected, and it must survive the notification work: the device will subscribe to the topic for the cell containing a place, so the link between a person and a place never leaves their phone. Location is coarse only, and that took enforcing. geolocator declares ACCESS_FINE_LOCATION in its own manifest and the merger pulls it in, so the system dialog offered "Precise" despite the app asking for nothing of the sort; the manifest now removes it with tools:node="remove", and the dialog reads "approximate location" with no choice offered. Requests also go through the platform LocationManager rather than the Play Services fused provider, which prompts about Location Accuracy and, when declined, returns no fix at all — an absurd outcome for an app that only ever wanted an approximate one, and one that also tied location to Play Services being present. The prominent disclosure comes before the system dialog, as Play requires, and is repeated in Settings so someone who already answered can still read what the permission is for. Declining leaves the app fully usable. Two more defects found by running it and by a test: - MapLibreMap leaves cameraPosition null unless trackCameraPosition is set, so "save the map centre" silently saved the region default rather than what the user was looking at. - Place ids came straight from the microsecond clock, so two places saved in the same microsecond shared an id and rename, remove and the duplicate-name check all acted on the wrong one. A test caught it on a fast machine. Saving refuses points outside the region rather than accepting them: a place in Rome would look like it worked and then show nothing forever. Also corrects CLAUDE.md, which still said ARPA states no licence, and records the ARPA realtime API there with the property that governs how it may be used — it lags about 4.5 hours, so it is an observation archive and must never sit next to 5-minute radar looking current. Verified: analyze clean, 158 tests passing, and on the emulator the disclosure precedes the system dialog, the dialog asks only for approximate location, a place survives restart and reinstall, and tapping one moves the map onto it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |