Le Cycle de vie d’un UIViewController

En tant que développeur iOS, nous utilisons à 99.99% du temps un ou plusieurs UIViewController. Pour pouvoir l’utiliser au mieux, il est indispensable de bien comprendre comment utiliser ce dernier et surtout s’intéresser à son cycle de vie. En effet, vous serez amené à effectuer des actions à certains moments de la vie de ce dernier afin de pouvoir proposer la meilleure expérience utilisateur.

Le cycle de vie d’un UIViewController se décompose donc comme ceci:

• init(coder:)
• loadView()
• viewDidLoad()
• viewWillAppear(_ animated: Bool)
• viewDidAppear(_ animated: Bool)
• didReceiveMemoryWarning()
• viewWillDisappear(_ animated: Bool)
• viewDidDisappear(_ animated: Bool)

init(coder:)

Lorsque vous créez les vues de votre application dans un Storyboard, la méthode init(coder) est la méthode utilisée pour instancier le UIViewController. C’est généralement à ce moment que sont allouées les ressources nécessaires à votre UIViewController pour pouvoir fonctionner durant son cycle de vie.

Cette méthode n’est appelée qu’une seule fois durant le cycle de vie de l’objet (pour notre cas, le UIViewController), comme tous les init d’ailleurs.

loadView()

Cette méthode n’est appelée que lorsque le UIViewController est créé de façon programmatique. Vous pouvez overrider cette méthode pour créer vos vue manuellement. Si vous utilisez des Storyboards ou Nibs, cette méthode est à ignorer, c’est en effet le init(coder) qui prendra le relais pour implémenter les fichiers interface et connecter les @IBoutlets et @IBActions.

viewDidLoad()

Cette méthode n’est appelée que lorsque le UIViewController est créé. Chose très importante: A ce moment du cycle de vie, les bounds de la vue ne sont pas finaux!

A ce moment du cycle de vie, vous êtes surs que le UIViewController est créé, que les @IBOutlets sont bien connectés.

C’est un très bon endroit pour initialiser des objets et démarrer des tâches de background, ou encore mettre en place des actions qui ne doivent être effectuer qu’une seule fois.

Si une tâche doit être effectuée à chaque fois que la vue devient visible, ce n’est pas le bon endroit. Concernant les animations, étant donné que les bounds ne sont pas finaux et que la vue n’est pas visible, ce n’est pas le meilleur endroit pour les effectuer.

viewWillAppear(_ animated: Bool)

Méthode appelée avant que le UIViewController soit visible. Il est appelé à chaque fois qu’il va devenir visible à nouveau, au contraire de viewDidLoad qui ne sera appelé qu’une fois.

In ne faut donc pas ajouter de code nécessitant d’être effectué qu’une seule fois durant le cycle de vie du UIViewController. Cette méthode peut être utilisée pour mettre à jour des données qui auraient pu changer lorsque le UIViewController n’était pas visible.

viewDidAppear(_ animated: Bool)

Ca y est! le UIViewController est visible à l’écran, cette méthode est donc appelée. Nous avons les bounds, frames et orientations finaux de notre UIViewController.

C’est le meilleur moment pour faire des animations.

didReceiveMemoryWarning()

Comme tous les produits informatique, les devices iOS ont une limite de mémoire et de puissance. Lorsque la mémoire RAM commence à saturer, iOS ne se sert pas de son disque dur pour déplacer les données comme un ordinateur pourrait le faire. Si votre application utilise trop de mémoire, iOS va le notifier à cette dernière via la méthode didReceiveMemoryWarning(). C’est à ce moment que l’on peut prendre des actions pour libérer de la memoire. Si rien n’est fait et que le UIViewController n’est pas visible, unloadView() est appelé, si le UIViewController est visible et que la mémoire sature vraiment, l’application s’arrêtera et apparait comme un crash aux yeux de l’utilisateur.

Pour libérer de la place, vous pouvez mettre en nil des éléments que vous pouvez recréer ou arrêter une tâche qui demande beaucoup de resources comme un téléchargement de données.

viewWillDisappear(_ animated: Bool)

est appelée juste avant que le UIViewController ne disparaisse de l’écran et avant que le prochain UIViewController soit présenté. Il est possible d’overrider cette méthode. On peut par exemple cacher le clavier, enregistrer des données. Pour arrêter les animations, on va cependant préférer le viewDidDisappear().

viewDidDisappear(_ animated: Bool)

Une fois que le UIViewController n’est plus à l’écran, cette méthode est appelée. Si vous voulez arrêter certaines taches lorsque le UIViewController n’est pas visible, c’est le bon endroit. Il vous faudra pour cela overrider la méthode.

Vous pouvez par exemple arrêter un détecteur de mouvement , un timer, ou arrêter d’écouter les notifications.