viewWillAppear iOS-ben: a metódus lényege és használata

Mi az a viewWillAppear

viewWillAppear — ez egy UIViewController metódus, amelyet UIKit közvetlenül a View ablak hierarchiába történő hozzáadása előtt hív meg. Ebben a pillanatban a View már rendelkezik a végleges méretekkel az Auto Layout lépések után, de még nem látható a felhasználó számára — az átmeneti animáció vagy még nem kezdődött el, vagy folyamatban van. A fejlesztő felülírja ezt a metódust, hogy olyan műveleteket végezzen, amelyeknek minden képernyő megjelenése előtt meg kell történniük.

Ellentétben a viewDidLoad-dal, amely egyszer fut le, a viewWillAppear minden alkalommal meghívódik, amikor a képernyő meg fog jelenni: az első megnyitáskor, a gyermek vezérlőről való visszatéréskor, a modális ablak bezárása után és a TabBar lapok váltásakor. Ez teszi kulcsfontosságú metódussá az interfész aktuális állapotának fenntartásában.

A metódus egy Bool típusú animated paramétert kap, amely akkor true, ha a képernyő megjelenését animáció kíséri. Ez a paraméter kényelmesen továbbítható a NavigationBar és TabBar metódusainak, amelyek hasonló paraméterrel rendelkeznek az összehangolt viselkedés érdekében.

Mikor hívódik meg a viewWillAppear

Időzítés a viewWillAppear meghívása a navigáció típusától függ, de az általános szabály változatlan: a metódus azelőtt fut le, hogy a View láthatóvá válik. Tekintsük át a fő forgatókönyveket.

A képernyő első megnyitásakor

A viewDidLoad meghívása után a UIKit megkezdi a megjelenítésre való felkészülést: a View hozzáadódik a hierarchiához, lefutnak a layout lépések, és közvetlenül az átmeneti animáció megkezdése előtt a viewWillAppear meghívódik. Ebben a pillanatban a képernyő még nem látható, de minden subview helyes mérettel rendelkezik, és tartalmuk biztonságosan frissíthető.

NavigationControllerből való visszatéréskor

Amikor a felhasználó megnyomja a vissza gombot vagy programozottan meghívja a popViewController-t, a UIKit visszatér az előző képernyőre és meghívja a viewWillAppear-t rajta. Ez az a fő forgatókönyv, amelyre a viewWillAppear-t használjuk — a lista frissítése egy elem hozzáadása után vagy a beállítások szinkronizálása.

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

Modális ablak bezárásakor

A modálisan bemutatott vezérlő bezárása után a UIKit meghívja a viewWillAppear-t a vezérlőn, amely bemutatta azt. Ez a forgatókönyv különös figyelmet igényel, ha delegate-eket vagy closure-okat használ az adatok visszaküldésére — a viewWillAppear garantálja, hogy a képernyő frissül az eredmény fogadása után.

TabBar lapok váltásakor

A TabBarController minden lapváltáskor meghívja a viewWillAppear-t a kiválasztott lap vezérlőjén. Ha a lapon dinamikus adatok jelennek meg — árfolyamok, értesítések, felhasználói állapot — a viewWillAppear az ideális hely ezek frissítésére.

Gyakorlati feladatok a viewWillAppear-ben

viewWillAppear számos konkrét feladatot old meg, amelyeket nem lehet vagy nem optimális más metódusokban végrehajtani. Tekintsük át a főbbeket.

Tábla adatainak frissítése

A viewWillAppear leggyakoribb használata — a UITableView vagy UICollectionView újratöltése a képernyő minden megjelenésekor. Ha az adatok megváltozhattak az előző képernyőn (elem hozzáadása, állapotváltozás), a reloadData meghívása a viewWillAppear-ben garantálja, hogy a felhasználó aktuális információkat lát.

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

NavigationBar és TabBar konfigurálása

A viewWillAppear-ben kényelmesen konfigurálható a NavigationBar megjelenése: elrejtése vagy megjelenítése, szín változtatása, large title beállítása. Ha a NavigationBar különböző képernyőkön másképp néz ki, a viewWillAppear a megfelelő hely ezekre a változtatásokra, mivel a viewDidLoad csak egyszer hívódik meg.

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

Ideiglenes értesítésekre való feliratkozás

Azok az értesítések, amelyeknek csak akkor van értelme, ha a képernyő látható — billentyűzet, tartalomváltozási értesítések — a viewWillAppear-ben iratkozunk fel rájuk és a viewDidDisappear-ben iratkozunk le róluk. Ez megakadályozza a felesleges handler-eket, amikor a képernyő nem aktív, és véd a memóriaszivárgások ellen.

UI állapot helyreállítása

Ha a képernyőt az alkalmazás elrejtheti vagy minimalizálhatja, a viewWillAppear kényelmes hely az UI állapotának helyreállítására: szegmensek váltása, görgetési pozíció helyreállítása, ideiglenes változtatások visszaállítása. A felhasználó minden megjelenéskor kiszámítható formában kapja meg a képernyőt.

Jelvények és számlálók frissítése

