.onDisappear: zasada działania i zastosowanie w SwiftUI

Co to jest .onDisappear?

.onDisappear — modyfikator View w SwiftUI, który przyjmuje domknięcie Void i wykonuje je przy usuwaniu View z hierarchii. W parze z .onAppear tworzy pełny cykl życia ekranu: pojawienie się — działanie — zniknięcie. Apple wprowadziła onDisappear wraz z wydaniem SwiftUI w iOS 13 jako odpowiednik viewDidDisappear z UIKit.

Składniowo .onDisappear jest identyczny z onAppear: modyfikuje dowolny View i dołącza domknięcie, które jest wywoływane przez komponent SwiftUI przy usuwaniu widoku. W przeciwieństwie do UIKit, gdzie viewDidDisappear jest wywoływany dopiero po zakończeniu animacji przejścia, onDisappear w SwiftUI może być wywołany przed zakończeniem animacji — w momencie, gdy View jest oznaczony do usunięcia.

Składnia onDisappear

Podstawowa składnia onDisappear jest równie zwięzła jak onAppear. Modyfikator nie przyjmuje dodatkowych parametrów — tylko domknięcie, które jest wykonywane synchronicznie w głównym wątku.

struct DetailView: View {
    var body: some View {
        Text("Ekran szczegółów")
            .onDisappear {
                print("DetailView zniknął z ekranu")
            }
    }
}

Jak działa .onDisappear

Mechanizm wywołania onDisappear jest przeciwny do onAppear: najpierw elementy potomne otrzymują onDisappear, potem rodzic. Ta zasada child-first gwarantuje, że zasoby elementów potomnych są zwalniane przed zwolnieniem zasobów rodzica. Jeśli element potomny zależy od danych rodzica, musi mieć możliwość poprawnego zakończenia bez kontekstu rodzica.

SwiftUI wywołuje onDisappear w momencie, gdy View jest wykluczany z grafu renderowania. Wyzwalaczem może być: pop z NavigationStack, przełączenie TabView, dismiss okna modalnego (sheet/fullScreenCover), zmiana warunkowo wyświetlanego View (if/switch). W List i ScrollView onDisappear jest wywoływany przy przewijaniu komórki poza prefetch-bufor.

Kolejność wywołania child-first

Kolejność child-first oznacza, że jeśli w VStack są trzy potomne View, onDisappear zostanie wywołany najpierw dla każdego dziecka w odwrotnej kolejności, potem dla rodzica. Jest to krytyczne dla poprawnego czyszczenia: potomne timery są anulowane zanim rodzicielski ViewModel zwolni współdzielone zasoby.

struct ParentView: View {
    var body: some View {
        VStack {
            ChildView(id: "A")
            ChildView(id: "B")
        }
        .onDisappear {
            print("Parent onDisappear — ostatni")
        }
    }
}

struct ChildView: View {
    let id: String
    var body: some View {
        Text("Dziecko \(id)")
            .onDisappear {
                print("Dziecko \(id) onDisappear")
            }
    }
}

Wynik w konsoli: Child B onDisappear, Child A onDisappear, Parent onDisappear — ostatni. Odwrotna kolejność w porównaniu z onAppear gwarantuje poprawny łańcuch zwalniania.

Kiedy wywoływany jest .onDisappear

Scenariusze wywołania onDisappear zależą od typu kontenera. W NavigationStack onDisappear jest wyzwalany przy pop-to-root, zwykłym pop-back lub usunięciu ekranu gestem przesunięcia (interactivePopGestureRecognizer). W TabView przełączenie zakładki wywołuje onDisappear dla ukrywanej i onAppear dla wyświetlanej — oba modyfikatory są wyzwalane praktycznie jednocześnie.

W Sheet i fullScreenCover onDisappear jest wywoływany przy programowym dismiss (przez @Environment(\.dismiss)) lub geście przesunięcia w dół. Ważna cecha: jeśli sheet został otwarty, ale użytkownik przełączył aplikację, onDisappear NIE jest wywoływany do faktycznego zamknięcia.

Przykłady .onDisappear

Główne scenariusze onDisappear — to czyszczenie zasobów, zapisywanie stanu i śledzenie. W przeciwieństwie do onAppear, zadania onDisappear są wykonywane na wyjściu i nie wymagają sprawdzania duplikacji, ponieważ View znika jednorazowo.

Zapisywanie stanu i anulowanie timerów

Zapisywanie stanu w onDisappear jest szczególnie przydatne dla formularzy, gdzie dane muszą być zapisane przy opuszczeniu ekranu. Timery i subskrypcje Combine są anulowane w onDisappear, aby uniknąć wycieków przy powrocie na ekran.

