viewWillAppear in iOS: essentie van de methode en hoe te gebruiken

Wat is viewWillAppear

viewWillAppear — is een methode van UIViewController die UIKit aanroept direct voordat View aan de vensterhiërarchie wordt toegevoegd. Op dit moment heeft View al de definitieve afmetingen na Auto Layout-passages, maar is nog niet zichtbaar voor de gebruiker — de overgangsanimatie is of nog niet begonnen, of wordt uitgevoerd. De ontwikkelaar overschrijft deze methode om bewerkingen uit te voeren die vóór elke weergave van het scherm moeten plaatsvinden.

In tegenstelling tot viewDidLoad dat eenmalig wordt uitgevoerd, wordt viewWillAppear elke keer aangeroepen wanneer het scherm gaat verschijnen: bij de initiële opening, bij terugkeer van een child-controller, na het sluiten van een modaal venster en bij het overschakelen van TabBar-tabbladen. Dit maakt het een cruciale methode voor het behouden van een actuele interfacestatus.

De methode ontvangt de parameter animated van het type Bool, die true is als de verschijning van het scherm gepaard gaat met animatie. Deze parameter is handig om door te geven aan NavigationBar- en TabBar-methoden die een vergelijkbare parameter hebben voor consistent gedrag.

Wanneer wordt viewWillAppear aangeroepen

Tijdstip van aanroepen van viewWillAppear hangt af van het type navigatie, maar de algemene regel is onveranderd: de methode wordt uitgevoerd voordat View zichtbaar wordt. Laten we de belangrijkste scenario’s bekijken.

Bij de eerste opening van het scherm

Na het aanroepen van viewDidLoad begint UIKit met de voorbereiding voor weergave: View wordt aan de hiërarchie toegevoegd, lay-outpassages worden uitgevoerd, en direct voor het begin van de overgangsanimatie wordt viewWillAppear aangeroepen. Op dit moment is het scherm nog niet zichtbaar, maar alle subviews hebben correcte afmetingen en hun inhoud kan veilig worden bijgewerkt.

Bij terugkeer van NavigationController

Wanneer de gebruiker op de terugknop drukt of programmatisch popViewController aanroept, keert UIKit terug naar het vorige scherm en roept viewWillAppear erop aan. Dit is het belangrijkste scenario waarvoor viewWillAppear wordt gebruikt — het bijwerken van de lijst na het toevoegen van een element of het synchroniseren van instellingen.

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

Bij het sluiten van een modaal venster

Na het sluiten van een modaal gepresenteerde controller roept UIKit viewWillAppear aan op de controller die deze presenteerde. Dit scenario vereist speciale aandacht als u delegaten of closures gebruikt om gegevens terug te sturen — viewWillAppear garandeert dat het scherm wordt bijgewerkt na ontvangst van het resultaat.

Bij het overschakelen van TabBar-tabbladen

TabBarController roept viewWillAppear aan op de controller van het geselecteerde tabblad elke keer bij het overschakelen. Als op het tabblad dynamische gegevens worden weergegeven — wisselkoersen, meldingen, gebruikersstatus — is viewWillAppear de ideale plek om deze bij te werken.

Praktische taken in viewWillAppear

viewWillAppear lost verschillende concrete taken op die niet of niet optimaal in andere methoden kunnen worden uitgevoerd. Laten we de belangrijkste bekijken.

Bijwerken van tabelgegevens

De meest voorkomende toepassing van viewWillAppear — het herladen van UITableView of UICollectionView bij elke verschijning van het scherm. Als gegevens op het vorige scherm kunnen zijn gewijzigd (toevoegen van een element, wijzigen van status), garandeert het aanroepen van reloadData in viewWillAppear dat de gebruiker actuele informatie ziet.

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

Configureren van NavigationBar en TabBar

In viewWillAppear kunt u eenvoudig het uiterlijk van NavigationBar configureren: verbergen of tonen, kleur wijzigen, large title instellen. Als NavigationBar op verschillende schermen anders uitziet, is viewWillAppear de juiste plaats voor deze wijzigingen, omdat viewDidLoad slechts eenmaal wordt aangeroepen.

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

Abonneren op tijdelijke meldingen

Meldingen die alleen zin hebben wanneer het scherm zichtbaar is — toetsenbord-, inhoudswijzigingsmeldingen — worden geabonneerd in viewWillAppear en opgezegd in viewDidDisappear. Dit voorkomt overbodige handlers wanneer het scherm niet actief is en beschermt tegen geheugenlekken.

Herstellen van de UI-status

Als het scherm door de applicatie kan worden verborgen of geminimaliseerd, is viewWillAppear een handige plek om de UI-status te herstellen: segmenten schakelen, scrollpositie herstellen, tijdelijke wijzigingen resetten. De gebruiker ontvangt het scherm in een voorspelbare vorm bij elke verschijning.

Bijwerken van badges en tellers

