aa91b457ed5cea36883496d54a3e144427840f20
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
aa91b457ed |
Give the map the whole screen and move the credits into settings
Drops the app bar, moves settings onto the map with the other controls, and takes the attribution bar off the main screen. The app bar held only the app name — which the launcher already shows — and one action, so removing it hands its height to the map rather than leaving an empty strip. The settings button joins search and recentre in the column over the map, where the rest of the controls that act on the map already live. The attribution needed checking before it could move, because it is a licence obligation rather than a layout choice. The OSMF guidelines settle it: for a browsable map the credit does not have to be permanently visible, provided "the user must still be able to find the licence information if they look for it, for example from an '(i)' button in the corner of the map or an 'About' option in a menu". Map to settings to "Fonti e licenze" is exactly that, and MapLibre's own (i) control now sits in the map's top-right corner as a second route — it had been landing underneath the new button column. Two things had to follow the bar rather than disappear with it. The radar manifest carries its own credit for the frames on screen, set by whoever published them and absent from the region config, so the Sources screen now shows it alongside the configured attributions. And the settings entry that leads there carries a subtitle saying what it holds, because "Fonti e licenze" alone does not tell a reader that this is where the licence information went. settings_screen_test asserts that entry exists and opens the screen. Removing it would be a licence breach, so it should fail the build rather than ship quietly. Verified on the emulator: no title bar, the map runs to the top with the demo notice above it, the three controls stack bottom-right without colliding with the (i), and settings shows the sources entry with its subtitle. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
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> |