viewWillDisappear sa iOS — esensya ng metodo at kung paano ito gamitin nang tama

Ano ang viewWillDisappear

viewWillDisappear ay isang metodo ng UIViewController na tinatawag ng UIKit bago pa man magsimulang mawala ang View ng controller sa screen. Sa sandaling ito, nakikita pa rin ng user ang screen, ngunit nasimulan na ang transisyon: Sinimulan na ng NavigationController ang push/pop animation, nagsimula nang magsara ang modal window, o nagsimula nang lumipat ang TabBar sa ibang tab. Override ng developer ang metodong ito para magsagawa ng mga operasyon na nangangailangan na available pa ang screen, ngunit naghahanda na itong itago.

Hindi tulad ng viewDidDisappear na nagti-trigger pagkatapos itago ang screen, ang viewWillDisappear ay nagbibigay ng huling pagkakataon na mag-save ng data at magpakawala ng resources habang nakikita pa ng user ang interface. Ito ay kritikal para sa UX — ang pag-save ng draft o paghinto ng timer ay dapat mangyari bago lumipat ang user sa ibang screen.

Tumatanggap ang metodo ng parameter na animated, na nagpapahiwatig kung ang pagkawala ay may kasamang animation. Ang value na true ay nangangahulugang ginagawa ng UIKit ang transisyon na may animation, false — agad na nawawala ang screen, halimbawa sa dismiss na walang animation o programmatic na pag-alis mula sa hierarchy.

Kailan tinatawag ang viewWillDisappear

viewWillDisappear ay tinatawag sa lahat ng scenario kapag ang kasalukuyang screen ay tumigil sa pagiging aktibo. Suriin natin ang mga pangunahing kaso na partikular sa pag-develop ng iOS.

Sa push ng bagong screen

Kapag ang UINavigationController ay nagsagawa ng push ng bagong controller, sa kasalukuyang controller ay tinatawag ang viewWillDisappear sa simula ng transisyon animation. Sa sandaling ito, ang kasalukuyang screen ay nakikita pa sa ilalim ng bagong controller na dumudulas sa ibabaw nito. Ito ang standard na scenario kung saan nagti-trigger ang viewWillDisappear na may animated = true.

Sa pop ng kasalukuyang screen

Kapag pinindot ng user ang back button o nagsagawa ng interactive na swipe pabalik, sa kasalukuyang controller ay tinatawag ang viewWillDisappear. Sa interactive na kilos, ang tawag na ito ay maaaring makansela kung nagbago ng isip ang user at ibinalik ang screen sa lugar nito. Ito ay mahalagang katangian na dapat isaalang-alang kapag nagdidisenyo ng pag-save ng estado.

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

Sa dismiss ng controller

Sa pagsasara ng modal window, ang viewWillDisappear ay tinatawag sa controller na sinasara sa simula ng dismiss animation. Sa sandaling ito, maaaring ibalik ang mga resulta sa pamamagitan ng delegate o closure, dahil ang controller na nagpresenta ng modal window ay hindi pa nakatanggap ng kontrol.

Sa paglipat ng TabBar tab

Ang UITabBarController ay tumatawag ng viewWillDisappear sa controller ng iniiwan na tab kaagad pagkatapos hawakan ng user ang ibang tab. Kung sa kasalukuyang tab ay may aktibong proseso — pag-play ng media, pag-load ng file, timer — dito sila pinapause o pinapatigil.

Mga praktikal na gawain sa viewWillDisappear

viewWillDisappear ay lumulutas ng mga konkreto na gawain sa pamamahala ng resources at estado. Suriin natin ang mga pangunahing scenario na may mga halimbawa ng code.

Pag-save ng data ng user

Ang pinakamahalagang gawain ng viewWillDisappear — pag-save ng data na ininput o binago ng user sa kasalukuyang screen. Mga draft ng mensahe, na-edit na field ng form, napiling setting — lahat ito ay dapat mai-save bago mawala ang screen. Gamitin ang Core Data, UserDefaults, o file storage para sa persistency.

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

Pag-unsubscribe mula sa mga notipikasyon

NotificationCenter, KVO, at mga Combine publisher na na-subscribe mo sa viewWillAppear o viewDidLoad ay dapat kanselahin sa viewWillDisappear. Kung hindi mo ito gagawin, darating ang mga notipikasyon sa nakatagong screen, na magdudulot ng UI updates na hindi nakikita ng user, o mas malala — crashes dahil sa reference sa mga napa-release nang object.

Paghinto ng mga animation at timer

Ang mga UIView animation na sinimulan sa viewDidAppear at mga timer na gumagana sa pamamagitan ng Timer o DispatchSource ay dapat ihinto sa viewWillDisappear. Ang patuloy na animation sa nakatagong screen ay kumokonsumo ng GPU at baterya nang walang pakinabang sa user. Ihinto ang mga ito nang tahasan sa pamamagitan ng pagtawag ng invalidate sa mga timer at removeAllAnimations sa mga layer.

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

Pagbalik ng data

Kung binuksan ang controller para makakuha ng resulta — pagpili ng elemento, pag-input ng text, pagkumpirma ng aksyon — ang viewWillDisappear ang huling sandali kung kailan umiiral pa ang orihinal na controller sa stack at maaaring tumanggap ng data. Tawagan ang delegate o closure bago tawagin ang deinit.

Estratehiya sa pag-save ng estado

Maaasahang pag-save ng estado ng screen ay isa sa pinakamahirap na gawain sa pag-develop ng iOS. Ang viewWillDisappear ay mahalaga, ngunit hindi nag-iisang elemento ng estratehiya. Suriin natin ang komprehensibong approach.

