viewWillAppear w iOS: istota metody i jak z niej korzystać

Czym jest viewWillAppear

viewWillAppear — to metoda UIViewController, którą UIKit wywołuje bezpośrednio przed dodaniem View do hierarchii okien. W tym momencie View ma już ostateczne rozmiary po przejściach Auto Layout, ale jeszcze nie jest widoczna dla użytkownika — animacja przejścia albo się nie rozpoczęła, albo jest wykonywana. Deweloper nadpisuje tę metodę, aby wykonać operacje, które powinny nastąpić przed każdym wyświetleniem ekranu.

W przeciwieństwie do viewDidLoad, który uruchamia się jednokrotnie, viewWillAppear jest wywoływane za każdym razem, gdy ekran ma się pojawić: przy początkowym otwarciu, po powrocie z kontrolera potomnego, po zamknięciu okna modalnego oraz przy przełączaniu zakładek TabBar. To czyni go kluczową metodą do utrzymywania aktualnego stanu interfejsu.

Metoda przyjmuje parametr animated typu Bool, który ma wartość true, jeśli pojawieniu się ekranu towarzyszy animacja. Ten parametr wygodnie jest przekazywać do metod NavigationBar i TabBar, które również mają analogiczny parametr dla spójnego zachowania.

Kiedy wywoływane jest viewWillAppear

Czas wywołania viewWillAppear zależy od rodzaju nawigacji, ale ogólna zasada jest niezmienna: metoda uruchamia się przed tym, jak View staje się widoczne. Rozważmy główne scenariusze.

Przy pierwszym otwarciu ekranu

Po wywołaniu viewDidLoad UIKit rozpoczyna przygotowanie do wyświetlenia: View jest dodawane do hierarchii, uruchamiane są przejścia layout, i bezpośrednio przed rozpoczęciem animacji przejścia wywoływane jest viewWillAppear. W tym momencie ekran jeszcze nie jest widoczny, ale wszystkie subviews mają poprawne rozmiary i można bezpiecznie aktualizować ich zawartość.

Przy powrocie z NavigationController

Gdy użytkownik naciska przycisk wstecz lub programowo wywołuje popViewController, UIKit wraca do poprzedniego ekranu i wywołuje u niego viewWillAppear. To główny scenariusz, dla którego używa się viewWillAppear — aktualizacja listy po dodaniu elementu lub synchronizacja ustawień.

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

Przy zamykaniu okna modalnego

Po zamknięciu modalnie przedstawionego kontrolera UIKit wywołuje viewWillAppear u kontrolera, który go przedstawił. Ten scenariusz wymaga szczególnej uwagi, jeśli używasz delegatów lub domknięć do przekazywania danych z powrotem — viewWillAppear gwarantuje, że ekran zaktualizuje się po otrzymaniu wyniku.

Przy przełączaniu zakładek TabBar

TabBarController wywołuje viewWillAppear u kontrolera wybranej zakładki za każdym razem przy przełączaniu. Jeśli na zakładce wyświetlane są dane dynamiczne — kursy walut, powiadomienia, status użytkownika — viewWillAppear jest idealnym miejscem do ich aktualizacji.

Zadania praktyczne w viewWillAppear

viewWillAppear rozwiązuje kilka konkretnych zadań, których nie można lub nie jest optymalnie wykonywać w innych metodach. Rozważmy główne z nich.

Aktualizacja danych tabeli

Najczęstsze zastosowanie viewWillAppear — przeładowanie UITableView lub UICollectionView przy każdym pojawieniu się ekranu. Jeśli dane mogły się zmienić na poprzednim ekranie (dodanie elementu, zmiana statusu), wywołanie reloadData w viewWillAppear gwarantuje, że użytkownik widzi aktualne informacje.

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

Konfiguracja NavigationBar i TabBar

W viewWillAppear wygodnie konfiguruje się wygląd NavigationBar: ukrywanie lub pokazywanie go, zmiana koloru, ustawianie large title. Jeśli na różnych ekranach NavigationBar wygląda inaczej, viewWillAppear — to właściwe miejsce na te zmiany, ponieważ viewDidLoad wywoływane jest tylko raz.

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

Subskrypcja tymczasowych powiadomień

Powiadomienia, które mają sens tylko gdy ekran jest widoczny — klawiaturowe, powiadomienia o zmianie treści — subskrybuje się w viewWillAppear i anuluje w viewDidDisappear. Zapobiega to zbędnym handlerom, gdy ekran nie jest aktywny, i chroni przed wyciekami pamięci.

Przywracanie stanu UI

Jeśli ekran może zostać ukryty przez aplikację lub zminimalizowany, viewWillAppear — to wygodne miejsce do przywrócenia stanu UI: przełączania segmentów, przywracania pozycji scrolla, resetowania tymczasowych zmian. Użytkownik otrzymuje ekran w przewidywalnej postaci przy każdym pojawieniu się.

Aktualizacja badży i liczników

