f434a68155aabf2f0c30163ec9faa29ec4323e0a
19
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
|
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> |
||
|
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> |
||
|
Alby96andClaude Opus 5
|
e14308bbb6 |
Survey the ARPA REST APIs and correct the licence position
Scanned the two public ARPA Piemonte APIs and recorded what they actually contain, so this question does not get re-litigated from the marketing pages later. Neither needs a key, a token or a registration. This corrects something I got wrong. The docs said ARPA states no licence for its data, based on the open-data page saying only "gratuiti". The site's legal notice does state one — CC BY 4.0, commercial use explicitly permitted, credit "Fonte: Arpa Piemonte - www.arpa.piemonte.it" — and both APIs link that notice from their OpenAPI description, so anything they serve is covered. Only the radar volumes remain ambiguous, because their own page does not repeat the licence and the access link is still issued by email; both questions belong in the same message to ARPA. The survey's operative findings: - api_realtime carries 374 stations with coordinates, of which 286 have a rain gauge, spanning 74 m to 2820 m of elevation. - Its observations lag by about 4.5 hours on an hourly cadence, measured uniformly across every station sampled. That is the property that decides how it can be used: it is an observation archive with a publishing delay, not a real-time feed, and it must never sit next to 5-minute radar looking current. - Only 4 of 143 hydrometer stations publish guard and danger thresholds, and 5 publish a river name. A river-level warning built on this would be empty for 97% of stations, so that idea is recorded as rejected rather than pending. - Meteoweb is a 3.27-million-record historical archive plus a seismic catalogue: a research dataset, not app content. One thing is worth adopting: rain-gauge accumulations as ground truth for the radar. Radar infers rainfall from reflectivity aloft, gauges measure what reached the ground, and the network is densest exactly where Alpine terrain blocks the beam. It belongs behind the worker, clearly timestamped, once the worker exists. Also notes that the credit ARPA asks for is the full "Fonte: Arpa Piemonte - www.arpa.piemonte.it", not the bare name currently in the region config, to be adopted the moment any ARPA-sourced data is displayed. No code changes: nothing is integrated yet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Alby96andClaude Opus 5
|
f3a0e3794a |
Narrow scope to radar, and put the app on a real OpenStreetMap base map
Drops forecasts, lightning, the home-screen widget and advertising. What remains is radar on a map, the official ARPA alert bulletin, and rain notifications. The base map is now OpenFreeMap's Positron style: real OpenStreetMap vector tiles with no API key, no registration, no request limits and commercial use permitted. Every other free tier — MapTiler, Stadia, Jawg, Thunderforest — needs a key, which is a secret to manage, a quota to outgrow and a signup to complete before anyone can build the project, and the map is the one thing the app cannot work without. Positron rather than Liberty or Bright because the radar overlay has to be the loudest thing on screen, and a desaturated grey base is built to sit under data. Its style JSON carries no `attribution` field, so MapLibre displays no credits by itself. The app renders them from the region config instead: the two mandatory credits, OpenStreetMap and OpenMapTiles, go in the always-visible bar, and OpenFreeMap's own credit — optional by their terms — is listed on the Sources screen with the rest. The bundled offline style is still reachable with MAP_STYLE_URL=offline, and still claims no base map attribution, because crediting OpenStreetMap while showing it would be a false claim. Radar-DPC stays the source. ARPA Piemonte's own radar remains a disabled stub for two reasons that belong to the project owner, not to the code: the real-time access link is only issued by email, and the open-data page states the data is "gratuiti" and nothing else. Free of charge is not a licence, and rendering those volumes into frames served from a CDN is redistribution. Both questions go in the same email. An earlier draft of the docs recorded ARPA radar as CC BY 4.0; the source page does not support that, so the claim is removed rather than carried forward. The documentation is updated throughout rather than annotated: CLAUDE.md gains an explicit scope boundary, data-sources drops MET Norway and ISTAT and gains the base map, licenses records that free of charge is not a licence, privacy loses the whole advertising section, and the roadmap is renumbered so the backend worker is next — until it exists, DpcRadarSource has nothing to read. licenses.md keeps Open-Meteo and Blitzortung listed as excluded even though the features that would have used them are gone: both are non-commercial-only, ads are a plausible future, and neither should be adopted on the grounds that there are none today. Verified: analyze clean, 130 tests passing, and on the emulator the radar overlay sits correctly over Piedmont on real OSM tiles with Turin, Milan and Genoa labelled, the age reads "Aggiornato 4 minuti fa", and the Sources screen lists all five credits with their licences. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
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> |
||
|
Alby96andClaude Opus 5
|
8ff8a903b8 |
Document the VS Code debug configurations in the README
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
|
7c0a1bd180 |
Disable emulator quickboot snapshots
The AVD's quickboot snapshot had grown to 2.6 GB, which took this machine down to 1.4 GB free. Saving a minute of boot time is not worth that here, so cold boot is now the default and the snapshot directory is gone. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Alby96andClaude Opus 5
|
47049b39e7 |
Fit the map to the region and keep attribution clear of the gesture bar
Running the app on an emulator for the first time showed two problems that the unit tests could not have caught, because both are about what the pixels actually do. The configured initial zoom of 7.2 puts the viewport entirely inside the region on a 411dp-wide screen, so the map rendered as a flat expanse of fill colour with no outline, border or reference point anywhere in view — it read as a failure to load. A single zoom number cannot frame a region on both a phone and a tablet, so the camera now fits the region bounds once the map is ready, which is correct at any screen size. The configured zoom stays as the starting position before the fit. The attribution bar sat behind the system gesture pill. A credit that is covered by the navigation bar is a credit that is not being displayed, which is the thing ODbL and CC BY-SA actually require, so it now sits inside a SafeArea. Also records how to run and screenshot the app on the `nuvolari` AVD, and notes the pre-existing broken `pixel_7_-_api_35` AVD that is holding 4.8 GB. Verified on the emulator: the region outline is framed with margin, the attribution bar is clear of the pill, and the Sources screen shows the disclaimer, all four credits with their licences, the "no licence stated" line for ARPA and the share-alike note. 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
|
4142b67a8d |
Record why the Android NDK is required
Hiding the NDK and rebuilding showed the build fails without it, and the reason is not obvious from this repository: maplibre_gl pins ndkVersion 28.2.13676358 in its own build file, and AGP needs every module to agree on one NDK. The app has no native sources and no Dart FFI, so the declaration reads like dead configuration and invites exactly the deletion that was just tried. Costs about 2 GB of Android SDK. Notes the full toolchain disk budget in the README as well, since a warm Gradle cache plus build output pushes the total to roughly 14 GB. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Alby96andClaude Opus 5
|
d84095b5a8 |
Add the region map, permanent attribution and the Sources screen
Puts a MapLibre map on screen framed on the region, with the credit obligations that come with showing third-party data satisfied structurally rather than by remembering to add a label. The base map style comes from MAP_STYLE_URL, and with no key configured the app generates a fallback style from the region's own bounding box: a flat background and the extent outline, no network sources at all. That keeps a fresh clone runnable offline without pulling in a boundary dataset that would carry its own licence, and it deliberately looks like a placeholder so it is not mistaken for a finished map. Attribution is driven by what is actually rendered. The bar lists the credits for the active sources only, because crediting OpenStreetMap while showing the fallback style would be a false attribution, and it says plainly when no base map is configured. It sits below the map rather than floating over it so no map control or gesture overlay can occlude a credit that the ODbL and CC BY-SA terms require to be visible. The Sources screen leads with the independence disclaimer, before the sources it qualifies, so a reader who stops after the first screenful has still seen it. Sources with no stated licence — ARPA publishes none for the alert bulletin — say so explicitly rather than being shown bare or given an invented one. A separate note explains that the rendered radar frames inherit CC BY-SA from the DPC source data. Also declares the INTERNET permission in the main manifest: Flutter injects it into the debug and profile manifests only, so a release build would otherwise fail every request on device. Verified: analyze clean, 66 tests passing, appbundle builds with the native MapLibre plugin. Not verified visually — this machine has no Android device or emulator image, so nobody has watched the map render. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Alby96andClaude Opus 5
|
85b2c99949 |
Scaffold the Flutter app with Italian l10n and region configuration
Creates the app skeleton and the seam everything else in the project hangs off: region-specific data lives in an asset file, not in code, so adding a region later is a new JSON file rather than a refactor. Notable choices: - applicationId and namespace are it.nuvolari.app rather than the doubled it.nuvolari.nuvolari that `flutter create` produces, with the Kotlin package and the iOS bundle identifiers moved to match. - SDK levels are pinned instead of inherited from `flutter.*`. Google Play requires API 36, and that is a release blocker rather than something to let a Flutter upgrade change silently. minSdk 24 is the highest floor the planned dependencies impose. - Riverpod and Dio-free for now, no code generation: see docs/stack-decisions.md. - Italian is the l10n source language, so app_it.arb is the template rather than a translation of an English original. The region parser rejects rather than repairs. An inverted bounding box, a map centre outside its own bounds, an unknown adapter name, a duplicate zone code or an empty attribution list all throw with the offending field named. Each of those would otherwise fail silently and visibly wrong: a swapped latitude and longitude renders the radar in the wrong place, an unknown adapter falling back to mock would show demo frames where live data was expected, and a missing attribution is a licence violation rather than a cosmetic gap. Tests run against the asset that actually ships and against a captured copy of the live ARPA CAP feed, so the eleven zone codes in the config are checked against the eleven the feed really emits rather than against a list retyped from documentation. Verified: dart format clean, flutter analyze 0 issues, 50 tests passing, flutter build appbundle --debug produces an AAB with applicationId it.nuvolari.app, minSdk 24, targetSdk 36. 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> |
||
|
Alby96andClaude Opus 5
|
3b0fce2516 |
Drop Xamarin skeleton and add project guidelines
The Nuvolari app is being rebuilt as a Flutter project targeting Android first and iOS later on a single codebase, so the original Xamarin.Android skeleton no longer applies. Its files were already removed from the working tree; this records the removal. Adds CLAUDE.md with the golden rules that constrain the rewrite: English code and commit messages with Italian UI via ARB, no secrets in the repo, AdMob test IDs only, no direct polling of ARPA/DPC from the app, and no server-side precise user locations. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Alby96
|
7a45880059 |
Aggiunta configurazione base per l'app Android
Implementate le configurazioni iniziali in `AndroidManifest.xml` e `Nuvolari.csproj`. Creata la classe `MainActivity` per gestire la mappa con `SearchView` per la ricerca di luoghi. Definiti i layout in `activity_main.axml` e `activity_main.xml`. Aggiunti file di risorse per le icone dell'app e creato `ic_launcher_background.xml` per il colore di sfondo. Definiti i testi dell'app in `strings.xml`. |
||
|
Alby96
|
3d482329d0 | Initial commit |