viewWillDisappear in iOS — essentie van de methode en hoe correct te gebruiken

Wat is viewWillDisappear

viewWillDisappear is een methode van UIViewController die UIKit aanroept vlak voordat de View van de controller van het scherm begint te verdwijnen. Op dit moment is het scherm nog zichtbaar voor de gebruiker, maar de overgang is al gestart: NavigationController is begonnen met de push/pop-animatie, het modale venster begint te sluiten of TabBar is begonnen met overschakelen naar een ander tabblad. De ontwikkelaar overschrijft deze methode om bewerkingen uit te voeren die vereisen dat het scherm nog beschikbaar is, maar zich al voorbereidt op verberging.

In tegenstelling tot viewDidDisappear, dat wordt geactiveerd nadat het scherm is verborgen, biedt viewWillDisappear de laatste kans om gegevens op te slaan en bronnen vrij te geven terwijl de gebruiker de interface nog ziet. Dit is cruciaal voor UX — het opslaan van een concept of het stoppen van een timer moet plaatsvinden voordat de gebruiker overschakelt naar een ander scherm.

De methode ontvangt de parameter animated, die aangeeft of de verdwijning met animatie plaatsvindt. Waarde true betekent dat UIKit de overgang met animatie uitvoert, false — het scherm verdwijnt onmiddellijk, bijvoorbeeld bij dismiss zonder animatie of bij programmatische verwijdering uit de hiërarchie.

Wanneer wordt viewWillDisappear aangeroepen

viewWillDisappear wordt aangeroepen in alle scenario's waarin het huidige scherm stopt met actief zijn. Laten we de belangrijkste gevallen bekijken die specifiek zijn voor iOS-ontwikkeling.

Bij push van een nieuw scherm

Wanneer UINavigationController een push van een nieuwe controller uitvoert, wordt bij de huidige controller viewWillDisappear aangeroepen aan het begin van de overgangsanimatie. Op dit moment is het huidige scherm nog zichtbaar onder de nieuwe controller die eroverheen glijdt. Dit is het standaardscenario waarbij viewWillDisappear wordt geactiveerd met animated = true.

Bij pop van het huidige scherm

Wanneer de gebruiker op de terugknop drukt of een interactieve veegbeweging terug maakt, wordt bij de huidige controller viewWillDisappear aangeroepen. Bij een interactief gebaar kan deze aanroep worden geannuleerd als de gebruiker van gedachten verandert en het scherm terugplaatst. Dit is een belangrijke eigenschap waarmee rekening moet worden gehouden bij het ontwerpen van statusopslag.

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

Bij dismiss van de controller

Bij het sluiten van een modaal venster wordt viewWillDisappear aangeroepen op de controller die wordt gesloten aan het begin van de dismiss-animatie. Op dit moment kunnen resultaten worden teruggegeven via delegate of closure, omdat de controller die het modale venster presenteerde nog geen controle heeft gekregen.

Bij het wisselen van TabBar-tabbladen

UITabBarController roept viewWillDisappear aan op de controller van het verlaten tabblad onmiddellijk nadat de gebruiker een ander tabblad heeft aangeraakt. Als er op het huidige tabblad actieve processen zijn — media-afspelen, bestand laden, timer — worden ze hier gepauzeerd of gestopt.

Praktische taken in viewWillDisappear

viewWillDisappear lost concrete taken op het gebied van resource- en statusbeheer op. Laten we de belangrijkste scenario's met codevoorbeelden bekijken.

Gebruikersgegevens opslaan

De belangrijkste taak van viewWillDisappear — het opslaan van gegevens die de gebruiker heeft ingevoerd of gewijzigd op het huidige scherm. Berichtconcepten, bewerkte formuliervelden, geselecteerde instellingen — dit alles moet worden opgeslagen voordat het scherm verdwijnt. Gebruik Core Data, UserDefaults of bestandsopslag voor persistentie.

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

Uitschrijven van meldingen

NotificationCenter, KVO en Combine publishers waarop u bent geabonneerd in viewWillAppear of viewDidLoad moeten worden geannuleerd in viewWillDisappear. Als u dit niet doet, zullen meldingen naar het verborgen scherm komen, wat UI-updates veroorzaakt die de gebruiker niet ziet, of — erger — crashes door verwijzingen naar reeds vrijgegeven objecten.

Animaties en timers stoppen

UIView-animaties gestart in viewDidAppear en timers die werken via Timer of DispatchSource moeten worden gestopt in viewWillDisappear. Doorgaande animaties op een verborgen scherm verbruiken GPU en batterij zonder enig voordeel voor de gebruiker. Stop ze expliciet door invalidate aan te roepen op timers en removeAllAnimations op lagen.

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

Gegevens teruggeven

Als de controller is geopend om een resultaat te krijgen — selectie van een element, tekstinvoer, bevestiging van een actie — is viewWillDisappear het laatste moment waarop de originele controller nog in de stack bestaat en gegevens kan ontvangen. Roep de delegate of closure aan voordat deinit wordt aangeroepen.

Statusopslagstrategie