Na ekranach wyświetlających liczniki nieprzeczytanych wiadomości, ocen lub powiadomień, viewWillAppear — to właściwe miejsce do ich aktualizacji. Jeśli użytkownik mógł zmienić ilość na innym ekranie, tutaj wywołuje się przeliczenie i aktualizację UITabBarItem.badgeValue lub niestandardowych wskaźników. Gwarantuje to, że użytkownik zawsze widzi aktualne liczby niezależnie od tego, jak długo przebywał na innych ekranach.

Osobno warto wspomnieć o pracy z collectionView: jeśli dane na ekranie są przedstawione w formie siatki z komórkami zawierającymi liczniki lub statusy, ich aktualizacja w viewWillAppear powinna być wybiórcza. Zamiast pełnego reloadData używaj reloadItemsAtIndexPaths dla widocznych komórek, aby uniknąć migotania i utraty pozycji scrolla.

Różnice między viewWillAppear a viewDidLoad

Zrozumienie różnicy między viewWillAppear a viewDidLoad — to podstawa poprawnej architektury UIViewController. Te metody mają różną częstotliwość wywołania, różny kontekst i różne przeznaczenie.

viewDidLoad jest wywoływane raz i nadaje się do konfiguracji, która nie zmienia się z czasem: rejestracja komórek, ustawianie delegatów, inicjalizacja stałych. viewWillAppear jest wywoływane przy każdym pojawieniu się i nadaje się do operacji, które powinny się powtarzać: aktualizacja danych, konfiguracja widocznych elementów, synchronizacja stanu.

Złota zasada: jeśli operacja ma się wykonać tylko raz — umieść ją w viewDidLoad. Jeśli za każdym razem po powrocie na ekran — umieść w viewWillAppear.

Typowe błędy w viewWillAppear

Nieprawidłowe użycie viewWillAppear może prowadzić do problemów z wydajnością, nadmiernych aktualizacji i niespójnego stanu interfejsu. Rozważmy najczęstsze błędy.

Pierwszy błąd — powielanie logiki z viewDidLoad. Jeśli rejestrujesz komórki tabeli zarówno w viewDidLoad, jak i w viewWillAppear — rejestracja będzie wykonywana wielokrotnie, choć wystarczy jednorazowa konfiguracja. Przenieś wszystkie jednorazowe konfiguracje do viewDidLoad.

Drugi błąd — bezwarunkowe reloadData przy każdym pojawieniu się. Jeśli dane się nie zmieniły, przeładowanie tabeli powoduje zbędne zapytania do data source i przerysowywanie komórek, obniżając wydajność. Sprawdzaj, czy stan rzeczywiście się zmienił przed wywołaniem reloadData.

Trzeci błąd — praca z zapytaniami sieciowymi bez uwzględnienia, że ekran może zostać ponownie ukryty przed zakończeniem zapytania. Jeśli w viewWillAppear uruchamiasz zapytanie URLSession, a użytkownik natychmiast przechodzi na inny ekran, wynik może zostać zastosowany do już ukrytego View. Używaj anulowalnych zadań lub sprawdzaj isViewLoaded i window przed aktualizacją.

Czwarty błąd — zapomnienie o wywołaniu super. Niewywołanie super.viewWillAppear może zakłócić działanie kontrolerów nadrzędnych (UINavigationController, UITabBarController) i prowadzić do nieprawidłowego przetwarzania gestów i przejść. super powinien być zawsze wywoływany.

Piąty błąd — zmiana constraintów bez wywołania layoutIfNeeded. Jeśli w viewWillAppear programowo zmieniasz constraints, UIKit nie stosuje ich natychmiast — zmiany kumulują się do następnego przejścia layout. Aby natychmiast zastosować zmiany po modyfikacji constraintów, wywołuj view.layoutIfNeeded(). Jest to szczególnie ważne przy ustawianiu wysokości elementów zależnych od zawartości.

Szósty błąd — próba wykonania animacji w viewWillAppear. Jak wspomniano powyżej, UIKit wciąż przetwarza animację przejścia, a twoja animacja może konkurować z systemową. Jeśli potrzebujesz, aby element pojawił się z efektem, użyj animacji wejściowej w viewDidAppear, a w viewWillAppear tylko skonfiguruj stan początkowy: przezroczystość 0, transform w skali 0.8 i tak dalej.

Siódmy błąd — ignorowanie parametru animated. Niektórzy deweloperzy nie sprawdzają wartości animated w viewWillAppear i wykonują operacje, które powinny zależeć od obecności animacji. Na przykład ukrywanie NavigationBar przy animated = false można zrobić bez animacji, a przy animated = true — z animacją, aby przejście wyglądało płynnie. Zawsze przekazuj parametr animated do odpowiednich metod UIKit.

Ósmy błąd — modyfikacja UI przy niewidocznym ekranie. Jeśli w viewWillAppear uruchamiasz zapytanie sieciowe, a jego completion block aktualizuje UI, gdy ekran mógł już zniknąć, użytkownik zobaczy migotanie lub niespójny stan. Zawsze sprawdzaj isViewLoaded i window przed aktualizacją UI w domknięciach. Ta prosta czynność zapobiega crashom i zbędnym przerysowaniom interfejsu.