Diversi eventi, alcuni attivati dall'utente e altri dal sistema, possono causare la transizione di un
Activity da uno stato all'altro. Questo documento descrive
alcuni casi comuni in cui si verificano queste transizioni e come gestirle.
Per maggiori informazioni sugli stati delle attività, consulta Il ciclo di vita delle attività. Per
scoprire in che modo la classe ViewModel può aiutarti a gestire il ciclo di vita dell'attività, consulta la panoramica di ViewModel.
Per la maggior parte delle modifiche all'attività, non è necessario rispondere direttamente ai callback nel ciclo di vita dell'attività. Poiché Compose ricompone le UI dallo stato, puoi sfruttare la ricomposizione automatica assicurandoti che lo stato sia archiviato in una posizione appropriata, ad esempio rememberSaveable o ViewModel.
Si verifica una modifica della configurazione
Esistono diversi eventi che possono attivare una modifica della configurazione. Forse l'esempio più evidente è il passaggio dall'orientamento verticale a quello orizzontale e viceversa. Altri casi che possono causare modifiche alla configurazione includono modifiche alle impostazioni della lingua o al dispositivo di input.
Quando si verifica una modifica alla configurazione, l'attività viene eliminata e ricreata. Vengono attivati i seguenti callback nell'istanza dell'attività originale:
Viene creata una nuova istanza dell'attività e vengono attivati i seguenti callback:
In Compose, non è normale interagire direttamente con questi callback. In alternativa,
utilizza l'API Lifecycle per osservare le modifiche di stato. In Compose, puoi utilizzare
LocalLifecycleOwner.current per ottenere il ciclo di vita corrente e aggiungere un
observer, che ti consente di rispondere agli eventi.
Utilizza una combinazione di istanze ViewModel, rememberSaveable o spazio di archiviazione locale persistente per conservare lo stato dell'interfaccia utente di un'attività in seguito a modifiche alla configurazione.
Decidere come combinare queste opzioni dipende dalla complessità dei dati dell'interfaccia utente,
dai casi d'uso della tua app e dalla considerazione della velocità di recupero rispetto
alla memoria utilizzata. Per la maggior parte dei casi d'uso, devi sollevare lo stato in un ViewModel e
utilizzare rememberSaveable per garantire che lo stato venga mantenuto sia durante le modifiche alla configurazione
sia durante l'interruzione del processo avviata dal sistema. Per saperne di più sul salvataggio
dello stato dell'interfaccia utente dell'attività, vedi Salvataggio degli stati dell'interfaccia utente.
Quando un'attività viene ricreata a causa di una modifica alla configurazione, la composizione iniziale viene eliminata. L'utilizzo di ViewModel o rememberSaveable garantisce il ripristino dello stato dell'interfaccia utente nella nuova composizione.
Per saperne di più, consulta Ciclo di vita in Jetpack Compose e Stato e Jetpack Compose.
Gestire i casi multi-finestra
Quando un'app entra in modalità multi-finestra, disponibile su Android 7.0 (livello API 24) e versioni successive, il sistema notifica all'attività in esecuzione una modifica alla configurazione, passando così attraverso le transizioni del ciclo di vita descritte in precedenza.
Questo comportamento si verifica anche se viene ridimensionata un'app già in modalità multi-finestra. La tua attività può gestire autonomamente la modifica della configurazione oppure può consentire al sistema di distruggerla e ricrearla con le nuove dimensioni.
Per saperne di più sul ciclo di vita della funzionalità Multi-finestra, consulta la spiegazione del ciclo di vita della funzionalità Multi-finestra nella sezione Supportare la modalità Multi-finestra.
In modalità multi-finestra, anche se l'utente vede due app, solo quella con cui sta interagendo è in primo piano e ha il focus. L'attività è nello stato Ripresa, mentre l'app nell'altra finestra è nello stato In pausa.
Quando l'utente passa dall'app A all'app B, il sistema chiama onPause sull'app A e onResume sull'app B. Passa da un metodo all'altro
ogni volta che l'utente passa da un'app all'altra.
Per maggiori dettagli sulla modalità Multi-finestra, consulta Supporto della modalità Multi-finestra.
Attività o finestra di dialogo in primo piano
Se una nuova attività o una nuova finestra di dialogo viene visualizzata in primo piano, prendendo il focus e
coprendo parzialmente l'attività in corso, l'attività coperta perde il focus
e passa allo stato In pausa. Poi, il sistema chiama onPause.
Quando l'attività coperta torna in primo piano e riacquista lo stato attivo, il
sistema chiama onResume.
Se una nuova attività o una nuova finestra di dialogo viene visualizzata in primo piano, prendendo il focus e
coprendo completamente l'attività in corso, l'attività coperta perde il focus
e passa allo stato Interrotto. Il sistema chiama quindi, in rapida successione, onPause e onStop.
Quando la stessa istanza dell'attività coperta torna in primo piano, il
sistema chiama onRestart, onStart e onResume sull'attività. Se si tratta di una nuova istanza dell'attività coperta che passa in background, il sistema non chiama onRestart, ma solo onStart e onResume.
La ricomposizione non è interessata dalle finestre di dialogo visualizzate in primo piano. Tuttavia,
gli effetti collaterali legati al ciclo di vita, come flussi e animazioni, devono utilizzare
API sensibili al ciclo di vita (come collectAsStateWithLifecycle) per
mettere in pausa e riprendere automaticamente il lavoro in base alle necessità. Per saperne di più, consulta State
e Jetpack Compose.
L'utente tocca o esegue il gesto Indietro
Se un'attività è in primo piano e l'utente tocca o esegue un gesto Indietro, l'attività passa attraverso i callback onPause, onStop e onDestroy. L'attività viene eliminata e rimossa dallo
stack precedente.
In un'app con una sola attività, come la maggior parte delle app Compose, rememberSaveable non
manterrà lo stato se il composable viene rimosso dallo stack di navigazione. Questo
perché, quando l'utente tocca Indietro, non si aspetta di
tornare alla stessa istanza, quindi tutto lo stato viene cancellato.
Per implementare un comportamento personalizzato del pulsante Indietro, ad esempio visualizzare una finestra di dialogo che chiede all'utente di confermare che vuole uscire dall'app, utilizza l'API NavigationEventHandler.
Il sistema termina il processo dell'app
Se un'app è in background e il sistema deve liberare memoria per un'app in primo piano, il sistema può chiudere l'app in background. Quando il sistema chiude un'app, non è garantito che onDestroy venga chiamato nell'app.
Per scoprire di più su come il sistema decide quali processi eliminare, leggi Stato dell'attività ed espulsione dalla memoria e Ciclo di vita di processi e app.
Per scoprire come salvare lo stato dell'interfaccia utente dell'attività quando il sistema termina il processo dell'app, consulta Salvataggio e ripristino dello stato dell'interfaccia utente temporaneo.