viewWillAppear i iOS: metodens innebörd och hur man använder den

Vad är viewWillAppear

viewWillAppear — är en UIViewController-metod som UIKit anropar omedelbart innan View läggs till i fönsterhierarkin. I detta ögonblick har View redan de slutgiltiga måtten efter Auto Layout-passager, men är ännu inte synlig för användaren — övergångsanimeringen har antingen inte startat eller pågår. Utvecklaren åsidosätter denna metod för att utföra operationer som måste ske före varje skärmvisning.

Till skillnad från viewDidLoad som anropas en gång, anropas viewWillAppear varje gång skärmen ska visas: vid den första öppningen, vid återkomst från en child-controller, efter att ett modalt fönster stängts och vid växling av TabBar-flikar. Detta gör den till en nyckelmetod för att bibehålla ett aktuellt gränssnittstillstånd.

Metoden tar emot parametern animated av typen Bool, som är true om skärmvisningen åtföljs av animering. Denna parameter är bekväm att skicka vidare till NavigationBar- och TabBar-metoder som har en liknande parameter för konsekvent beteende.

När anropas viewWillAppear

Tidpunkten för anropet av viewWillAppear beror på navigeringstypen, men den allmänna regeln är oförändrad: metoden körs innan View blir synlig. Låt oss undersöka de huvudsakliga scenarierna.

Vid första öppningen av skärmen

Efter anropet av viewDidLoad börjar UIKit förberedelserna för visning: View läggs till i hierarkin, layout-passager utförs, och omedelbart innan övergångsanimeringen startar anropas viewWillAppear. I detta ögonblick är skärmen ännu inte synlig, men alla subviews har korrekta mått och deras innehåll kan säkert uppdateras.

Vid återkomst från NavigationController

När användaren trycker på tillbakaknappen eller programmatiskt anropar popViewController, återvänder UIKit till den föregående skärmen och anropar viewWillAppear på den. Detta är huvudscenariot för vilket viewWillAppear används — uppdatering av listan efter att ett element lagts till eller synkronisering av inställningar.

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

Vid stängning av modalt fönster

Efter stängning av en modalt presenterad kontrollant anropar UIKit viewWillAppear på kontrollanten som presenterade den. Detta scenario kräver särskild uppmärksamhet om du använder delegater eller closures för att skicka tillbaka data — viewWillAppear garanterar att skärmen uppdateras efter att resultatet har mottagits.

Vid växling av TabBar-flikar

TabBarController anropar viewWillAppear på kontrollanten för den valda fliken varje gång vid växling. Om dynamisk data visas på fliken — växelkurser, notiser, användarstatus — är viewWillAppear den idealiska platsen för att uppdatera den.

Praktiska uppgifter i viewWillAppear

viewWillAppear löser flera konkreta uppgifter som inte kan eller inte är optimala att utföra i andra metoder. Låt oss undersöka de viktigaste.

Uppdatering av tabelldata

Den vanligaste användningen av viewWillAppear — omladdning av UITableView eller UICollectionView vid varje skärmvisning. Om data kan ha ändrats på den föregående skärmen (tillägg av element, statusändring), garanterar anropet av reloadData i viewWillAppear att användaren ser aktuell information.

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

Konfigurering av NavigationBar och TabBar

I viewWillAppear är det bekvämt att konfigurera NavigationBars utseende: dölja eller visa den, ändra färg, ställa in large title. Om NavigationBar ser olika ut på olika skärmar är viewWillAppear rätt plats för dessa ändringar, eftersom viewDidLoad bara anropas en gång.

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

Prenumeration på tillfälliga notiser

Notiser som bara är meningsfulla när skärmen är synlig — tangentbords-, innehållsändringsnotiser — prenumereras i viewWillAppear och avslutas i viewDidDisappear. Detta förhindrar onödiga hanterare när skärmen inte är aktiv och skyddar mot minnesläckor.

Återställning av UI-tillstånd

Om skärmen kan döljas av applikationen eller minimeras, är viewWillAppear en bekväm plats för att återställa UI-tillståndet: växla segment, återställa scrollposition, nollställa temporära ändringar. Användaren får skärmen i en förutsägbar form vid varje visning.

Uppdatering av badges och räknare

På skärmar som visar räknare för olästa meddelanden, betyg eller notiser, är viewWillAppear rätt plats för att uppdatera dem. Om användaren kan ha ändrat antalet på en annan skärm, anropas här omräkning och uppdatering av UITabBarItem.badgeValue eller anpassade indikatorer. Detta garanterar att användaren alltid ser aktuella siffror oavsett hur länge han befann sig på andra skärmar.

