A propos des methods "viewDidLoad" et "viewWillAppear" de viewController

Je voudrais append à la réponse de Caleb: Ne confondez pas le controller de vue et la vue! Le nom viewDidLoad indique clairement que la méthode est invoquée après le chargement de la vue . C'est le controller de vue qui effectue le chargement.

Quelques pointeurs concernant le cycle de vie des vues et l'ordre dans lequel les messages sont envoyés:

• Ce n'est pas un document officiel d'Apple, mais je trouve ce diagramme très utile car il inclut à peu près tous les rlocations de cycle de vie de UIViewController .
• Dans la section Gestion des ressources dans View Controllers du "Guide de programmation de View Controller" d'Apple, il y a un diagramme qui décrit le mode de chargement initial des vues. Il explique loadView et viewDidLoad , également en conjonction avec les storyboards.
• La section Répondre aux notifications relatives à l'affichage du «Guide de programmation de View Controller» d'Apple explique comment répondre aux vues apparaissant et disparaissant ( viewWillAppear: et al)
• Si vous envisagez d'implémenter un controller de vue de conteneur: La reference de class UIViewController a un bon aperçu de la manière dont les messages doivent être envoyés par votre sous-class.

Je m'arrête ici. Vous pouvez find plus de choses vous-même en recherchant "cycle de vie uiviewcontroller".

-viewDidLoad est appelée lorsque le controller charge sa vue, ce qui n'est pas nécessairement juste après l'initialisation. Les controllers View ne chargent pas leurs vues tant qu'ils n'en ont pas besoin, que ce soit pour l'affichage ou pour toute autre raison.

-viewWillAppear est appelée juste avant l'affichage de la vue. Ce sera après -viewDidLoad , mais vous ne savez pas exactement combien de time après. -viewWillAppear est appelée à chaque fois que la vue est affichée; -viewDidLoad ne sera appelée qu'une seconde fois si la vue est déchargée à un moment donné (par exemple, didReceiveMemoryWarning ). Ces jours-ci c'est inhabituel, mais ça peut arriver.

Ou si le viewController est défini sur nil , ce qui peut généralement arriver si un controller de vue est expulsé de la stack de navigation, la prochaine fois qu'il est amené à la stack de navigation, il doit appeler à nouveau -viewDidLoad .

Je pensais que, d'abord, viewDidLoad est appelé lorsque le viewController est chargé pour la première fois (comme son nom l'indique), et immédiatement après la méthode init

Non. Le nom indique que la view du controller a été chargée (pas le controller lui-même). En fait, les docs déclarent que cette méthode sera appelée après que la hiérarchie de vue a été chargée en memory (soit via loadView ou via une plume par exemple).

Ensuite, j'ai pensé qu'une fois que viewDidLoad returnne, viewWillAppear est appelé

Encore une fois, non. loadView (et par conséquent viewDidLoad ) sera appelée la première fois que la propriété view sera accessible et est nil (ce qui est le cas lorsque vous initialisez un controller). Pensez à ce scénario simple:

 MyViewController *vc = [[MyViewController alloc] init]; UIView *view = vc.view; // <= loadView & viewDidLoad will fire but it certainly didn't appear... 

Cependant, tout en développant je fais l'printing qu'il n'y a pas d'ordre lors de l'appel de viewDidLoad et viewWillAppear …

Eh bien, il y a un ordre. Nous soaps avec certitude que viewWillAppear sera toujours appelé après viewDidLoad (si les deux doivent être appelés bien sûr).

Comme vous l'avez dit, ViewDidLoad n'appelle qu'une seule fois après le chargement de la vue. Nous pouvons donc initialiser les instances dans viewDidLoad . Il est principalement destiné à l'initialisation.

viewWillAppear invoquera chaque fois que nous atteindrons cette vue. Donc, s'il y a des changements dans l'interface user, nous pouvons le faire dans viewWillAppear .

J'ai couru une trace sur quand tous ces appels sont faits: http://thecodist.com/article/ios_arc_storyboards_and_uiviewcontroller_trace