Antas 1 — pag-save sa viewWillDisappear. Mabilis na pag-save ng magaan na data na dapat ay available kaagad pagbalik. Angkop para sa UI state: posisyon ng scroll, napiling segment, text sa input field. Problema: sa kina-nselang interactive pop kilos, nagaganap ang pag-save kahit nanatili ang user sa screen — ang data ay na-o-overwrite nang hindi kinakailangan.

Antas 2 — pag-save sa viewDidDisappear. Dinodoble ang pag-save mula sa unang antas, ngunit nagti-trigger lamang pagkatapos garantisadong nakatago ang screen. Ito ay seguro laban sa kinanselang kilos. Gayunpaman, kung sa viewWillDisappear nag-unsubscribe ka na sa mga notipikasyon, maaaring walang access ang viewDidDisappear sa ilang data.

Antas 3 — pag-save sa pamamagitan ng mga notipikasyon ng app. Ang UIApplication.willResignActiveNotification at UIApplication.didEnterBackgroundNotification ay humaharang sa pag-minimize ng app. Kung mininimize ng user ang app, maaaring hindi natawag ang viewWillDisappear — ngunit ang pag-save sa pamamagitan ng mga notipikasyong ito ay ginagarantiya ang integridad ng data sa pagtatapos ng session.

Rekomendasyon: gamitin ang kombinasyon ng lahat ng tatlong antas para sa kritikal na data ng user. Para sa hindi kritikal na estado — sapat na ang unang antas. Mahalaga na huwag i-overwrite ang parehong data nang paulit-ulit — gumamit ng dirty flag na nagpapahiwatig na nagbago ang data mula noong huling pag-save.

Ang espesyal na atensyon ay dapat ibigay sa estratehiya para sa mga CRUD screen, kung saan nag-iinput ang user ng data. Sa ganitong mga screen, ang pag-save ng bawat pagpindot ng key sa viewWillDisappear ay hindi inirerekomenda — ito ay kalabisan. Gumamit ng auto-save na may pagkaantala (debounce) sa pamamagitan ng Timer, at ilapat ang viewWillDisappear lamang para sa pinal na sapilitang pag-save kung may mga hindi nai-save na pagbabago. Ang ganitong approach ay nagbabalanse sa pagitan ng performance at kaligtasan ng data.

Para sa mga app na may Core Data, ang karagdagang hakbang ay ang pagtawag ng saveContext sa viewWillDisappear lamang kapag may tunay na pagbabago sa managed object context. Ang pagsusuri ng context.hasChanges bago mag-save ay pumipigil sa mga hindi kinakailangang pagsulat sa persistent store at nagpapahaba ng buhay ng baterya ng device. Pagsamahin ang pagsusuring ito sa global na pag-save sa applicationDidEnterBackground.

Mga karaniwang pagkakamali sa viewWillDisappear

Maling paggamit ng viewWillDisappear ay maaaring humantong sa pagkawala ng data, pagtagas ng memorya, at hindi matatag na pag-uugali ng app. Suriin natin ang mga karaniwang pagkakamali ng mga iOS developer.

Unang pagkakamali — pag-save ng data lamang sa viewWillDisappear. Tulad ng tinalakay sa itaas, sa interactive pop kilos ang metodo ay tinatawag kahit hindi nawawala ang screen. Kung ang pag-save ay may side effects — pagpapadala ng data sa server, pagbabago ng estado — ito ay maaaring humantong sa maling pag-trigger. Magdagdag ng pagsusuri ng isBeingDismissed o isMovingFromParent.

Ikalawang pagkakamali — hindi pag-unsubscribe mula sa NotificationCenter. Ito ay isa sa mga pinakakaraniwang pagtagas ng memorya sa iOS. Kung nag-subscribe ka sa viewWillAppear sa UIResponder.keyboardWillShowNotification ngunit hindi nag-unsubscribe sa viewWillDisappear, patuloy na tatawagin ang closure. Sa deinit ng controller, ang closure ay magre-reference sa napa-release nang object — crash ng app ay garantisado.

Ikatlong pagkakamali — pagsasagawa ng mabibigat na synchronous na operasyon. Ang pag-save ng malaking halaga ng data, pagsulat sa Core Data o file system sa viewWillDisappear ay humaharang sa main thread. Kung ang operasyon ay tumatagal nang mas mahaba kaysa sa transisyon animation, pinipigilan ng UIKit ang thread at ang interface ay nag-freeze. Ilipat ang mabibigat na pag-save sa background queues.

Ikaapat na pagkakamali — nakalimutang tawagan ang super. Ang hindi pagtawag ng super.viewWillDisappear ay maaaring makagambala sa trabaho ng UINavigationController at UITabBarController, na gumagamit ng metodong ito para sa kanilang internal na estado. Laging tawagan ang super una o huli, ayon sa dokumentasyon ng Apple.

Ang problemang ito ay pinalala sa iOS na may aktibong multitasking at paglipat sa pagitan ng mga app. Ikalimang pagkakamali — paggamit ng DispatchQueue.main.async pagkatapos mag-save sa viewWillDisappear. Kung magpapadala ka ng block nang asynchronously sa main queue pagkatapos tawagan ang super.viewWillDisappear, walang garantiya na umiiral pa ang controller sa oras ng pag-execute ng block. Laging gumamit ng mahinang reference [weak self] sa loob ng closures para maiwasan ang reference sa napa-release na memorya at maiwasan ang crash ng app.