Azokon a képernyőkön, amelyek olvasatlan üzenetek, értékelések vagy értesítések számlálóit jelenítik meg, a viewWillAppear a megfelelő hely ezek frissítésére. Ha a felhasználó másik képernyőn megváltoztathatta a mennyiséget, itt történik az újraszámítás és a UITabBarItem.badgeValue vagy egyéni mutatók frissítése. Ez garantálja, hogy a felhasználó mindig aktuális számokat lát, függetlenül attól, mennyi ideig tartózkodott más képernyőkön.

Külön meg kell említeni a collectionView-vel való munkát: ha a képernyőn lévő adatok rács formájában jelennek meg, olyan cellákkal, amelyek számlálókat vagy állapotokat tartalmaznak, azok frissítése a viewWillAppear-ben szelektív kell legyen. A teljes reloadData helyett használjon reloadItemsAtIndexPaths-t a látható cellákhoz, hogy elkerülje a villogást és a görgetési pozíció elvesztését.

Különbségek a viewWillAppear és a viewDidLoad között

A viewWillAppear és a viewDidLoad közötti különbség megértése — a helyes UIViewController architektúra alapja. Ezek a metódusok eltérő hívási gyakorisággal, eltérő kontextussal és eltérő céllal rendelkeznek.

viewDidLoad egyszer hívódik meg és alkalmas olyan konfigurációra, amely nem változik az idő folyamán: cellák regisztrálása, delegate-ek beállítása, konstansok inicializálása. viewWillAppear minden megjelenéskor meghívódik és alkalmas olyan műveletekre, amelyeket meg kell ismételni: adatok frissítése, látható elemek konfigurálása, állapot szinkronizálása.

Aranyszabály: ha a műveletet csak egyszer kell végrehajtani — tegye a viewDidLoad-ba. Ha minden visszatéréskor a képernyőre — tegye a viewWillAppear-be.

Tipikus hibák a viewWillAppear-ben

Helytelen használat a viewWillAppear-nek teljesítményproblémákhoz, túlzott frissítésekhez és következetlen interfész állapothoz vezethet. Tekintsük át a leggyakoribb hibákat.

Első hiba — a viewDidLoad logikájának megkettőzése. Ha a táblázat celláit mind a viewDidLoad-ban, mind a viewWillAppear-ben regisztrálja — a regisztráció többször fog lefutni, holott az egyszeri konfiguráció elegendő. Helyezze át az összes egyszeri konfigurációt a viewDidLoad-ba.

Második hiba — feltétlen reloadData minden megjelenéskor. Ha az adatok nem változtak, a tábla újratöltése felesleges lekérdezéseket okoz az adatforráshoz és újarajzolja a cellákat, csökkentve a teljesítményt. Ellenőrizze, hogy az állapot tényleg megváltozott-e a reloadData meghívása előtt.

Harmadik hiba — hálózati kérések kezelése anélkül, hogy figyelembe vennénk, hogy a képernyő újra elrejthető a kérés befejeződése előtt. Ha a viewWillAppear-ben elindít egy URLSession kérést, és a felhasználó azonnal másik képernyőre megy, az eredmény egy már elrejtett View-re alkalmazható. Használjon megszakítható feladatokat, vagy ellenőrizze az isViewLoaded és window értékét frissítés előtt.

Negyedik hiba — elfelejti meghívni a super-t. A super.viewWillAppear elmulasztása megzavarhatja a szülő vezérlők (UINavigationController, UITabBarController) működését és a gesztusok és átmenetek helytelen feldolgozásához vezethet. super-t mindig meg kell hívni.

Ötödik hiba — korlátozások módosítása a layoutIfNeeded meghívása nélkül. Ha a viewWillAppear-ben programozottan módosítja a korlátozásokat, a UIKit nem alkalmazza azonnal azokat — a változtatások a következő layout lépésig halmozódnak. A korlátozások módosítása után az azonnali alkalmazáshoz hívja meg a view.layoutIfNeeded() metódust. Ez különösen fontos a tartalomtól függő elemek magasságának beállításakor.

Hatodik hiba — animáció próbálkozás a viewWillAppear-ben. Ahogy fent említettük, a UIKit még mindig az átmeneti animációt dolgozza fel, és az Ön animációja versenyezhet a rendszer animációjával. Ha egy elemnek effektussal kell megjelennie, használjon belépési animációt a viewDidAppear-ben, és a viewWillAppear-ben csak a kezdeti állapotot konfigurálja: átlátszóság 0, transform skála 0.8 és így tovább.

Hetedik hiba — az animated paraméter figyelmen kívül hagyása. Néhány fejlesztő nem ellenőrzi az animated értékét a viewWillAppear-ben, és olyan műveleteket végez, amelyeknek az animáció jelenlététől kellene függeniük. Például, a NavigationBar elrejtése animated = false esetén animáció nélkül, animated = true esetén pedig animációval történhet, hogy az átmenet simán nézzen ki. Mindig adja tovább az animated paramétert a megfelelő UIKit metódusoknak.

Nyolcadik hiba — UI módosítása nem látható képernyőn. Ha a viewWillAppear-ben elindít egy hálózati kérést, és annak befejező blokkja frissíti a UI-t, amikor a képernyő már eltűnhetett, a felhasználó villogást vagy következetlen állapotot lát. Mindig ellenőrizze az isViewLoaded és window értékét, mielőtt frissítené a UI-t closure-okban. Ez az egyszerű művelet megakadályozza az összeomlásokat és a szükségtelen interfész újarajzolásokat.