Op schermen die tellers van ongelezen berichten, beoordelingen of meldingen weergeven, is viewWillAppear de juiste plek om ze bij te werken. Als de gebruiker de hoeveelheid op een ander scherm heeft kunnen wijzigen, wordt hier de herberekening en update van UITabBarItem.badgeValue of aangepaste indicatoren aangeroepen. Dit garandeert dat de gebruiker altijd actuele cijfers ziet, ongeacht hoe lang hij op andere schermen is geweest.

Apart moet het werken met collectionView worden genoemd: als de gegevens op het scherm worden gepresenteerd in de vorm van een raster met cellen die tellers of statussen bevatten, moet hun update in viewWillAppear selectief zijn. Gebruik in plaats van volledige reloadData reloadItemsAtIndexPaths voor zichtbare cellen om knipperen en verlies van scrollpositie te voorkomen.

Verschillen tussen viewWillAppear en viewDidLoad

Het begrijpen van het verschil tussen viewWillAppear en viewDidLoad — de basis van een correcte UIViewController-architectuur. Deze methoden hebben een verschillende aanroepfrequentie, verschillende context en een verschillend doel.

viewDidLoad wordt eenmalig aangeroepen en is geschikt voor configuratie die in de loop der tijd niet verandert: registratie van cellen, instellen van delegaten, initialisatie van constanten. viewWillAppear wordt bij elke verschijning aangeroepen en is geschikt voor bewerkingen die moeten worden herhaald: gegevens bijwerken, zichtbare elementen configureren, status synchroniseren.

Gouden regel: als de bewerking slechts eenmaal moet worden uitgevoerd — plaats deze in viewDidLoad. Als elke keer bij terugkeer naar het scherm — plaats in viewWillAppear.

Veelvoorkomende fouten in viewWillAppear

Onjuist gebruik van viewWillAppear kan leiden tot prestatieproblemen, overmatige updates en een inconsistente interfacestatus. Laten we de meest voorkomende fouten bekijken.

Eerste fout — het dupliceren van logica uit viewDidLoad. Als u tabelcellen registreert zowel in viewDidLoad als in viewWillAppear — wordt de registratie meerdere keren uitgevoerd, terwijl eenmalige configuratie voldoende is. Verplaats alle eenmalige configuraties naar viewDidLoad.

Tweede fout — onvoorwaardelijk reloadData bij elke verschijning. Als de gegevens niet zijn gewijzigd, veroorzaakt het herladen van de tabel onnodige verzoeken aan de data source en hertekent cellen, wat de prestaties vermindert. Controleer of de status werkelijk is gewijzigd voordat u reloadData aanroept.

Derde fout — werken met netwerkverzoeken zonder rekening te houden dat het scherm opnieuw kan worden verborgen voordat het verzoek is voltooid. Als u in viewWillAppear een URLSession-verzoek start en de gebruiker gaat onmiddellijk naar een ander scherm, kan het resultaat worden toegepast op een reeds verborgen View. Gebruik annuleerbare taken of controleer isViewLoaded en window vóór het bijwerken.

Vierde fout — vergeten super aan te roepen. Het niet aanroepen van super.viewWillAppear kan de werking van bovenliggende controllers (UINavigationController, UITabBarController) verstoren en leiden tot onjuiste verwerking van gebaren en overgangen. super moet altijd worden aangeroepen.

Vijfde fout — het wijzigen van constraints zonder layoutIfNeeded aan te roepen. Als u in viewWillAppear programmatisch constraints wijzigt, past UIKit deze niet onmiddellijk toe — wijzigingen worden opgehoopt tot de volgende lay-outpassage. Voor onmiddellijke toepassing van wijzigingen na modificatie van constraints, roept u view.layoutIfNeeded() aan. Dit is vooral belangrijk bij het instellen van de hoogte van elementen die afhankelijk zijn van inhoud.

Zesde fout — proberen animatie uit te voeren in viewWillAppear. Zoals hierboven vermeld, verwerkt UIKit nog steeds de overgangsanimatie en uw animatie kan concurreren met de systeemanimatie. Als u nodig heeft dat een element met effect verschijnt, gebruik dan ingangsanimatie in viewDidAppear en configureer in viewWillAppear alleen de begintoestand: transparantie 0, transform op schaal 0.8, enzovoort.

Zevende fout — het negeren van de parameter animated. Sommige ontwikkelaars controleren de waarde van animated in viewWillAppear niet en voeren bewerkingen uit die afhankelijk zouden moeten zijn van de aanwezigheid van animatie. Bijvoorbeeld, het verbergen van NavigationBar bij animated = false kan zonder animatie, en bij animated = true — met animatie, zodat de overgang er vloeiend uitziet. Geef de parameter animated altijd door aan de overeenkomstige UIKit-methoden.

Achtste fout — UI wijzigen op een onzichtbaar scherm. Als u in viewWillAppear een netwerkverzoek start en het voltooiingsblok ervan de UI bijwerkt terwijl het scherm mogelijk al is verdwenen, ziet de gebruiker knipperen of een inconsistente status. Controleer altijd isViewLoaded en window voordat u de UI bijwerkt in closures. Deze eenvoudige handeling voorkomt crashes en onnodige hertekeningen van de interface.