Il s'agit des dernières versions d'iOS (modifiées avec Xcode 9.3, Swift 4.1 ). Voici toutes les étapes qui rendent le cycle de vie UIViewControllercomplet.
loadView()
loadViewIfNeeded()
viewDidLoad()
viewWillAppear(_ animated: Bool)
viewWillLayoutSubviews()
viewDidLayoutSubviews()
viewDidAppear(_ animated: Bool)
viewWillDisappear(_ animated: Bool)
viewDidDisappear(_ animated: Bool)
Permettez-moi d'expliquer toutes ces étapes.
1. loadView
Cet événement crée / charge la vue gérée par le contrôleur. Il peut se charger à partir d'un fichier nib associé ou d'un vide UIViewsi null a été trouvé. Cela en fait un bon endroit pour créer vos vues dans le code par programme.
C'est là que les sous-classes doivent créer leur hiérarchie de vue personnalisée si elles n'utilisent pas de plume. Ne devrait jamais être appelé directement. Ne remplacez cette méthode que lorsque vous créez des vues par programme et affectez la vue racine à la viewpropriété N'appelez pas de super méthode lorsque vous substituez
loadView
2. loadViewIfNeeded
Si au cas où la vue du courant viewControllern'a pas encore été définie, cette méthode chargera la vue, mais rappelez-vous, cela n'est disponible que dans iOS> = 9.0. Donc, si vous prenez en charge iOS <9.0, ne vous attendez pas à ce qu'il apparaisse dans l'image.
Charge la vue du contrôleur de vue si elle n'a pas déjà été définie.
3. viewDidLoad
L' viewDidLoadévénement n'est appelé que lorsque la vue est créée et chargée en mémoire, mais les limites de la vue ne sont pas encore définies. C'est un bon endroit pour initialiser les objets que le contrôleur de vue va utiliser.
Appelé après le chargement de la vue. Pour les contrôleurs de vue créés dans le code, c'est après -loadView. Pour les contrôleurs de vue non archivés à partir d'une pointe, c'est après que la vue est définie.
4. viewWillAppear
Cet événement avertit viewControllerchaque fois que la vue apparaît à l'écran. Dans cette étape, la vue a des limites qui sont définies mais l'orientation n'est pas définie.
Appelé lorsque la vue est sur le point d'être rendue visible. La valeur par défaut ne fait rien.
5. viewWillLayoutSubviews
Il s'agit de la première étape du cycle de vie où les limites sont finalisées. Si vous n'utilisez pas de contraintes ou de disposition automatique, vous souhaiterez probablement mettre à jour les sous-vues ici. Ceci est uniquement disponible dans iOS> = 5.0. Donc, si vous prenez en charge iOS <5.0, ne vous attendez pas à ce qu'il apparaisse dans l'image.
Appelé juste avant l'appel de la méthode layoutSubviews du contrôleur de vue. Les sous-classes peuvent être implémentées si nécessaire. La valeur par défaut est un nop.
6. viewDidLayoutSubviews
Cet événement informe le contrôleur de vue que les sous-vues ont été configurées. C'est un bon endroit pour apporter des modifications aux sous-vues une fois qu'elles ont été définies. Ceci est uniquement disponible dans iOS> = 5.0. Donc, si vous prenez en charge iOS <5.0, ne vous attendez pas à ce qu'il apparaisse dans l'image.
Appelé juste après l'appel de la méthode layoutSubviews du contrôleur de vue. Les sous-classes peuvent être implémentées si nécessaire. La valeur par défaut est un nop.
7. viewDidAppear
L' viewDidAppearévénement se déclenche après la présentation de la vue à l'écran. Ce qui en fait un bon endroit pour obtenir des données d'un service backend ou d'une base de données.
Appelé lorsque la vue a été entièrement transférée sur l'écran. La valeur par défaut ne fait rien
8. viewWillDisappear
L' viewWillDisappearévénement se déclenche lorsque la vue présentée viewControllerest sur le point de disparaître, de disparaître, de se couvrir ou de se cacher derrière l'autre viewController. C'est un bon endroit où vous pouvez restreindre vos appels réseau, invalider le minuteur ou libérer des objets qui y sont liés viewController.
Appelé lorsque la vue est rejetée, couverte ou autrement masquée.
9. viewDidDisappear
Il s'agit de la dernière étape du cycle de vie à laquelle tout le monde peut s'attaquer, car cet événement se déclenche juste après que la vue présentée viewControllera disparu, rejetée, couverte ou masquée.
Appelé après que la vue a été rejetée, couverte ou autrement cachée. La valeur par défaut ne fait rien
Maintenant, selon Apple, lorsque vous implémentez ces méthodes, vous devez vous rappeler d'appeler l' superimplémentation de cette méthode spécifique.
Si vous sous-classe UIViewController, vous devez appeler la super implémentation de cette méthode, même si vous n'utilisez pas de NIB. (Par commodité, la méthode init par défaut le fera pour vous et spécifiera nil pour les deux arguments de cette méthode.) Dans la NIB spécifiée, le proxy du propriétaire du fichier devrait avoir sa classe définie dans votre sous-classe de contrôleur de vue, avec la sortie de vue connecté à la vue principale. Si vous appelez cette méthode avec un nom de nib nul, la -loadViewméthode de cette classe tentera de charger une NIB dont le nom est le même que la classe de votre contrôleur de vue. Si une telle NIB n'existe pas, vous devez alors appeler -setView:avant que -viewsoit invoqué, ou remplacer la -loadViewméthode pour configurer vos vues par programme.
J'espère que cela vous a aidé. Merci.
MISE À JOUR - Comme @ThomasW l'a souligné à l'intérieur du commentaire viewWillLayoutSubviewset viewDidLayoutSubviewssera également appelé à d'autres moments lorsque des sous-vues de la vue principale sont chargées, par exemple lorsque des cellules d'une vue de table ou d'une vue de collection sont chargées.
MISE À JOUR - Comme @Maria l'a souligné dans le commentaire, la description de a loadViewété mise à jour