struct FormView: View {
    @State private var draftText = ""
    @State private var timer: Timer?
    
    var body: some View {
        TextField("Enter text", text: $draftText)
            .onAppear {
                timer = Timer.scheduledTimer(withTimeInterval: 60, repeats: true) { _ in
                    saveDraft()
                }
            }
            .onDisappear {
                timer?.invalidate()
                timer = nil
                saveDraft()
            }
    }
    
    private func saveDraft() {
        UserDefaults.standard.set(draftText, forKey: "draft")
    }
}

Anulowanie timera w onDisappear zapobiega wykonaniu kodu po zamknięciu ekranu. Bez anulowania timer może próbować zaktualizować @State, który już nie należy do aktualnego View, wywołując runtime warning.

Śledzenie czasu na ekranie

Czas przebywania na ekranie — klasyczny scenariusz śledzenia. Rejestrujemy czas w onAppear, obliczamy różnicę w onDisappear i wysyłamy zdarzenie analityczne z czasem trwania sesji.

struct TrackedView: View {
    @State private var appearTime: Date?
    
    var body: some View {
        Text("Śledzony ekran")
            .onAppear {
                appearTime = Date()
                Analytics.shared.logEvent("screen_view", params: ["screen": "TrackedView"])
            }
            .onDisappear {
                if let start = appearTime {
                    let duration = Date().timeIntervalSince(start)
                    Analytics.shared.logEvent("screen_close", params: [
                        "screen": "TrackedView",
                        "duration_ms": Int(duration * 1000)
                    ])
                }
            }
    }
}

.onDisappear vs .onAppear — różnice

Kluczowa różnica onDisappear od onAppear — kolejność wywołania i gwarancje zadziałania. onAppear jest wywoływany przy dodawaniu View do hierarchii i ma właściwość ponownego wywołania przy odtworzeniu. onDisappear jest wywoływany przy usuwaniu i gwarantowanie działa tylko przy normalnym zamknięciu, ale nie w scenariuszach awaryjnych.

Według WWDC 2024, Apple zaleca traktować onDisappear jako punkt czyszczenia, a nie jako punkt zapisu danych. Krytycznie ważne dane (płatności, rejestracje) powinny być zapisywane w czasie rzeczywistym, a nie w momencie znikania View, ponieważ onDisappear nie gwarantuje wywołania przy zwijaniu aplikacji.

Zalecenie: używaj onDisappear tylko do niekrytycznego czyszczenia i śledzenia. Do zapisywania danych używaj scenePhase lub powiadomień applicationWillTerminate w AppDelegate.

Typowe scenariusze zastosowania

Scenariusz 1: ładowanie podobne do YouTube. Na ekranie szczegółów wideo onDisappear zapisuje pozycję odtwarzania w UserDefaults. Przy ponownym otwarciu onAppear przywraca pozycję z UserDefaults, dając efekt ciągłego oglądania.

Scenariusz 2: anulowanie subskrypcji Combine. Jeśli ViewModel używa publisherów Combine, onDisappear anuluje subskrypcję przez cancellable?.cancel(). Zapobiega to aktualizacji UI po opuszczeniu ekranu, co jest szczególnie ważne dla list z paginacją i zapytań wyszukiwania.

Scenariusz 3: zamykanie WebSocket. W aplikacjach z połączeniami czasu rzeczywistego (komunikatory, kanały notowań) onDisappear zamyka połączenie WebSocket w celu oszczędzania baterii i transferu. Ponowne otwarcie następuje w onAppear przy powrocie na ekran.

Zamykanie WebSocket w onDisappear

WebSocket — typowy zasób, który należy zamykać przy opuszczeniu ekranu. W poniższym przykładzie onDisappear rozłącza socket, a onAppear ponownie go podłącza, co daje znaczną oszczędność transferu dla aplikacji z wieloma ekranami.

struct ChatView: View {
    @StateObject private var socket = WebSocketManager()
    
    var body: some View {
        ChatListView(messages: socket.messages)
            .onAppear {
                socket.connect()
            }
            .onDisappear {
                socket.disconnect()
            }
    }
}

Ważne: przy przełączaniu między zakładkami TabView onDisappear bieżącej i onAppear następnej zakładki są wyzwalane prawie jednocześnie. Dla WebSocket może to prowadzić do cyklu disconnect-connect, który generuje dodatkowe obciążenie. Rozwiązaniem jest użycie opóźnienia lub sprawdzenia, czy socket jest potrzebny na następnym ekranie.