Jaki jest proces urodzenia UIViewController (która metoda następuje po której)?

Przejrzałem to ostatnio i stworzyłem projekt testowy: https://github.com/Janek2004/ViewControllerTest

Uruchom projekt na symulatorze iOS, aby zobaczyć kolejność wykonywania metod podklasy UIViewController. Kolejność może być inna, gdy używamy pliku Nib zamiast storyboard lub load view controller programowo.

1. -[ViewController initWithCoder:] Niearchive danych z nib lub storyboard
2. -[ViewController awakeFromNib] przygotowuje odbiornik do obsługi po załadowaniu go z archiwum Interface Builder lub nib plik.
3. -[ViewController loadView] nigdy nie należy wywoływać tej metody bezpośrednio. Kontroler widoku wywołuje tę metodę, gdy jego widok property is requested but is currently nil. Metoda ta ładuje lub tworzy widok i przypisuje go do właściwości view.
4. -[ViewController viewDidLoad] metoda ta jest wywoływana po tym, jak kontroler widoku załadował swoją hierarchię widoków do pamięci.
5. -[ViewController viewWillAppear:] metoda ta jest wywoływana przed dodaniem widoku odbiornika do hierarchii widoku i przed wszystkie animacje są skonfigurowane do wyświetlania widoku.
6. -[ViewController viewWillLayoutSubviews] wywołane, aby powiadomić kontroler widoku, że jego Widok ma zamiar układać jego podview.Gdy a granice widoku zmieniają się, widok dostosowuje położenie jego podwidań. Kontroler widoku może zastąp tę metodę, aby wprowadzić zmiany przed widok przedstawia swoje podglądy.
7. -[ViewController viewDidLayoutSubviews] wywołane, aby powiadomić kontroler widoku, że jego widok właśnie rozplanował swoje podwoje. Kiedy zmiana granic dla widoku kontrolera widoku, widok dostosowuje pozycji jego podwidywań, a następnie system wywołuje tę metodę. Jednak wywołanie tej metody nie wskazuje, że dostosowano poszczególne układy podwidań widoku. Każdy subview jest odpowiedzialny za dostosowanie własnego układu.

8. -[ViewController Viewdidappear:] powiadamia kontroler widoku, że jego Widok został dodany do hierarchii widoków. Możesz nadpisać tę metodę wykonywanie dodatkowych zadań związanych z prezentacją widoku.

9. -[ViewController Viewwilldisappear:] powiadamia kontroler widoku, że jego Widok ma zostać usunięty z hierarchii widoków.To metoda jest wywoływana w odpowiedzi na usunięcie widoku z widok hierarchia. Ta metoda jest wywoływana przed usunięciem widoku i zanim jakiekolwiek animacje zostaną skonfigurowane. Powiadamia widok kontrolera, że jego Widok został dodany do hierarchii widoków. Możesz zastąp tę metodę, aby wykonać dodatkowe zadania związane z przedstawiam widok.

10. - [ViewController viewDidDisappear:] powiadamia kontroler widoku, że jego Widok został usunięty z hierarchii widoków.

Innym kluczowym momentem w procesie jest wywołanie layoutSubviews na dowolnych podviewach. W tym momencie, a nie wcześniej, wszelkie ograniczenia skonfigurowane w storyboard zostały zastosowane. Jeśli chcesz wprowadzić zmiany w podwidywaniach widoku na podstawie jego ograniczonych współrzędnych, musisz to zrobić w layoutSubviews. Jeśli zrobisz to w viewDidLayoutSubviews, to będzie to za wcześnie, ponieważ te podview nie mają jeszcze zastosowanych ograniczeń (ponieważ jak mówi dokumentacja " każdy subview jest odpowiedzialny za dostosowanie własnego układu".) A jeśli zrobisz to w viewDidAppear, będzie to oczywiście za późno, ponieważ użytkownik zobaczy, że Twoje podviewy zmieniają współrzędne. Tak więc drugim ważnym krokiem w tym procesie jest:

-viewController viewWillAppear
-viewController viewWillLayoutSubviews
-viewController viewDidLayoutSubviews
---> viewController.[any subview] layoutSubviews
-viewController viewDidAppear  

Z Dokumentacji Apple UIViewController:

Kiedy definiujesz nową podklasę UIViewController, musisz określić widoki, którymi kontroler będzie zarządzał. Istnieją dwa wzajemnie wykluczające się sposoby określenia tych widoków: ręcznie lub za pomocą pliku nib. Jeśli widoki zostaną określone ręcznie, należy zaimplementować metodę loadView i użyć jej do przypisania głównego obiektu widoku do właściwości view. Jeśli określisz widoki za pomocą pliku nib, nie możesz nadpisać loadView, ale zamiast tego należy utworzyć plik nib w Interface Builder, a następnie zainicjować obiekt kontrolera widoku za pomocą metody initwithnibname: bundle:. Tworzenie widoków za pomocą pliku nib jest często prostsze, ponieważ można użyć aplikacji Interface Builder do tworzenia i konfigurowania widoków graficznie(w przeciwieństwie do programowego). Obie techniki mają jednak ten sam efekt końcowy, który polega na stworzeniu odpowiedniego zestawu widoków i wyeksponowaniu ich za pomocą właściwości view.

Z top of my head:

1. initWithNibname
2. loadView (ładuj rzeczy ręcznie)
3. viewDidiLoad
4. viewDidAppear

Nie wiadomo gdzie wchodzi layoutSubviews

Generalnie rozwiązuję to pytanie, umieszczając NSLog (lub punkty przerwania) we wszystkich tych delegatach, w tym delegat uruchamiania aplikacji, i postępując zgodnie z kolejnością w debuggerze.

-- This is related to view only:
-viewWillAppear:
-viewDidAppear: 
-viewWillDisappear: and 
-viewDidDisappear: 

are only called when the view is being displayed.

-viewController viewDidLoad
-viewController viewWillAppear
-viewController viewDidAppear

other methods

-viewController viewDidDisappear
-viewController viewWillDisappear 
-viewController viewDidUnload

Chcę podziękować E. James za jego doskonały opis. Nie mogę jeszcze skomentować posta, ale aby uzyskać szybką wizualną ilustrację, zapoznaj się z tym schematem przepływu w Przewodniku programowania kontrolera widoku. I zdaję sobie sprawę, że jest to off-topic, ale dla Wykres sekwencji uruchamiania aplikacji , zapoznaj się z przewodnikiem programowania aplikacji na iOS.