Separat bör arbete med collectionView nämnas: om data på skärmen presenteras i form av ett rutnät med celler som innehåller räknare eller statusar, måste deras uppdatering i viewWillAppear vara selektiv. Använd reloadItemsAtIndexPaths för synliga celler istället för full reloadData för att undvika flimmer och förlust av scrollposition.

Skillnader mellan viewWillAppear och viewDidLoad

Att förstå skillnaden mellan viewWillAppear och viewDidLoad — grunden för en korrekt UIViewController-arkitektur. Dessa metoder har olika anropsfrekvens, olika kontext och olika syfte.

viewDidLoad anropas en gång och är lämplig för konfiguration som inte förändras över tid: registrering av celler, inställning av delegater, initiering av konstanter. viewWillAppear anropas vid varje visning och är lämplig för operationer som måste upprepas: uppdatering av data, konfigurering av synliga element, synkronisering av tillstånd.

Gyllene regeln: om operationen endast ska utföras en gång — lägg den i viewDidLoad. Om varje gång vid återkomst till skärmen — lägg i viewWillAppear.

Vanliga misstag i viewWillAppear

Felaktig användning av viewWillAppear kan leda till prestandaproblem, överdrivna uppdateringar och inkonsekvent gränssnittstillstånd. Låt oss undersöka de vanligaste misstagen.

Första misstaget — duplicering av logik från viewDidLoad. Om du registrerar tabellceller både i viewDidLoad och i viewWillAppear — kommer registreringen att utföras flera gånger, trots att engångskonfiguration räcker. Flytta alla engångskonfigurationer till viewDidLoad.

Andra misstaget — ovillkorlig reloadData vid varje visning. Om data inte har ändrats orsakar omladdning av tabellen onödiga förfrågningar till datakällan och omritning av celler, vilket minskar prestandan. Kontrollera om tillståndet verkligen har ändrats innan du anropar reloadData.

Tredje misstaget — arbete med nätverksförfrågningar utan att beakta att skärmen kan döljas igen innan förfrågan slutförs. Om du i viewWillAppear startar en URLSession-förfrågan och användaren omedelbart går till en annan skärm, kan resultatet tillämpas på en redan dold View. Använd avbrytbara uppgifter eller kontrollera isViewLoaded och window innan uppdatering.

Fjärde misstaget — glömma att anropa super. Att inte anropa super.viewWillAppear kan störa funktionen hos överordnade kontrollanter (UINavigationController, UITabBarController) och leda till felaktig bearbetning av gester och övergångar. super måste alltid anropas.

Femte misstaget — ändring av begränsningar utan att anropa layoutIfNeeded. Om du i viewWillAppear programmatiskt ändrar begränsningar, tillämpar UIKit dem inte omedelbart — ändringarna ackumuleras till nästa layout-passage. För omedelbar tillämpning av ändringar efter modifiering av begränsningar, anropa view.layoutIfNeeded(). Detta är särskilt viktigt vid inställning av höjden på element som är beroende av innehåll.

Sjätte misstaget — försök att utföra animering i viewWillAppear. Som nämnts ovan bearbetar UIKit fortfarande övergångsanimeringen och din animering kan konkurrera med systemanimeringen. Om du behöver att ett element visas med effekt, använd ingångsanimering i viewDidAppear och i viewWillAppear konfigurera endast starttillståndet: transparens 0, transform i skala 0.8 och så vidare.

Sjunde misstaget — ignorering av parametern animated. Vissa utvecklare kontrollerar inte värdet animated i viewWillAppear och utför operationer som borde bero på närvaron av animering. Till exempel, döljande av NavigationBar vid animated = false kan göras utan animering, och vid animated = true — med animering, för att övergången ska se smidig ut. Skicka alltid parametern animated till motsvarande UIKit-metoder.

Åttonde misstaget — modifiering av UI på en osynlig skärm. Om du i viewWillAppear startar en nätverksförfrågan och dess slutförandeblock uppdaterar UI när skärmen kan ha försvunnit, kommer användaren att se flimmer eller inkonsekvent tillstånd. Kontrollera alltid isViewLoaded och window innan du uppdaterar UI i closures. Denna enkla åtgärd förhindrar krascher och onödig omritning av gränssnittet.