Eventi diversi, alcuni attivati dall'utente e altri attivati dal sistema, possono causare la transizione di un elemento Activity da uno stato all'altro. Questo documento descrive alcuni casi comuni in cui si verificano queste transizioni e come gestirle.
Per ulteriori informazioni sugli stati delle attività, vedi Il ciclo di vita dell'attività. Per scoprire in che modo il corso ViewModel può aiutarti a gestire il ciclo di vita dell'attività, consulta la panoramica di ViewModel.
Si è verificata una modifica della configurazione
Esistono una serie di eventi che possono attivare una modifica della configurazione. Forse l'esempio più evidente è un cambiamento tra l'orientamento verticale e quello orizzontale. Altri casi che possono causare modifiche alla configurazione sono le modifiche alle impostazioni della lingua o al dispositivo di input.
Quando si verifica una modifica alla configurazione, l'attività viene eliminata e ricreata. Questo attiva i seguenti callback nell'istanza originale dell'attività:
Viene creata una nuova istanza dell'attività e vengono attivati i seguenti callback:
Utilizza una combinazione di istanze ViewModel, metodo onSaveInstanceState() o archiviazione locale permanente per preservare lo stato dell'interfaccia utente di un'attività in caso di modifiche alla configurazione. La scelta della combinazione di queste opzioni dipende dalla complessità dei dati dell'interfaccia utente, dai casi d'uso della tua app e dalla considerazione tra la velocità di recupero e l'utilizzo della memoria. Per ulteriori informazioni sul salvataggio dello stato dell'interfaccia utente delle attività, consulta
Salvare gli stati dell'interfaccia utente.
Gestire le richieste multi-finestra
Quando un'app entra in modalità multi-finestra, disponibile su Android 7.0 (livello API 24) e versioni successive, il sistema notifica l'attività in corso di una modifica alla configurazione, attraversando così le transizioni del ciclo di vita descritte in precedenza.
Questo comportamento si verifica anche se un'app già in modalità multi-finestra viene ridimensionata. L'attività può gestire autonomamente la modifica della configurazione o consentire al sistema di eliminare l'attività e ricrearla con le nuove dimensioni.
Per ulteriori informazioni sul ciclo di vita multi-finestra, consulta la spiegazione del ciclo di vita multi-finestra nella pagina Supporto multi-finestra.
Anche se in modalità multi-finestra sono due app visibili all'utente, solo quella con cui l'utente sta interagendo è in primo piano ed è attiva. L'attività è in stato Ripresa, mentre l'app nell'altra finestra è in stato In pausa.
Quando l'utente passa dall'app A all'app B, il sistema chiama
onPause() l'app A e
onResume() l'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 multi-finestra.
L'attività o la finestra di dialogo appare in primo piano
Se una nuova attività o finestra di dialogo viene visualizzata in primo piano, con lo stato attivo e copre parzialmente l'attività in corso, l'attività coperta perde lo stato attivo ed entra nello stato In pausa. Quindi, il sistema chiama
onPause().
Quando l'attività coperta torna in primo piano e viene nuovamente evidenziata, il sistema chiama onResume().
Se una nuova attività o finestra di dialogo viene visualizzata in primo piano, con lo stato attivo e
copre completamente l'attività in corso, l'attività coperta perde lo stato attivo
ed entra nello stato Arrestata. Il sistema quindi, in rapida successione, chiama
onPause() e onStop().
Quando la stessa istanza dell'attività coperta torna in primo piano, il sistema chiama onRestart(), onStart() e onResume() per l'attività. Se
si tratta di una nuova istanza dell'attività coperta in background, il
sistema non chiama onRestart(), ma solo
onStart() e onResume().
L'utente tocca o fa gesti Indietro
Se un'attività è in primo piano e l'utente tocca o fa un gesto Indietro, l'attività passa attraverso i callback onPause(), onStop() e onDestroy(). L'attività viene distrutta e rimossa dallo stack posteriore.
Per impostazione predefinita, il callback onSaveInstanceState() non viene attivato in questo caso. Questo comportamento presuppone che l'utente tocchi Indietro senza aspettarsi di tornare alla stessa istanza dell'attività.
Tuttavia, puoi eseguire l'override del metodo onBackPressed() per implementare un comportamento personalizzato, ad esempio la visualizzazione di una finestra di dialogo che chiede all'utente di confermare l'uscita dall'app.
Se esegui l'override del metodo onBackPressed(), ti consigliamo vivamente di richiamare super.onBackPressed() dal metodo di override. In caso contrario, il comportamento Indietro del sistema potrebbe essere fastidioso per l'utente.
Il sistema termina il processo dell'app
Se un'app è in background e il sistema deve liberare memoria per un'app in primo piano, può terminare l'app in background. Quando il sistema termina un'app, non è garantito che l'app onDestroy() venga chiamata nell'app.
Per scoprire di più su come il sistema decide quali processi eliminare, leggi Stato dell'attività ed espulsione dalla memoria e Processi e ciclo di vita delle app.
Per informazioni su 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.