viewWillAppear sa iOS: esensya ng pamamaraan at kung paano gamitin

Ano ang viewWillAppear

viewWillAppear — ay isang pamamaraan ng UIViewController na tinatawag ng UIKit bago idagdag ang View sa hierarchy ng window. Sa sandaling ito ang View ay mayroon nang huling sukat pagkatapos ng mga Auto Layout pass, ngunit hindi pa nakikita ng user — ang animation ng transition ay hindi pa nagsisimula o isinasagawa. Ang developer ay nag-o-override sa pamamaraang ito upang magsagawa ng mga operasyon na dapat mangyari bago ang bawat pagpapakita ng screen.

Hindi tulad ng viewDidLoad na tinatawag nang isang beses, ang viewWillAppear ay tinatawag bawat oras na lilitaw ang screen: sa paunang pagbubukas, sa pagbabalik mula sa child controller, pagkatapos isara ang modal window at sa paglipat ng mga tab ng TabBar. Ginagawa nitong isang pangunahing pamamaraan para sa pagpapanatili ng napapanahong estado ng interface.

Ang pamamaraan ay tumatanggap ng parameter na animated na uri Bool, na true kung ang paglitaw ng screen ay may kasamang animation. Ang parameter na ito ay maginhawang ipasa sa mga pamamaraan ng NavigationBar at TabBar na may katulad na parameter para sa pare-parehong pag-uugali.

Kailan tinatawag ang viewWillAppear

Oras ng pagtawag sa viewWillAppear ay depende sa uri ng nabigasyon, ngunit ang pangkalahatang tuntunin ay hindi nagbabago: ang pamamaraan ay isinasagawa bago maging nakikita ang View. Tingnan natin ang mga pangunahing sitwasyon.

Sa unang pagbubukas ng screen

Pagkatapos ng pagtawag sa viewDidLoad, sinimulan ng UIKit ang paghahanda para sa pagpapakita: idinagdag ang View sa hierarchy, isinasagawa ang mga layout pass, at bago magsimula ang animation ng transition ay tinatawag ang viewWillAppear. Sa sandaling ito ang screen ay hindi pa nakikita, ngunit ang lahat ng subview ay may tamang sukat at ang kanilang nilalaman ay maaaring ligtas na ma-update.

Sa pagbabalik mula sa NavigationController

Kapag pinindot ng user ang back button o programmatically tinawag ang popViewController, bumalik ang UIKit sa nakaraang screen at tinatawag ang viewWillAppear dito. Ito ang pangunahing sitwasyon kung saan ginagamit ang viewWillAppear — pag-update ng listahan pagkatapos magdagdag ng elemento o pag-synchronize ng mga setting.

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

Sa pagsasara ng modal window

Pagkatapos isara ang modal na ipinakitang controller, tinatawag ng UIKit ang viewWillAppear sa controller na nagpakita nito. Ang sitwasyong ito ay nangangailangan ng espesyal na atensyon kung gumagamit ka ng mga delegate o closure para magpadala ng data pabalik — ginagarantiyahan ng viewWillAppear na ang screen ay ma-update pagkatapos matanggap ang resulta.

Sa paglipat ng mga tab ng TabBar

Tinatawag ng TabBarController ang viewWillAppear sa controller ng napiling tab sa bawat oras na lumilipat. Kung sa tab ay ipinapakita ang dynamic na data — mga exchange rate, notification, status ng user — ang viewWillAppear ay ang perpektong lugar para i-update ang mga ito.

Mga praktikal na gawain sa viewWillAppear

viewWillAppear ay lumulutas ng ilang konkretong gawain na hindi magagawa o hindi optimal sa ibang mga pamamaraan. Tingnan natin ang mga pangunahin.

Pag-update ng data ng talahanayan

Ang pinakakaraniwang paggamit ng viewWillAppear — muling pag-load ng UITableView o UICollectionView sa bawat paglitaw ng screen. Kung ang data ay maaaring nagbago sa nakaraang screen (pagdaragdag ng elemento, pagbabago ng status), ang pagtawag sa reloadData sa viewWillAppear ay ginagarantiyang nakikita ng user ang napapanahong impormasyon.

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

Pag-configure ng NavigationBar at TabBar

Sa viewWillAppear maginhawang i-configure ang hitsura ng NavigationBar: itago o ipakita ito, baguhin ang kulay, itakda ang large title. Kung sa iba’t ibang screen ay iba ang hitsura ng NavigationBar, ang viewWillAppear ay ang tamang lugar para sa mga pagbabagong ito, dahil ang viewDidLoad ay tinatawag lamang nang isang beses.

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

Pag-subscribe sa pansamantalang mga notification

Ang mga notification na may katuturan lamang kapag nakikita ang screen — keyboard, mga notification ng pagbabago ng nilalaman — ay naka-subscribe sa viewWillAppear at naka-unsubscribe sa viewDidDisappear. Pinipigilan nito ang mga hindi kinakailangang handler kapag hindi aktibo ang screen at pinoprotektahan laban sa pagtagas ng memorya.

Pagpapanumbalik ng estado ng UI

Kung ang screen ay maaaring itago ng application o i-minimize, ang viewWillAppear ay isang maginhawang lugar para ibalik ang estado ng UI: paglipat ng mga segment, pagpapanumbalik ng posisyon ng scroll, pag-reset ng mga pansamantalang pagbabago. Ang user ay tumatanggap ng screen sa isang predictable na anyo sa bawat paglitaw.

Pag-update ng mga badge at counter

Sa mga screen na nagpapakita ng mga counter ng hindi nabasang mensahe, rating o notification, ang viewWillAppear ay ang tamang lugar para i-update ang mga ito. Kung maaaring binago ng user ang dami sa ibang screen, dito tinatawag ang muling pagkalkula at pag-update ng UITabBarItem.badgeValue o mga custom na indicator. Ginagarantiyahan nito na ang user ay laging nakakakita ng napapanahong mga numero kahit gaano siya katagal sa ibang mga screen.

