viewWillDisappear w iOS — istota metody i jak prawidłowo jej używać

Czym jest viewWillDisappear

viewWillDisappear to metoda UIViewController, którą UIKit wywołuje bezpośrednio przed tym, jak widok kontrolera zaczyna znikać z ekranu. W tym momencie ekran jest nadal widoczny dla użytkownika, ale przejście już zostało zainicjowane: NavigationController rozpoczął animację push/pop, okno modalne zaczęło się zamykać lub TabBar rozpoczął przełączanie na inną zakładkę. Deweloper nadpisuje tę metodę, aby wykonać operacje, które wymagają, aby ekran był jeszcze dostępny, ale już przygotowuje się do ukrycia.

W przeciwieństwie do viewDidDisappear, które wywoływane jest po ukryciu ekranu, viewWillDisappear zapewnia ostatnią szansę na zapisanie danych i zwolnienie zasobów, gdy użytkownik wciąż widzi interfejs. Jest to kluczowe dla UX — zapisanie szkicu lub zatrzymanie timera powinno nastąpić zanim użytkownik przełączy się na inny ekran.

Metoda przyjmuje parametr animated, który wskazuje, czy zniknięcie odbywa się z animacją. Wartość true oznacza, że UIKit wykonuje przejście z animacją, false — ekran znika natychmiastowo, na przykład przy dismiss bez animacji lub programowym usunięciu z hierarchii.

Kiedy wywoływane jest viewWillDisappear

viewWillDisappear jest wywoływane we wszystkich scenariuszach, gdy bieżący ekran przestaje być aktywny. Omówmy główne przypadki specyficzne dla rozwoju iOS.

Przy push nowego ekranu

Gdy UINavigationController wykonuje push nowego kontrolera, u bieżącego wywoływane jest viewWillDisappear na początku animacji przejścia. W tym momencie bieżący ekran jest nadal widoczny pod nowym, przesuwającym się po nim kontrolerem. To standardowy scenariusz, w którym viewWillDisappear wywoływane jest z animated = true.

Przy pop bieżącego ekranu

Gdy użytkownik naciska przycisk wstecz lub wykonuje interaktywny przesuw w tył, u bieżącego kontrolera wywoływane jest viewWillDisappear. Przy interaktywnym geście to wywołanie może zostać anulowane, jeśli użytkownik zmienił zdanie i przywrócił ekran na miejsce. To ważna cecha, którą należy uwzględnić przy projektowaniu zapisywania stanu.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    saveDraftData()
    NotificationCenter.default.removeObserver(self)
}

Przy dismiss kontrolera

Przy zamykaniu okna modalnego viewWillDisappear jest wywoływane na zamykanym kontrolerze na początku animacji dismiss. W tym momencie można przekazać wyniki z powrotem przez delegat lub domknięcie, ponieważ kontroler, który przedstawił okno modalne, jeszcze nie otrzymał sterowania.

Przy przełączaniu zakładek TabBar

UITabBarController wywołuje viewWillDisappear na kontrolerze opuszczanej zakładki natychmiast po dotknięciu innej zakładki przez użytkownika. Jeśli na bieżącej zakładce są aktywne procesy — odtwarzanie multimediów, ładowanie pliku, timer — tutaj są one wstrzymywane lub zatrzymywane.

Zadania praktyczne w viewWillDisappear

viewWillDisappear rozwiązuje konkretne zadania związane z zarządzaniem zasobami i stanem. Omówmy kluczowe scenariusze z przykładami kodu.

Zapisywanie danych użytkownika

Najważniejsze zadanie viewWillDisappear — zapisywanie danych, które użytkownik wprowadził lub zmienił na bieżącym ekranie. Szkice wiadomości, edytowane pola formularzy, wybrane ustawienia — wszystko to powinno zostać zapisane zanim ekran zniknie. Użyj Core Data, UserDefaults lub pamięci plikowej do trwałości.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    guard hasUnsavedChanges else { return }
    draftStorage.save(currentDraft)
}

Wypisywanie się z powiadomień

NotificationCenter, KVO i Combine publishers, na które zapisałeś się w viewWillAppear lub viewDidLoad, powinny być anulowane w viewWillDisappear. Jeśli tego nie zrobisz, powiadomienia będą przychodzić do ukrytego ekranu, powodując aktualizacje UI, których użytkownik nie widzi, lub — co gorsza — awarie z powodu odwołań do już zwolnionych obiektów.

Zatrzymywanie animacji i timerów

Animacje UIView uruchomione w viewDidAppear i timery działające przez Timer lub DispatchSource powinny być zatrzymane w viewWillDisappear. Kontynuujące się animacje na ukrytym ekranie marnują GPU i baterię bez żadnej korzyści dla użytkownika. Zatrzymuj je jawnie, wywołując invalidate na timerach i removeAllAnimations na warstwach.

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    countdownTimer?.invalidate()
    countdownTimer = nil
    loadingIndicator.layer.removeAllAnimations()
}

Przekazywanie danych z powrotem

Jeśli kontroler został otwarty w celu uzyskania wyniku — wyboru elementu, wprowadzenia tekstu, potwierdzenia działania — viewWillDisappear to ostatni moment, kiedy oryginalny kontroler nadal istnieje w stosie i może przyjąć dane. Wywołaj delegata lub domknięcie przed tym, jak zostanie wywołane deinit.

