viewWillDisappear dans iOS — l’essence de la méthode et comment l’utiliser correctement

Qu’est-ce que viewWillDisappear

viewWillDisappear est une méthode de UIViewController qu’UIKit appelle juste avant que la Vue du contrôleur ne commence à disparaître de l’écran. À ce moment, l’écran est encore visible pour l’utilisateur, mais la transition a déjà été initiée : NavigationController a commencé l’animation push/pop, la vue modale a commencé à se fermer, ou TabBar a commencé à changer d’onglet. Le développeur redéfinit cette méthode pour effectuer des opérations qui nécessitent que l’écran soit encore accessible tout en se préparant à le masquer.

Contrairement à viewDidDisappear, qui se déclenche après que l’écran est masqué, viewWillDisappear offre la dernière opportunité de sauvegarder des données et de libérer des ressources pendant que l’utilisateur peut encore voir l’interface. C’est crucial pour l’UX — la sauvegarde d’un brouillon ou l’arrêt d’un minuteur doit se produire avant que l’utilisateur ne change d’écran.

La méthode accepte un paramètre animated qui indique si la disparition est animée. true signifie qu’UIKit effectue une transition animée, false signifie que l’écran disparaît instantanément, par exemple lors d’un dismiss sans animation ou d’une suppression programmatique de la hiérarchie.

Quand viewWillDisappear est appelé

viewWillDisappear est appelé dans tous les scénarios où l’écran actuel cesse d’être actif. Passons en revue les principaux cas spécifiques au développement iOS.

Lors du push d’un nouvel écran

Quand UINavigationController effectue un push d’un nouveau contrôleur, viewWillDisappear est appelé sur le contrôleur actuel au début de l’animation de transition. À ce moment, l’écran actuel est encore visible sous le nouveau contrôleur qui glisse par-dessus. C’est le scénario standard où viewWillDisappear se déclenche avec animated = true.

Lors du pop de l’écran actuel

Quand l’utilisateur appuie sur le bouton retour ou effectue un balayage interactif vers l’arrière, viewWillDisappear est appelé sur le contrôleur actuel. Avec un geste interactif, cet appel peut être annulé si l’utilisateur change d’avis et ramène l’écran à sa place. C’est une caractéristique importante à prendre en compte lors de la conception de la sauvegarde d’état.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    saveDraftData()
    NotificationCenter.default.removeObserver(self)
}

Lors du dismiss d’un contrôleur

Lors de la fermeture d’une vue modale, viewWillDisappear est appelé sur le contrôleur fermé au début de l’animation de dismiss. À ce stade, vous pouvez transmettre les résultats via un délégué ou une closure, car le contrôleur qui a présenté la vue modale n’a pas encore repris le contrôle.

Lors du changement d’onglets TabBar

UITabBarController appelle viewWillDisappear sur le contrôleur de l’onglet quitté juste après que l’utilisateur a touché un autre onglet. Si l’onglet actuel a des processus actifs — lecture multimédia, téléchargement de fichier, minuteur — ils doivent être mis en pause ou arrêtés ici.

Tâches pratiques dans viewWillDisappear

viewWillDisappear résout des tâches spécifiques de gestion des ressources et de l’état. Passons en revue les scénarios clés avec des exemples de code.

Sauvegarde des données utilisateur

La tâche la plus importante de viewWillDisappear est de sauvegarder les données que l’utilisateur a saisies ou modifiées sur l’écran actuel. Brouillons de messages, champs de formulaire modifiés, paramètres sélectionnés — tout cela doit être sauvegardé avant que l’écran ne disparaisse. Utilisez Core Data, UserDefaults ou le stockage de fichiers pour la persistance.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    guard hasUnsavedChanges else { return }
    draftStorage.save(currentDraft)
}

Désabonnement des notifications

Les abonnements à NotificationCenter, KVO et aux publishers Combine que vous avez faits dans viewWillAppear ou viewDidLoad doivent être annulés dans viewWillDisappear. Sinon, les notifications arriveront sur l’écran masqué, provoquant des mises à jour de l’interface que l’utilisateur ne voit pas, ou — pire — des plantages dus à l’accès à des objets déjà désalloués.

Arrêt des animations et minuteurs

Les animations UIView lancées dans viewDidAppear et les minuteurs fonctionnant via Timer ou DispatchSource doivent être arrêtés dans viewWillDisappear. Les animations qui continuent sur un écran masqué gaspillent le GPU et la batterie sans aucun bénéfice pour l’utilisateur. Arrêtez-les explicitement en appelant invalidate sur les minuteurs et removeAllAnimations sur les couches.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    countdownTimer?.invalidate()
    countdownTimer = nil
    loadingIndicator.layer.removeAllAnimations()
}

Transmettre des données en retour

Si un contrôleur a été ouvert pour obtenir un résultat — sélection d’un élément, saisie de texte, confirmation d’action — viewWillDisappear est le dernier moment où le contrôleur d’origine existe encore dans la pile et peut recevoir des données. Appelez le délégué ou la closure avant que deinit ne soit invoqué.

