Da Android 11 un'app vede le altre app installate solo se le dichiara in
<queries>. Senza l'intent IMAGE_CAPTURE, MediaPicker.CapturePhotoAsync non
trovava la fotocamera di sistema e falliva con "Either there was no camera
on the device or 'android.media.action.IMAGE_CAPTURE' was not added to the
<queries> element" (segnalato su Sentry).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Lo splash era rosa (#FDECEA) mentre l'app apre su #E9EDF2: a ogni avvio si
vedeva un lampo di colore prima della prima schermata. Ora e' la stessa
superficie, e il passaggio non si nota.
Il tema dello splash deriva da quello generato da MAUI e chiede le icone di
sistema scure, coerenti con lo sfondo chiaro. Su Android 12+ lo splash e'
disegnato dal sistema, che dell'attributo puo' non tenere conto: sul terminale
di prova le icone restano chiare per la frazione di secondo dello splash.
Marchio da 128 a 112: su 360 punti di larghezza riempiva troppo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Il salvataggio come bozza non e' mai scattato dal tasto indietro: la UI Blazor
non riceveva l'evento, e uscire da un form con modifiche in corso buttava via
il lavoro esattamente come prima che la bozza esistesse.
Il back non arrivava a OnBackPressed per due motivi diversi:
- da AndroidX Activity 1.6 il gesto passa dall'OnBackPressedDispatcher e il
metodo dell'Activity non viene piu' invocato;
- con la navigazione a tre tasti il back arriva come evento di tastiera e la
WebView lo intercetta per conto suo, tornando indietro nella propria
cronologia, prima che Activity o dispatcher lo vedano.
Ora la chiave si ferma in DispatchKeyEvent, che passa prima della gerarchia di
view, e resta un callback sul dispatcher per la navigazione a gesti, dove
evento di tastiera non ce n'e'. Entrambi restano accesi solo finche' la UI ha
davvero qualcosa da dire: altrimenti il back si comporta come sempre.
I gestori diventano una pila, cosi' sopra il form puo' aprirsi un bottom sheet
e il back chiude prima quello senza portarsi via la registrazione sottostante.
ActionSheet si registra da solo mentre e' aperto.
Verificato sull'EDA52: back sul form con modifiche apre "Lavoro non salvato" e
salva la bozza; back sullo sheet chiude solo lo sheet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Prime correzioni fatte guardando l'app su un Honeywell EDA52 (720x1440
@320dpi, cioe' 360 punti logici di larghezza) invece che a occhio.
- Barra di stato: era tinta di corallo da colorPrimaryDark, cioe' l'accento
usato come decorazione della cornice di sistema. Ora si fonde con lo
sfondo dell'app, con icone scure (WindowInsetsController).
- Gradino compatto sotto i 380px: la scala di STILE_UI e' tarata su telefoni
piu' larghi, e a misura piena i titoli si troncavano e in una schermata
entrava pochissimo lavoro. Le proporzioni restano, cambia la taglia.
Sui telefoni normali non cambia nulla.
- Icone delle azioni costruttive: usavano il fondo del tono danger, quindi
"Nuova scheda" e "Aggiungi una foto" erano identiche a "Elimina
ispezione". Ora usano il tono info. Un --primary-surface non risolveva:
il primario di SteUP e' gia' un rosso, quindi un suo fondo tenue resta
indistinguibile da quello danger.
- Testata: il titolo puo' andare su due righe prima di troncare. Il nome del
punto vendita e' l'ancora del compito, "D11-PRIMO PREZ..." non aiuta.
- Schermata ispezione: il nome del punto vendita non e' piu' ripetuto nel
pannello di riepilogo, dove era gia' in testata.
- Padding dei gruppi di form e della barra azioni ridotti su schermo stretto.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Honeywell emette BarcodeFailureEvent anche solo premendo e rilasciando il
trigger senza inquadrare nulla: e' la normale mancata lettura, non un
guasto. Finiva pero' in OnScanFailed insieme ai guasti veri, quindi ogni
pressione a vuoto fermava il rilevatore con un dialog bloccante contenente
il toString() Java grezzo:
Scan failure: com.honeywell.aidc.BarcodeFailureEvent[source=...]
Ora l'evento e' ignorato: chi preme il trigger sa gia' di non aver letto
niente, non serve alcun riscontro. OnScanFailed resta riservato ai guasti
reali (ScannerUnavailableException alla Claim, init di AidcManager fallito).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Uscendo da una scheda a meta' (tasto indietro del dispositivo o "Annulla")
il lavoro veniva scartato. Il tasto indietro non era nemmeno gestito: non
arriva alla WebView e non c'e' stack di navigazione, quindi mandava l'app
in background con i dati solo in memoria.
Nuovo stato Bozza ("Da completare"): salvata in locale, mai inviabile
finche' non viene conclusa.
- Scheda.Bozza + migration additiva (default false: le schede esistenti
non cambiano stato).
- SchedaSyncHelper: terzo SyncState, CountBozze(). CountDaInviare()
esclude le bozze, quindi il badge "da inviare" resta corretto.
- ModalFormScheda: SaveDraft() salva solo in locale senza validazione;
Save() azzera il flag; Submit() avvisa quando il form e' invalido
(prima il tocco su "Salva" sembrava non fare nulla se i campi mancanti
erano fuori schermo); Update() prende preserveActivityId cosi' una
bozza di scheda gia' inviata mantiene il link al server e al
completamento lo aggiorna invece di duplicarlo.
- ConfirmUpdateActivity: il pulsante bozza sta su NoText, non CancelText
(CancelText ritorna null, NoText ritorna false).
- BackButtonService + MainActivity.OnBackPressed: il tasto indietro passa
dallo stesso percorso di "Annulla". Ignorato mentre e' aperto un dialog
figlio, per non mostrare il prompt sotto un altro dialog.
- IspezionePage: "Concludi ispezione" si blocca se ci sono bozze,
"Esporta reparto" le salta, chip "N da completare" per reparto.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Da Android 15 (API 35+) l'edge-to-edge e' forzato e adjustResize non
ridimensiona piu' la finestra: la tastiera si limita a coprire la
BlazorWebView. Con il layout rigido (html overflow:hidden, #app 100vh,
page/main height:100% overflow:hidden) nemmeno il browser riesce a
portare in vista il campo col focus.
- MainActivity: WindowSoftInputMode AdjustResize|StateHidden e listener
sugli WindowInsets che applica al content view il padding bottom pari
all'inset IME (meno quello delle system bars, gia' coperto da
SafeAreaEdges in MainPage), cosi' il 100vh si ricalcola.
- main.js: su focusin e visualViewport resize porta il campo attivo al
centro con scrollIntoView, necessario per i contenitori scrollabili.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
MarcoEandClaude Opus 5.5