onRestart — restauration d'Activity dans le cycle de vie

onRestart — l'essence de la méthode dans le cycle de vie Android

onRestart — une méthode de callback qu'Android appelle strictement avant onStart lorsqu'une Activity revient de l'état invisible Stopped à l'état visible. Cette méthode est unique car elle n'est appelée que lorsque l'Activity est réaffichée — lors de la première création de l'instance, la séquence commence par onCreate, en sautant onRestart. Le cycle complet : onCreate → onStart → onResume (premier lancement) ou onRestart → onStart → onResume (affichage ultérieur).

Du point de vue du système Android, onRestart est une optimisation qui permet à l'Activity de se préparer à son retour : mettre à jour les données du référentiel, synchroniser l'état de l'UI, vérifier la connectivité réseau. Contrairement à onResume, qui est appelé chaque fois que l'Activity obtient le focus (y compris lors du retour d'une boîte de dialogue ou d'un menu système), onRestart n'est déclenché que lors d'un cycle complet de masquage et de retour. Cela fait d'onRestart l'endroit idéal pour les opérations de mise à jour « lourdes » qui ne sont pas nécessaires lors d'une perte partielle de focus.

Selon la spécification du cycle de vie de l'Activity Android, l'intervalle de temps entre onStop et onRestart peut aller de quelques secondes (l'utilisateur a rapidement changé) à plusieurs heures (l'application était en arrière-plan et l'utilisateur est revenu). Pendant ce temps, les données d'une source distante (API, BD) ont pu changer, donc onRestart est un point naturel pour vérifier l'actualité.

Quand onRestart est appelé : conditions et séquence

onRestart n'est appelé que lorsqu'une Activity revient de l'état Stopped, dans lequel l'Activity est entrée après l'appel de onStop. Voici tous les scénarios qui mènent à onRestart.

Scénarios d'invocation d'onRestart :

• Retour d'une autre Activity — l'utilisateur a ouvert une nouvelle Activity (par exemple, a tapé sur une notification) puis est revenu en arrière (a pressé « Retour »). Pile : MainActivity.onPause → MainActivity.onStop → SecondActivity est créée → l'utilisateur presse « Retour » → SecondActivity.onPause → SecondActivity.onStop → SecondActivity.onDestroy → MainActivity.onRestart → MainActivity.onStart → MainActivity.onResume.
• Retour de la minimisation — l'utilisateur a minimisé l'application (Accueil) et est revenu après un certain temps. CurrentActivity.onPause → CurrentActivity.onStop → (application en arrière-plan) → l'utilisateur revient → CurrentActivity.onRestart → CurrentActivity.onStart → CurrentActivity.onResume.
• Retour de l'écran de verrouillage — l'écran de verrouillage recouvre l'Activity ; après déverrouillage, l'Activity reçoit onRestart si un temps significatif s'est écoulé (plus de 5 secondes).
• Retour d'une application lancée via Intent — appareil photo, galerie, navigateur — toute application tierce lancée via startActivityForResult() ou ActivityResultLauncher.

Quand onRestart N'est PAS appelé : lors de la rotation de l'écran (l'Activity est détruite et recréée via onCreate), lors du retour d'une boîte de dialogue (l'Activity n'entre pas dans onStop, seulement onPause → onResume), lors de la mort du processus (l'Activity est recréée).

onRestart vs onCreate : lequel choisir

onRestart et onCreate sont deux approches différentes pour restaurer une Activity. Le choix entre eux dépend si l'Activity a été complètement détruite ou simplement masquée.

Règle de sélection : effectuez l'initialisation de la View et l'abonnement LiveData/StateFlow dans onCreate (ou onViewCreated pour Fragment). Les mises à jour de données, le rechargement de listes et les vérifications d'état — dans onRestart. Si les données sont chargées via ViewModel, onRestart peut simplement appeler la méthode refresh() sur le ViewModel, et la View s'abonnera aux données mises à jour via un flux réactif.

Google recommande : ne dupliquez pas la logique d'onCreate dans onRestart. Extrayez les méthodes refresh() dans ViewModel qui chargent les données actuelles, et appelez-les dans onRestart. Cela préserve une architecture MVVM propre et élimine la duplication de code.

Cas d'utilisation d'onRestart : mise à jour des données et de l'UI

onRestart est l'endroit idéal pour les opérations qui doivent être effectuées chaque fois que l'écran est réaffiché, mais qui ne sont pas nécessaires lors de la première ouverture. Voici des scénarios typiques :

• Mettre à jour une liste depuis la BD ou l'API — l'utilisateur est allé dans une autre Activity, y a modifié des données, est revenu — la liste doit être à jour. Appelez viewModel.refreshItems() dans onRestart.
• Vérification d'autorisation — si l'Activity a été masquée longtemps, le jeton d'accès a pu expirer. onRestart est le point pour vérifier la validité du jeton et rediriger vers l'écran de connexion.
• Synchronisation de l'état de l'UI — changement de thème, changement de langue, mise à jour des paramètres — les modifications doivent s'appliquer au retour à l'écran.
• Rechargement des médias — si l'Activity affiche du contenu qui a pu changer (fil d'actualités, taux de change, météo), mettez à jour les données dans onRestart.
• Vérification de la connectivité réseau — lors du retour du mode hors ligne, l'Activity doit vérifier la disponibilité du réseau et basculer l'UI.
• Restauration des animations — les animations libérées dans onStop doivent être redémarrées dans onRestart avant onStart.

Ce qu'il ne faut PAS faire dans onRestart : ne réinitialisez pas les Views — elles sont vivantes car l'Activity n'a pas été détruite. Ne vous réabonnez pas à LiveData — l'abonnement dans onCreate est toujours actif. Ne créez pas de nouveaux Fragments — ils sont déjà dans le FragmentManager.

onRestart et la mort du processus : une exception importante

L'exception la plus importante : onRestart n'est pas appelé si le processus de l'application a été tué par le système. C'est un point clé que les développeurs oublient souvent lorsqu'ils comptent sur onRestart pour la restauration d'état.

Lors de la mort du processus :

• L'application était en arrière-plan, Android a tué le processus pour libérer de la mémoire.
• L'utilisateur revient — le système démarre un nouveau processus.
• L'Activity est recréée : onCreate(Bundle) → onStart → onResume.
• onRestart n'est PAS appelé — pour le système, il s'agit d'une nouvelle instance d'Activity.

Comment s'en protéger : sauvegardez toujours l'état critique dans onSaveInstanceState(Bundle) (appelé avant onStop) ou utilisez SavedStateHandle dans ViewModel. Dans onCreate, vérifiez savedInstanceState : s'il n'est pas null, restaurez l'état depuis Bundle ; s'il est null, chargez de nouvelles données.

Selon Google Android Vitals, environ 7% des retours à une Activity après un long séjour en arrière-plan se produisent après une mort du processus. Cela signifie qu'une Activity sur 15 qui aurait dû appeler onRestart passe en réalité par onCreate. Ignorer ce scénario est l'une des principales causes de bugs d'« écran vide après le retour ».

Exemples de code avec onRestart en Kotlin

Exemple 1 : onRestart avec mise à jour de liste via ViewModel

L'Activity appelle viewModel.refreshTasks() dans onRestart pour mettre à jour la liste des tâches après être revenue de l'écran d'édition.

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", "${tasks.size} tâches reçues")
        }
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("TaskList", "onRestart: mise à jour de la liste des tâches")
        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() charge les données actuelles depuis le référentiel. LiveData notifie automatiquement l'Activity des changements de données — l'UI se met à jour sans code supplémentaire. onRestart ne crée pas un nouvel abonnement — il a déjà été configuré dans onCreate.

Exemple 2 : onRestart avec vérification d'autorisation

L'Activity vérifie la validité du jeton au retour et redirige vers la connexion si nécessaire.

class ProfileActivity : AppCompatActivity() {
    private val authManager = AuthManager()
    private val launcher = registerForActivityResult(
        ActivityResultContracts.StartActivityForResult()
    ) { Log.d("Profile", "Revenu de l'écran de connexion") }

    override fun onRestart() {
        super.onRestart()
        if (!authManager.isTokenValid()) {
            Log.d("Profile", "Token expiré — redirection vers la connexion")
            launcher.launch(Intent(this, LoginActivity::class.java))
        }
    }
}

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

Si l'utilisateur a minimisé l'application pendant une longue période et est revenu après l'expiration du jeton, onRestart le redirigera vers l'écran de connexion. Cela évite les erreurs d'API lors de la tentative d'exécution d'une requête avec un jeton expiré. Remarque : la vérification est dans onRestart, pas dans onResume, pour éviter une vérification inutile lors du retour d'une boîte de dialogue.

Exemple 3 : onRestart dans Fragment avec ViewLifecycleOwner

Le Fragment utilise onRestart via LifecycleObserver pour mettre à jour les données.

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 via LifecycleObserver")
                viewModel.refreshFeed()
            }
        })
    }
}

Au lieu de redéfinir onRestart dans Fragment, on utilise LifecycleObserver — une approche plus flexible permettant d'ajouter une logique d'événements de cycle de vie sans héritage. ViewLifecycleOwner garantit que l'observer vit dans la portée de la View (il ne survit pas à onDestroyView).