Stratégie de sauvegarde d’état

La sauvegarde fiable de l’état est l’une des tâches les plus difficiles du développement iOS. viewWillDisappear est un élément important mais pas le seul de la stratégie. Examinons une approche globale.

Niveau 1 — sauvegarde dans viewWillDisappear. Sauvegarde rapide des données légères qui doivent être disponibles immédiatement au retour. Convient pour l’état de l’interface : position de défilement, segment sélectionné, texte dans les champs de saisie. Problème : lors d’un geste de pop interactif annulé, la sauvegarde se produit même si l’utilisateur est resté sur l’écran — les données sont écrasées inutilement.

Niveau 2 — sauvegarde dans viewDidDisappear. Duplique la sauvegarde du premier niveau mais ne se déclenche qu’après que l’écran est garanti masqué. C’est une protection contre les gestes annulés. Cependant, si vous vous êtes déjà désabonné des notifications dans viewWillDisappear, viewDidDisappear peut ne pas avoir accès à certaines données.

Niveau 3 — sauvegarde via les notifications d’application. UIApplication.willResignActiveNotification et UIApplication.didEnterBackgroundNotification interceptent la mise en arrière-plan de l’application. Si l’utilisateur a minimisé l’application, viewWillDisappear peut ne pas avoir été appelé — mais la sauvegarde via ces notifications garantit l’intégrité des données à la fin de la session.

Recommandation : utilisez une combinaison des trois niveaux pour les données critiques de l’utilisateur. Pour l’état non critique, le premier niveau suffit. Il est important de ne pas sauvegarder les mêmes données plusieurs fois — utilisez un indicateur dirty signalant que les données ont changé depuis la dernière sauvegarde.

Une attention particulière doit être accordée à la stratégie pour les écrans CRUD où l’utilisateur saisit des données. Sur ces écrans, il n’est pas recommandé de sauvegarder chaque frappe dans viewWillDisappear — c’est excessif. Utilisez la sauvegarde automatique avec temporisation (debounce) via Timer, et utilisez viewWillDisappear uniquement pour la sauvegarde forcée finale si des modifications non sauvegardées existent. Cette approche équilibre les performances et l’intégrité des données.

Pour les applications utilisant Core Data, une mesure supplémentaire consiste à appeler saveContext dans viewWillDisappear uniquement en cas de modifications réelles dans le contexte d’objets gérés. Vérifier context.hasChanges avant la sauvegarde évite les écritures inutiles dans le stockage persistant et prolonge la durée de vie de la batterie de l’appareil. Combinez cette vérification avec la sauvegarde globale dans applicationDidEnterBackground.

Erreurs courantes dans viewWillDisappear

Une utilisation incorrecte de viewWillDisappear peut entraîner une perte de données, des fuites mémoire et un comportement instable de l’application. Passons en revue les erreurs fréquentes des développeurs iOS.

Première erreur — sauvegarder les données uniquement dans viewWillDisappear. Comme discuté précédemment, avec un geste de pop interactif la méthode est appelée même si l’écran n’a pas disparu. Si la sauvegarde a des effets secondaires — envoi de données au serveur, changement d’état — cela peut entraîner des déclenchements erronés. Ajoutez une vérification de isBeingDismissed ou isMovingFromParent.

Deuxième erreur — ne pas se désabonner de NotificationCenter. C’est l’une des fuites mémoire les plus courantes sous iOS. Si vous vous êtes abonné dans viewWillAppear à UIResponder.keyboardWillShowNotification mais ne vous êtes pas désabonné dans viewWillDisappear, la closure continuera à être appelée. Lors du deinit du contrôleur, la closure fera référence à un objet désalloué — plantage de l’application garanti.

Troisième erreur — exécution d’opérations synchrones lourdes. Sauvegarder de grandes quantités de données, écrire dans Core Data ou le système de fichiers dans viewWillDisappear bloque le thread principal. Si l’opération dure plus longtemps que l’animation de transition, UIKit met le thread en pause et l’interface se fige. Déplacez les sauvegardes lourdes vers des files d’attente en arrière-plan.

Quatrième erreur — oublier d’appeler super. Ne pas appeler super.viewWillDisappear peut perturber UINavigationController et UITabBarController, qui utilisent cette méthode pour leurs états internes. Appelez toujours super en premier ou en dernier, conformément à la documentation Apple.

Ce problème est aggravé sous iOS avec le multitâche actif et les changements d’application. Cinquième erreur — utiliser DispatchQueue.main.async après la sauvegarde dans viewWillDisappear. Si vous envoyez de manière asynchrone un bloc à la file principale après avoir appelé super.viewWillDisappear, rien ne garantit que le contrôleur existe encore au moment de l’exécution du bloc. Utilisez toujours des références faibles [weak self] dans les closures pour éviter d’accéder à la mémoire désallouée et prévenir les plantages de l’application.