onRestart — ripristino di Activity nel ciclo di vita

onRestart — l'essenza del metodo nel ciclo di vita Android

onRestart — un metodo di callback che Android chiama rigorosamente prima di onStart quando un'Activity torna dallo stato invisibile Stopped a essere visibile. Questo metodo è unico perché viene chiamato solo quando l'Activity viene mostrata di nuovo — durante la prima creazione dell'istanza, la sequenza inizia con onCreate, saltando onRestart. Il ciclo completo: onCreate → onStart → onResume (primo avvio) o onRestart → onStart → onResume (visualizzazione successiva).

Dal punto di vista del sistema Android, onRestart è un'ottimizzazione che consente all'Activity di prepararsi al suo ritorno: aggiornare i dati dal repository, sincronizzare lo stato dell'UI, verificare la connettività di rete. A differenza di onResume, che viene chiamato ogni volta che l'Activity ottiene il focus (incluso quando si torna da un dialogo o menu di sistema), onRestart viene attivato solo durante un ciclo completo di occultamento e ritorno. Questo rende onRestart il luogo ideale per operazioni di aggiornamento “pesanti” che non sono necessarie durante una perdita parziale di focus.

Secondo la specifica del ciclo di vita dell'Activity Android, l'intervallo di tempo tra onStop e onRestart può variare da pochi secondi (l'utente ha cambiato rapidamente) a diverse ore (l'app era in background e l'utente è tornato). Durante questo periodo, i dati in una fonte remota (API, DB) potrebbero essere cambiati, quindi onRestart è un punto naturale per verificare l'attualità.

Quando viene chiamato onRestart: condizioni e sequenza

onRestart viene chiamato solo quando un'Activity torna dallo stato Stopped, in cui l'Activity è entrata dopo che onStop è stato chiamato. Di seguito sono elencati tutti gli scenari che portano a onRestart.

Scenari di invocazione di onRestart:

• Ritorno da un'altra Activity — l'utente ha aperto una nuova Activity (ad esempio, ha toccato una notifica) e poi è tornato indietro (ha premuto “Indietro”). Stack: MainActivity.onPause → MainActivity.onStop → SecondActivity viene creata → l'utente preme “Indietro” → SecondActivity.onPause → SecondActivity.onStop → SecondActivity.onDestroy → MainActivity.onRestart → MainActivity.onStart → MainActivity.onResume.
• Ritorno dalla minimizzazione — l'utente ha minimizzato l'app (Home) e dopo un po' di tempo è tornato. CurrentActivity.onPause → CurrentActivity.onStop → (app in background) → l'utente torna → CurrentActivity.onRestart → CurrentActivity.onStart → CurrentActivity.onResume.
• Ritorno dalla schermata di blocco — la schermata di blocco copre l'Activity; dopo lo sblocco, l'Activity riceve onRestart se è trascorso un tempo significativo (più di 5 secondi).
• Ritorno da un'app avviata tramite Intent — fotocamera, galleria, browser — qualsiasi app di terze parti avviata tramite startActivityForResult() o ActivityResultLauncher.

Quando onRestart NON viene chiamato: durante la rotazione dello schermo (l'Activity viene distrutta e ricreata tramite onCreate), quando si torna da una finestra di dialogo (l'Activity non entra in onStop, solo onPause → onResume), durante la morte del processo (l'Activity viene ricreata).

onRestart vs onCreate: quale scegliere

onRestart e onCreate sono due approcci diversi per ripristinare un'Activity. La scelta tra di essi dipende dal fatto che l'Activity sia stata completamente distrutta o semplicemente nascosta.

Regola di selezione: esegui l'inizializzazione della View e la sottoscrizione a LiveData/StateFlow in onCreate (o onViewCreated per Fragment). Aggiornamenti dati, ricaricamento liste e controlli di stato — in onRestart. Se i dati vengono caricati tramite ViewModel, onRestart può semplicemente chiamare il metodo refresh() sul ViewModel, e la View si sottoscriverà ai dati aggiornati attraverso un flusso reattivo.

Google raccomanda: non duplicare la logica di onCreate in onRestart. Estrai i metodi refresh() in ViewModel che caricano i dati correnti e chiamali in onRestart. Questo preserva un'architettura MVVM pulita ed elimina la duplicazione del codice.

Casi d'uso di onRestart: aggiornamento dati e UI

onRestart è il luogo ideale per le operazioni che dovrebbero essere eseguite ogni volta che si torna alla schermata, ma non sono necessarie alla prima apertura. Ecco gli scenari tipici:

• Aggiornare una lista dal DB o API — l'utente è andato in un'altra Activity, ha modificato i dati lì, è tornato — la lista deve essere aggiornata. Chiama viewModel.refreshItems() in onRestart.
• Controllo di autorizzazione — se l'Activity è stata nascosta per molto tempo, il token di accesso potrebbe essere scaduto. onRestart è il punto per verificare la validità del token e reindirizzare alla schermata di login.
• Sincronizzazione dello stato dell'UI — cambio tema, cambio lingua, aggiornamento impostazioni — le modifiche dovrebbero essere applicate al ritorno alla schermata.
• Ricarica multimediale — se l'Activity mostra contenuti che potrebbero essere cambiati (feed di notizie, tassi di cambio, meteo), aggiorna i dati in onRestart.
• Controllo della connettività di rete — quando si torna dalla modalità offline, l'Activity dovrebbe verificare la disponibilità della rete e commutare l'UI.
• Ripristino animazioni — le animazioni rilasciate in onStop dovrebbero essere riavviate in onRestart prima di onStart.

Cosa NON fare in onRestart: non reinizializzare le View — sono vive perché l'Activity non è stata distrutta. Non ri-sottoscriverti a LiveData — la sottoscrizione in onCreate è ancora viva. Non creare nuovi Fragment — sono già nel FragmentManager.

onRestart e morte del processo: un'eccezione importante

L'eccezione più importante: onRestart non viene chiamato se il processo dell'app è stato ucciso dal sistema. Questo è un punto chiave che gli sviluppatori spesso trascurano quando fanno affidamento su onRestart per il ripristino dello stato.

Durante la morte del processo:

• L'app era in background, Android ha ucciso il processo per liberare memoria.
• L'utente torna — il sistema avvia un nuovo processo.
• L'Activity viene ricreata: onCreate(Bundle) → onStart → onResume.
• onRestart NON viene chiamato — per il sistema, questa è una nuova istanza di Activity.

Come proteggersi: salva sempre lo stato critico in onSaveInstanceState(Bundle) (chiamato prima di onStop) o usa SavedStateHandle in ViewModel. In onCreate, controlla savedInstanceState: se non è null, ripristina lo stato dal Bundle; se è null, carica dati freschi.

Secondo Google Android Vitals, circa il 7% dei ritorni a un'Activity dopo un lungo periodo in background avviene dopo la morte del processo. Ciò significa che ogni 15ª Activity che avrebbe dovuto chiamare onRestart, in realtà passa attraverso onCreate. Ignorare questo scenario è una delle cause principali di bug di “schermata vuota dopo il ritorno”.

Esempi di codice con onRestart in Kotlin

Esempio 1: onRestart con aggiornamento della lista tramite ViewModel

L'Activity chiama viewModel.refreshTasks() in onRestart per aggiornare la lista dei compiti dopo essere tornata dalla schermata di modifica.

class TaskListActivity : AppCompatActivity() {
    private val viewModel: TaskViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_task_list)
        viewModel.tasks.observe(this) { tasks ->
            Log.d("TaskList", "Ricevuti ${tasks.size} compiti")
        }
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("TaskList", "onRestart: aggiornamento elenco compiti")
        viewModel.refreshTasks()
    }
}

