viewWillAppear dans iOS : l'essence de la méthode et comment l'utiliser

Qu'est-ce que viewWillAppear

viewWillAppear est une méthode UIViewController qu'UIKit appelle immédiatement avant d'ajouter la View à la hiérarchie des fenêtres. À ce stade, la View a déjà ses dimensions finales après les passes d'Auto Layout, mais n'est pas encore visible pour l'utilisateur — l'animation de transition n'a pas encore commencé ou est en cours. Le développeur surcharge cette méthode pour effectuer des opérations qui doivent se produire avant chaque affichage de l'écran.

Contrairement à viewDidLoad qui n'est déclenché qu'une seule fois, viewWillAppear est appelé chaque fois que l'écran est sur le point d'apparaître : lors de l'ouverture initiale, au retour d'un contrôleur enfant, après la fermeture d'une fenêtre modale et lors du changement d'onglets de la TabBar. Cela en fait une méthode clé pour maintenir un état d'interface à jour.

La méthode accepte un paramètre animated de type Bool, qui est true si l'apparition de l'écran est accompagnée d'une animation. Ce paramètre est pratique à transmettre aux méthodes NavigationBar et TabBar, qui ont également un paramètre similaire pour un comportement cohérent.

Quand viewWillAppear est appelé

Le moment de l'appel de viewWillAppear dépend du type de navigation, mais la règle générale reste la même : la méthode est déclenchée avant que la View ne devienne visible. Examinons les scénarios principaux.

Lors de la première ouverture de l'écran

Après viewDidLoad, UIKit commence la préparation à l'affichage : la View est ajoutée à la hiérarchie, les passes de layout sont déclenchées, et immédiatement avant le début de l'animation de transition, viewWillAppear est appelé. À ce moment, l'écran n'est pas encore visible, mais toutes les sous-vues ont des tailles correctes et leur contenu peut être mis à jour en toute sécurité.

Au retour du NavigationController

Lorsque l'utilisateur appuie sur le bouton retour ou appelle programmatiquement popViewController, UIKit revient à l'écran précédent et appelle son viewWillAppear. C'est le scénario principal pour utiliser viewWillAppear — mettre à jour une liste après l'ajout d'un élément ou synchroniser des paramètres.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    tableView.reloadData()
    updateBadgeCount()
}

Lors de la fermeture d'une fenêtre modale

Après avoir fermé un contrôleur présenté modalement, UIKit appelle viewWillAppear sur le contrôleur qui l'a présenté. Ce scénario nécessite une attention particulière si vous utilisez des délégués ou des closures pour renvoyer des données — viewWillAppear garantit que l'écran se met à jour après avoir reçu le résultat.

Lors du changement d'onglets de la TabBar

TabBarController appelle viewWillAppear sur le contrôleur de l'onglet sélectionné à chaque changement. Si l'onglet affiche des données dynamiques — taux de change, notifications, statut utilisateur — viewWillAppear est l'endroit idéal pour les mettre à jour.

Tâches pratiques dans viewWillAppear

viewWillAppear résolve plusieurs tâches spécifiques qu'il est impossible ou sous-optimal d'effectuer dans d'autres méthodes. Voyons les principales.

Mettre à jour les données de tableau

L'utilisation la plus courante de viewWillAppear est de recharger une UITableView ou UICollectionView chaque fois que l'écran apparaît. Si les données ont pu changer sur l'écran précédent (élément ajouté, statut modifié), appeler reloadData dans viewWillAppear garantit que l'utilisateur voit des informations à jour.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    viewModel.synchronize()
    tableView.reloadData()
}

Configurer la NavigationBar et la TabBar

Dans viewWillAppear, il est pratique de configurer l'apparence de la NavigationBar : la masquer ou l'afficher, changer sa couleur, définir un grand titre. Si différents écrans ont différents styles de NavigationBar, viewWillAppear est l'endroit approprié pour ces changements, car viewDidLoad n'est appelé qu'une seule fois.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    navigationController?.setNavigationBarHidden(
        false, animated: animated
    )
    navigationController?.navigationBar.prefersLargeTitles = true
    tabBarController?.tabBar.isHidden = false
}

S'abonner aux notifications temporaires

Les notifications qui n'ont de sens que lorsque l'écran est visible — notifications de clavier, notifications de changement de contenu — sont souscrites dans viewWillAppear et désouscrites dans viewDidDisappear. Cela évite les gestionnaires inutiles lorsque l'écran n'est pas actif et protège contre les fuites mémoire.

Restaurer l'état de l'interface

Si l'écran peut être masqué par l'application ou réduit, viewWillAppear est un endroit pratique pour restaurer l'état de l'interface : basculer les segments, restaurer la position de défilement, réinitialiser les modifications temporaires. L'utilisateur obtient l'écran dans un état prévisible à chaque apparition.

Mettre à jour les badges et compteurs