Strategia zapisywania stanu

Niezawodne zapisywanie stanu ekranu to jedno z najtrudniejszych zadań w rozwoju iOS. viewWillDisappear jest ważnym, ale nie jedynym elementem strategii. Omówmy kompleksowe podejście.

Poziom 1 — zapisywanie w viewWillDisappear. Szybkie zapisywanie lekkich danych, które powinny być dostępne natychmiast po powrocie. Nadaje się do stanu UI: pozycja przewijania, wybrany segment, tekst w polach wprowadzania. Problem: przy anulowanym interaktywnym geście pop zapisywanie następuje, mimo że użytkownik pozostał na ekranie — dane są nadpisywane niepotrzebnie.

Poziom 2 — zapisywanie w viewDidDisappear. Powiela zapisywanie z pierwszego poziomu, ale wywoływane jest dopiero po tym, jak ekran został gwarantowanie ukryty. To zabezpieczenie przed anulowanymi gestami. Jednak jeśli w viewWillDisappear już wypisałeś się z powiadomień, viewDidDisappear może nie mieć dostępu do niektórych danych.

Poziom 3 — zapisywanie przez powiadomienia aplikacji. UIApplication.willResignActiveNotification i UIApplication.didEnterBackgroundNotification przechwytują zwijanie aplikacji. Jeśli użytkownik zwinął aplikację, viewWillDisappear mogło nie zostać wywołane — ale zapisywanie przez te powiadomienia gwarantuje integralność danych przy zakończeniu sesji.

Zalecenie: używaj kombinacji wszystkich trzech poziomów dla krytycznych danych użytkownika. Dla niekrytycznego stanu — wystarczy pierwszy poziom. Ważne, aby nie nadpisywać tych samych danych wielokrotnie — używaj flagi dirty, wskazującej, że dane zmieniły się od ostatniego zapisu.

Szczególną uwagę należy poświęcić strategii dla ekranów CRUD, gdzie użytkownik wprowadza dane. Na takich ekranach nie zaleca się zapisywania każdego naciśnięcia klawisza w viewWillDisappear — to nadmiarowe. Użyj auto-zapisu z opóźnieniem (debounce) przez Timer, a viewWillDisappear stosuj tylko do końcowego wymuszonego zapisu, jeśli istnieją niezapisane zmiany. Takie podejście balansuje między wydajnością a bezpieczeństwem danych.

Dla aplikacji z Core Data dodatkowym środkiem jest wywołanie saveContext w viewWillDisappear tylko w przypadku rzeczywistych zmian w kontekście zarządzanego obiektu. Sprawdzenie context.hasChanges przed zapisem zapobiega zbędnym zapisom do persistent store i wydłuża żywotność baterii urządzenia. Łącz tę kontrolę z globalnym zapisem w applicationDidEnterBackground.

Typowe błędy w viewWillDisappear

Nieprawidłowe użycie viewWillDisappear może prowadzić do utraty danych, wycieków pamięci i niestabilnego zachowania aplikacji. Omówmy częste błędy deweloperów iOS.

Pierwszy błąd — zapisywanie danych tylko w viewWillDisappear. Jak omówiono powyżej, przy interaktywnym geście pop metoda jest wywoływana, nawet jeśli ekran nie zniknął. Jeśli zapisywanie ma skutki uboczne — wysyłanie danych na serwer, zmiana stanu — może to prowadzić do fałszywych wywołań. Dodawaj sprawdzenie isBeingDismissed lub isMovingFromParent.

Drugi błąd — brak wypisania się z NotificationCenter. To jeden z najczęstszych wycieków pamięci w iOS. Jeśli zapisałeś się w viewWillAppear na UIResponder.keyboardWillShowNotification, ale nie wypisałeś się w viewWillDisappear, domknięcie będzie nadal wywoływane. Przy deinit kontrolera domknięcie będzie odwoływać się do zwolnionego obiektu — awaria aplikacji gwarantowana.

Trzeci błąd — wykonywanie ciężkich operacji synchronicznych. Zapisywanie dużej ilości danych, zapis do Core Data lub systemu plików w viewWillDisappear blokuje main thread. Jeśli operacja trwa dłużej niż animacja przejścia, UIKit wstrzymuje wątek i interfejs zawiesza się. Przenoś ciężkie zapisy do kolejek tła.

Czwarty błąd — zapomnienie o wywołaniu super. Niewywołanie super.viewWillDisappear może zakłócić działanie UINavigationController i UITabBarController, które używają tej metody dla swoich wewnętrznych stanów. Zawsze wywołuj super pierwsze lub ostatnie, zgodnie z dokumentacją Apple.

Ten problem pogłębia się na iOS z aktywną wielozadaniowością i przełączaniem między aplikacjami. Piąty błąd — używanie DispatchQueue.main.async po zapisie w viewWillDisappear. Jeśli asynchronicznie wysyłasz blok do głównej kolejki po wywołaniu super.viewWillDisappear, nie ma gwarancji, że kontroler nadal istnieje w momencie wykonania bloku. Zawsze używaj słabych referencji [weak self] wewnątrz domknięć, aby zapobiec odwołaniom do zwolnionej pamięci i zapobiec awarii aplikacji.