class TaskViewModel : ViewModel() {
    private val _tasks = MutableLiveData<List<Task>>()
    val tasks: LiveData<List<Task>> get() = _tasks

    fun refreshTasks() {
        viewModelScope.launch {
            _tasks.value = TaskRepository().getAllTasks()
        }
    }
}

ViewModel.refreshTasks() carica i dati correnti dal repository. LiveData notifica automaticamente l'Activity dei cambiamenti dei dati — l'UI si aggiorna senza codice aggiuntivo. onRestart non crea una nuova sottoscrizione — è già stata impostata in onCreate.

Esempio 2: onRestart con controllo di autorizzazione

L'Activity controlla la validità del token al ritorno e reindirizza al login se necessario.

class ProfileActivity : AppCompatActivity() {
    private val authManager = AuthManager()
    private val launcher = registerForActivityResult(
        ActivityResultContracts.StartActivityForResult()
    ) { Log.d("Profile", "Ritornato dalla schermata di login") }

    override fun onRestart() {
        super.onRestart()
        if (!authManager.isTokenValid()) {
            Log.d("Profile", "Token scaduto — reindirizzamento al login")
            launcher.launch(Intent(this, LoginActivity::class.java))
        }
    }
}

class AuthManager {
    fun isTokenValid(): Boolean {
        val expiry = SharedPreferencesManager().getTokenExpiry()
        return System.currentTimeMillis() < expiry
    }
}

Se l'utente ha minimizzato l'app per molto tempo ed è tornato dopo la scadenza del token, onRestart lo reindirizzerà alla schermata di login. Questo previene errori API quando si tenta di effettuare una richiesta con un token scaduto. Nota: il controllo è in onRestart, non in onResume, per evitare un controllo non necessario quando si torna da un dialogo.

Esempio 3: onRestart in Fragment con ViewLifecycleOwner

Il Fragment utilizza onRestart tramite LifecycleObserver per aggiornare i dati.

class FeedFragment : Fragment() {
    private val viewModel: FeedViewModel by viewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        viewLifecycleOwner.lifecycle.addObserver(object : LifecycleObserver {
            @OnLifecycleEvent(Lifecycle.Event.ON_RESTART)
            fun onRestart() {
                Log.d("FeedFragment", "onRestart tramite LifecycleObserver")
                viewModel.refreshFeed()
            }
        })
    }
}

Invece di sovrascrivere onRestart in Fragment, si utilizza LifecycleObserver — un approccio più flessibile che consente di aggiungere logica agli eventi del ciclo di vita senza ereditarietà. ViewLifecycleOwner garantisce che l'observer viva nell'ambito della View (non sopravvive a onDestroyView).