Hiwalay na dapat banggitin ang pagtatrabaho sa collectionView: kung ang data sa screen ay ipinakita sa anyo ng grid na may mga cell na naglalaman ng mga counter o status, ang kanilang pag-update sa viewWillAppear ay dapat na pumipili. Sa halip na buong reloadData, gumamit ng reloadItemsAtIndexPaths para sa mga nakikitang cell upang maiwasan ang pagkutitap at pagkawala ng posisyon ng scroll.

Pagkakaiba ng viewWillAppear at viewDidLoad

Ang pag-unawa sa pagkakaiba sa pagitan ng viewWillAppear at viewDidLoad — ang batayan ng tamang arkitektura ng UIViewController. Ang mga pamamaraang ito ay may magkaibang dalas ng pagtawag, magkaibang konteksto at magkaibang layunin.

viewDidLoad ay tinatawag nang isang beses at angkop para sa configuration na hindi nagbabago sa paglipas ng panahon: pagpaparehistro ng mga cell, pagtatakda ng mga delegado, pagsisimula ng mga constant. viewWillAppear ay tinatawag sa bawat paglitaw at angkop para sa mga operasyon na dapat ulitin: pag-update ng data, pag-configure ng mga nakikitang elemento, pag-synchronize ng estado.

Gintong patakaran: kung ang operasyon ay dapat isagawa nang isang beses lamang — ilagay sa viewDidLoad. Kung sa bawat pagbabalik sa screen — ilagay sa viewWillAppear.

Mga karaniwang pagkakamali sa viewWillAppear

Maling paggamit ng viewWillAppear ay maaaring humantong sa mga problema sa performance, labis na pag-update at hindi pare-parehong estado ng interface. Tingnan natin ang mga pinakakaraniwang pagkakamali.

Unang pagkakamali — pagdodoble ng lohika mula sa viewDidLoad. Kung nagrerehistro ka ng mga cell ng talahanayan pareho sa viewDidLoad at sa viewWillAppear — ang pagpaparehistro ay isasagawa nang maraming beses, kahit na sapat na ang isang beses na configuration. Ilipat ang lahat ng isang beses na configuration sa viewDidLoad.

Ikalawang pagkakamali — walang kondisyong reloadData sa bawat paglitaw. Kung hindi nagbago ang data, ang muling pag-load ng talahanayan ay nagdudulot ng mga karagdagang kahilingan sa data source at muling pagguhit ng mga cell, na nagpapababa ng performance. Suriin kung ang estado ay talagang nagbago bago tawagin ang reloadData.

Ikatlong pagkakamali — pagtatrabaho sa mga kahilingan sa network nang hindi isinasaalang-alang na ang screen ay maaaring itago muli bago matapos ang kahilingan. Kung sa viewWillAppear ay magsisimula ka ng URLSession request at ang user ay agad na pumunta sa ibang screen, ang resulta ay maaaring mailapat sa isang nakatago nang View. Gumamit ng nakakanselang mga gawain o suriin ang isViewLoaded at window bago mag-update.

Ikaapat na pagkakamali — nakalimutang tawagin ang super. Ang hindi pagtawag sa super.viewWillAppear ay maaaring makagambala sa pagpapatakbo ng mga parent controller (UINavigationController, UITabBarController) at humantong sa maling pagproseso ng mga galaw at transition. super ay dapat palaging tawagin.

Ikalimang pagkakamali — pagbabago ng mga constraint nang hindi tinatawag ang layoutIfNeeded. Kung sa viewWillAppear ay programmatically mong binabago ang mga constraint, hindi agad inaapply ng UIKit ang mga ito — ang mga pagbabago ay naipon hanggang sa susunod na layout pass. Para sa agarang pag-apply ng mga pagbabago pagkatapos baguhin ang mga constraint, tawagin ang view.layoutIfNeeded(). Ito ay lalong mahalaga kapag itinatakda ang taas ng mga elementong umaasa sa nilalaman.

Ikaanim na pagkakamali — pagtatangkang magsagawa ng animation sa viewWillAppear. Tulad ng nabanggit sa itaas, pinoproseso pa rin ng UIKit ang transition animation at ang iyong animation ay maaaring makipagkumpitensya sa system animation. Kung kailangan mong lumitaw ang isang elemento na may epekto, gamitin ang pasok na animation sa viewDidAppear, at sa viewWillAppear ay i-configure lamang ang paunang estado: transparency 0, transform sa scale 0.8, at iba pa.

Ikapitong pagkakamali — pagbalewala sa parameter na animated. Ang ilang developer ay hindi sinusuri ang halaga ng animated sa viewWillAppear at nagsasagawa ng mga operasyon na dapat depende sa pagkakaroon ng animation. Halimbawa, ang pagtatago ng NavigationBar sa animated = false ay maaaring gawin nang walang animation, at sa animated = true — may animation, upang ang transition ay mukhang makinis. Palaging ipasa ang parameter na animated sa kaukulang mga pamamaraan ng UIKit.

Ikawalong pagkakamali — pagbabago ng UI sa hindi nakikitang screen. Kung sa viewWillAppear ay magsisimula ka ng network request at ang completion block nito ay nag-a-update ng UI kapag ang screen ay maaaring nawala na, makikita ng user ang pagkutitap o hindi pare-parehong estado. Palaging suriin ang isViewLoaded at window bago mag-update ng UI sa mga closure. Ang simpleng pagkilos na ito ay pumipigil sa mga crash at hindi kinakailangang muling pagguhit ng interface.