Betrouwbare opslag van de schermstatus is een van de moeilijkste taken in iOS-ontwikkeling. viewWillDisappear is een belangrijk, maar niet het enige element van de strategie. Laten we een uitgebreide aanpak bekijken.

Niveau 1 — opslag in viewWillDisappear. Snelle opslag van lichte gegevens die direct na terugkeer beschikbaar moeten zijn. Geschikt voor UI-status: scrollpositie, geselecteerd segment, tekst in invoervelden. Probleem: bij een geannuleerd interactief pop-gebaar vindt opslag plaats, hoewel de gebruiker op het scherm is gebleven — gegevens worden onnodig overschreven.

Niveau 2 — opslag in viewDidDisappear. Dupliceert de opslag van het eerste niveau, maar wordt alleen geactiveerd nadat het scherm gegarandeerd is verborgen. Dit is een verzekering tegen geannuleerde gebaren. Als u zich echter in viewWillDisappear al heeft uitgeschreven van meldingen, heeft viewDidDisappear mogelijk geen toegang tot bepaalde gegevens.

Niveau 3 — opslag via applicatiemeldingen. UIApplication.willResignActiveNotification en UIApplication.didEnterBackgroundNotification onderscheppen het minimaliseren van de app. Als de gebruiker de app heeft geminimaliseerd, is viewWillDisappear mogelijk niet aangeroepen — maar opslag via deze meldingen garandeert de integriteit van gegevens bij het beëindigen van de sessie.

Aanbeveling: gebruik een combinatie van alle drie niveaus voor kritieke gebruikersgegevens. Voor niet-kritieke status is het eerste niveau voldoende. Het is belangrijk om dezelfde gegevens niet meerdere keren te overschrijven — gebruik een dirty-vlag die aangeeft dat gegevens zijn gewijzigd sinds de laatste opslag.

Speciale aandacht moet worden besteed aan de strategie voor CRUD-schermen, waar de gebruiker gegevens invoert. Op dergelijke schermen wordt het opslaan van elke toetsaanslag in viewWillDisappear niet aanbevolen — dit is overbodig. Gebruik auto-opslag met vertraging (debounce) via Timer en pas viewWillDisappear alleen toe voor definitieve geforceerde opslag als er niet-opgeslagen wijzigingen zijn. Een dergelijke benadering balanceert tussen prestaties en gegevensveiligheid.

Voor apps met Core Data is een extra maatregel het aanroepen van saveContext in viewWillDisappear alleen wanneer er daadwerkelijke wijzigingen zijn in de managed object context. Controle van context.hasChanges vóór opslag voorkomt onnodige schrijfbewerkingen naar de persistent store en verlengt de levensduur van de batterij van het apparaat. Combineer deze controle met wereldwijde opslag in applicationDidEnterBackground.

Veelvoorkomende fouten in viewWillDisappear

Onjuist gebruik van viewWillDisappear kan leiden tot gegevensverlies, geheugenlekken en instabiel gedrag van de app. Laten we veelvoorkomende fouten van iOS-ontwikkelaars bekijken.

Eerste fout — alleen gegevens opslaan in viewWillDisappear. Zoals hierboven besproken, wordt de methode bij een interactief pop-gebaar aangeroepen, zelfs als het scherm niet verdwijnt. Als opslag bijwerkingen heeft — gegevens naar de server sturen, status wijzigen — kan dit leiden tot valse triggers. Voeg een controle van isBeingDismissed of isMovingFromParent toe.

Tweede fout — geen uitschrijving van NotificationCenter. Dit is een van de meest voorkomende geheugenlekken in iOS. Als u zich in viewWillAppear heeft geabonneerd op UIResponder.keyboardWillShowNotification, maar zich niet heeft uitgeschreven in viewWillDisappear, blijft de closure worden aangeroepen. Bij deinit van de controller verwijst de closure naar een vrijgegeven object — crash van de app is gegarandeerd.

Derde fout — het uitvoeren van zware synchrone bewerkingen. Het opslaan van een grote hoeveelheid gegevens, schrijven naar Core Data of het bestandssysteem in viewWillDisappear blokkeert de main thread. Als de bewerking langer duurt dan de overgangsanimatie, onderbreekt UIKit de thread en bevriest de interface. Verplaats zware opslag naar achtergrondwachtrijen.

Vierde fout — vergeten super aan te roepen. Het niet aanroepen van super.viewWillDisappear kan de werking van UINavigationController en UITabBarController verstoren, die deze methode gebruiken voor hun interne toestanden. Roep altijd super eerst of laatst aan, volgens de Apple-documentatie.

Dit probleem wordt verergerd op iOS met actief multitasken en schakelen tussen apps. Vijfde fout — het gebruik van DispatchQueue.main.async na opslag in viewWillDisappear. Als u asynchroon een blok naar de hoofdrij verzendt na het aanroepen van super.viewWillDisappear, is er geen garantie dat de controller nog bestaat op het moment van uitvoering van het blok. Gebruik altijd zwakke referenties [weak self] binnen closures om verwijzing naar vrijgegeven geheugen te voorkomen en een crash van de app te voorkomen.