Sur les écrans affichant des compteurs de messages non lus, d'évaluations ou de notifications, viewWillAppear est l'endroit approprié pour les mettre à jour. Si l'utilisateur a pu modifier la quantité sur un autre écran, le recalcul et la mise à jour de UITabBarItem.badgeValue ou des indicateurs personnalisés sont appelés ici. Cela garantit que l'utilisateur voit toujours des chiffres à jour, quel que soit le temps passé sur d'autres écrans.

Une attention particulière doit être accordée au travail avec collectionView : si les données à l'écran sont présentées sous forme de grille avec des cellules contenant des compteurs ou des statuts, leur mise à jour dans viewWillAppear doit être sélective. Au lieu d'un reloadData complet, utilisez reloadItemsAtIndexPaths pour les cellules visibles, afin d'éviter le scintillement et la perte de la position de défilement.

Différences entre viewWillAppear et viewDidLoad

Comprendre la différence entre viewWillAppear et viewDidLoad est le fondement d'une architecture UIViewController correcte. Ces méthodes ont une fréquence d'appel, un contexte et un objectif différents.

viewDidLoad est appelé une fois et convient aux configurations qui ne changent pas avec le temps : enregistrer des cellules, définir des délégués, initialiser des constantes. viewWillAppear est appelé à chaque apparition et convient aux opérations qui doivent être répétées : mettre à jour les données, configurer les éléments visibles, synchroniser l'état.

La règle d'or : si une opération ne doit être exécutée qu'une seule fois — mettez-la dans viewDidLoad. Si elle doit être exécutée chaque fois que vous revenez à l'écran — mettez-la dans viewWillAppear.

Erreurs courantes dans viewWillAppear

Une utilisation incorrecte de viewWillAppear peut entraîner des problèmes de performances, des mises à jour excessives et un état d'interface incohérent. Examinons les erreurs les plus courantes.

La première erreur — dupliquer la logique de viewDidLoad. Si vous enregistrez des cellules de tableau à la fois dans viewDidLoad et viewWillAppear, l'enregistrement sera exécuté plusieurs fois, alors qu'une configuration unique suffit. Déplacez toutes les configurations uniques dans viewDidLoad.

La deuxième erreur — reloadData inconditionnel à chaque apparition. Si les données n'ont pas changé, recharger le tableau provoque des requêtes inutiles à la source de données et un redessin des cellules, réduisant les performances. Vérifiez si l'état a réellement changé avant d'appeler reloadData.

La troisième erreur — travailler avec des requêtes réseau sans tenir compte du fait que l'écran peut être à nouveau masqué avant la fin de la requête. Si vous lancez une requête URLSession dans viewWillAppear et que l'utilisateur navigue immédiatement vers un autre écran, le résultat peut être appliqué à une View déjà masquée. Utilisez des tâches annulables ou vérifiez isViewLoaded et window avant la mise à jour.

La quatrième erreur — oublier d'appeler super. Ne pas appeler super.viewWillAppear peut perturber le comportement des contrôleurs parents (UINavigationController, UITabBarController) et entraîner un traitement incorrect des gestes et des transitions. super doit toujours être appelé.

La cinquième erreur — modifier les contraintes sans appeler layoutIfNeeded. Si vous modifiez les contraintes programmatiquement dans viewWillAppear, UIKit ne les applique pas immédiatement — les modifications s'accumulent jusqu'à la prochaine passe de layout. Pour une application immédiate des modifications après avoir modifié les contraintes, appelez view.layoutIfNeeded(). Ceci est particulièrement important lors de l'ajustement de la hauteur d'éléments dépendants du contenu.

La sixième erreur — tenter d'exécuter une animation dans viewWillAppear. Comme mentionné précédemment, UIKit traite encore l'animation de transition, et votre animation peut entrer en concurrence avec celle du système. Si vous avez besoin qu'un élément apparaisse avec un effet, utilisez l'animation d'entrée dans viewDidAppear, et dans viewWillAppear, configurez uniquement l'état initial : transparence 0, transform à échelle 0,8, etc.

La septième erreur — ignorer le paramètre animated. Certains développeurs ne vérifient pas la valeur de animated dans viewWillAppear et effectuent des opérations qui devraient dépendre de la présence d'une animation. Par exemple, masquer la NavigationBar quand animated = false peut se faire sans animation, et quand animated = true — avec animation, pour que la transition paraisse fluide. Transmettez toujours le paramètre animated aux méthodes UIKit appropriées.

La huitième erreur — modifier l'interface lorsque l'écran n'est pas visible. Si vous lancez une requête réseau dans viewWillAppear et que son bloc de completion met à jour l'interface alors que l'écran a déjà disparu, l'utilisateur verra un scintillement ou un état incohérent. Vérifiez toujours isViewLoaded et window avant de mettre à jour l'interface dans les closures. Cette action simple empêche les plantages et les redessinages inutiles de l'interface.