viewDidDisappear: esensya ng pamamaraan, lifecycle ng UIViewController at kailan ito tinatawag

Ano ang viewDidDisappear?

viewDidDisappear — ay isang hook method ng superclass na UIViewController na tinatawag ng system pagkatapos na ganap na matanggal ang view sa hierarchy ng window sa screen. Ito ay bahagi ng standard lifecycle ng view sa UIKit at nagbibigay sa developer ng punto para magsagawa ng mga pagsasara ng operasyon.

Ang pamamaraan ay idineklara sa UIViewController protocol at available para i-override sa lahat ng subclass. Ang signature ng method: override func viewDidDisappear(_ animated: Bool). Ang parameter na animated ay nagpapahiwatig kung ang transition ay may kasamang animation. Ito ay nagbibigay-daan upang makilala ang programmatic at animated na transitions para sa mas tumpak na kontrol ng pag-uugali.

Hindi tulad ng viewWillDisappear na tinatawag bago magsimula ang animation, ginagarantiya ng viewDidDisappear na ang view ay hindi na nakikita ng user. Ito ay kritikal para sa mga operasyon na dapat gawin lamang pagkatapos na ganap na maitago ang interface — halimbawa, pagtatago ng full-screen overlay elements o pagtatapos ng video recording.

Signature at deklarasyon

Ang pamamaraan ay tinukoy sa base class na UIViewController at may sumusunod na signature:

import UIKit

class MyViewController: UIViewController {
    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        // Pagbabakante ng resources at pag-unsubscribe
    }
}

Ang mandatoryong tawag sa super.viewDidDisappear(animated) sa unang linya ng implementasyon — ito ay isang kinakailangan ng UIKit. Kung wala ito, hindi makukumpleto ng superclass ang mga internal na proseso na may kaugnayan sa pagpapakita ng view. Ang pagbalewala sa panuntunang ito ay humahantong sa hindi mahulaan na pag-uugali ng navigation at potensyal na pag-crash.

Posisyon ng viewDidDisappear sa lifecycle ng UIViewController

Ang kumpletong lifecycle ng UIViewController ay binubuo ng anim na pangunahing pamamaraan, bawat isa ay responsable para sa isang partikular na yugto ng pagkakaroon ng view. viewDidDisappear ay kumukumpleto sa sequence ng pagtatago, kasunod ng viewWillDisappear. Mahalagang maunawaan ang pagkakasunud-sunod ng pagtawag ng lahat ng pamamaraan upang maayos na maipamahagi ang initialization at pagbabakante ng resources.

Ang pagkakasunud-sunod kapag lumilitaw ang view: viewDidLoad → viewWillAppear → viewDidAppear. Kapag nagtatago: viewWillDisappear → viewDidDisappear. Ang huling yugto — deinit, na tinatawag kapag nawasak ang UIViewController object. Ang anim na pamamaraang ito ay bumubuo ng isang kumpletong cycle, na ginagarantiya ang predictable na pamamahala ng estado.

Ang bawat isa sa mga pamamaraang ito ay tinatawag nang isang beses lamang para sa kaukulang transition. Exception — viewDidLoad, na maaaring tawagin muli kung ang ViewController ay na-unload mula sa memory dahil sa kakulangan ng resources at pagkatapos ay na-restore. Sa kasong ito, ang viewDidDisappear ay mauuna sa muling viewDidLoad.

Kaugnayan sa transition animation

Ang parameter na animated sa signature ng method ay nagpapahiwatig kung ang transition ay may animation. Ito ay kapaki-pakinabang para sa pagkilala ng programmatic transitions na walang animation (halimbawa, kapag nagse-set ng rootViewController) at animated transitions na pinasimulan ng user. Kung ang halaga ay false, maaaring ang controller ay sapilitang itinago ng system — sa kasong ito, ang ilang time-dependent na operasyon ay maaaring hindi nauugnay.

Kailan tinatawag ang viewDidDisappear

Tinatawag ng system ang viewDidDisappear sa eksaktong dalawang sitwasyon: kapag ang ViewController ay tinanggal mula sa navigation stack at kapag ito ay natatakpan ng ibang controller. Sa parehong kaso, ang pamamaraan ay nagpapahiwatig na ang view ay hindi na nakikita ng user at ang developer ay dapat magbakante ng resources na hindi kailangan sa background. Ang pag-unawa sa mga sitwasyong ito ay pumipigil sa maling palagay tungkol sa estado ng application.

Unang sitwasyon — pop mula sa UINavigationController. Kapag pinindot ng user ang “Bumalik” na button, tinatawag ang popViewController: animated. Ang kasalukuyang controller ay tumatanggap ng viewDidDisappear, at pagkatapos, kung wala nang malakas na references dito, deinit. Pangalawang sitwasyon — present/dismiss. Sa modal na pagpapakita ng bagong controller, ang presentingViewController ay tumatanggap ng viewDidDisappear. Sa dismiss, ang pamamaraang ito ay tinatawag sa controller na ipinakita nang modal.

Pangatlong sitwasyon, hindi gaanong halata — pagdaragdag ng child ViewController. Kung ang isang bagong child controller ay idinagdag sa isang container controller (halimbawa, UIPageViewController o UITabBarController), ang aktibong child controller ay tumatanggap ng viewDidDisappear. Ito ay kritikal para sa mga application na may tabs o page carousel — bawat pagpapalit ng tab ay dapat na wastong mag-pause sa gawain ng hindi aktibong screen.

Mga exception at hindi halatang kaso

May mahalagang exception: kung ang UIViewController ay ipinapakita sa isang modal window at isinara ito ng user nang interactive sa pamamagitan ng pag-swipe pababa, maaaring hindi tawagin ng system ang viewDidDisappear sa hindi kumpletong swipe. Ang pag-uugaling ito ay lumitaw sa iOS 13 kasama ng interactive dismiss. Dapat pangasiwaan ng mga developer ang estado sa pamamagitan ng UIAdaptivePresentationControllerDelegate at ang method na didDismiss para sa garantisadong pagtanggap ng event.

Isa pang feature — memory warnings. Sa kakulangan ng memory, maaaring i-unload ng system ang view ng controller na hindi ipinapakita sa screen. Sa kasong ito, ang viewDidDisappear ay karaniwang tinatawag bago ang pag-unload, ngunit dapat i-duplicate ng developer ang mga kritikal na operasyon ng pagbabakante sa didReceiveMemoryWarning para sa kaligtasan. Ang ganitong approach ay pumipigil sa pagkawala ng data sa matinding sitwasyon.

Karaniwang mga sitwasyon ng paggamit

viewDidDisappear ay ginagamit para sa tatlong pangunahing kategorya ng operasyon: paghinto ng mga aktibidad, pagbabakante ng resources, at pag-save ng estado. Bawat kategorya ay may kanya-kanyang best practices na binuo ng komunidad ng iOS developers. Tingnan natin ang pinakakaraniwang sitwasyon na may mga halimbawa ng implementasyon.

• Paghinto ng animation — pagtawag ng layer.removeAllAnimations() para sa CALayer, paghinto ng UIView.animate blocks
• Pagbabakante ng resources — pag-zero ng malalaking images, pag-reset ng naka-cache na data, pagsasara ng file descriptors
• Pag-unsubscribe sa notification — pag-alis ng mga observer mula sa NotificationCenter.default, paghinto ng KVO observations
• Pag-save ng progress — pagsusulat ng drafts sa CoreData o UserDefaults kapag isinasara ang edit screen
• Pagtatago ng overlay — pag-alis ng loading indicators, tooltips at popover elements na hindi dapat manatili pagkatapos ng transition

Halimbawa: pag-unsubscribe sa NotificationCenter

Karaniwang pagkakamali — mag-subscribe sa notification sa viewDidLoad at hindi kailanman mag-unsubscribe. Ito ay humahantong sa pagtawag ng handler sa isang nawasak na object, na nagdudulot ng crash. Ang tamang approach — mag-subscribe sa viewWillAppear at mag-unsubscribe sa viewDidDisappear, na ginagarantiya na ang subscription ay aktibo lamang habang ang controller ay ipinapakita sa screen.

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    NotificationCenter.default.addObserver(
        self,
        selector: #selector(handleKeyboardShow),
        name: UIResponder.keyboardWillShowNotification,
        object: nil
    )
}

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

Ang pattern na ito ay ginagarantiya na ang notification handler ay aktibo lamang kapag ang controller ay nakikita sa screen. Kapag lumipat sa ibang screen, ang lahat ng subscription ay awtomatikong tinatanggal, at kapag bumalik ay naibabalik. Ito ay nagpapataas ng reliability ng application at nag-aalis ng klase ng mga bug na may kaugnayan sa notification.

Mga halimbawa ng code sa Swift

Tingnan natin ang dalawang praktikal na halimbawa ng paggamit ng viewDidDisappear sa totoong proyekto. Unang halimbawa ay nagpapakita ng paghinto ng timer kapag itinago ang screen, pangalawa — tamang pagtatapos ng pagmamasid sa keyboard. Parehong halimbawa ay sumusunod sa prinsipyo ng pagbabakante ng resources kapag hindi aktibo ang controller.

Paghinto ng timer

Kung sa screen ay tumatakbo ang Timer para sa pag-update ng UI (halimbawa, countdown o carousel), dapat itong itigil kapag itinago ang controller. Ang pagpapatuloy ng timer sa background ay hindi lamang kumukonsumo ng processor resources, ngunit maaari ring magdulot ng exception kapag sinubukang i-update ang hindi nakikitang UI.

class CountdownViewController: UIViewController {
    private var countdownTimer: Timer?
    private var remainingSeconds: Int = 60

    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)
        startTimer()
    }

    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        invalidateTimer()
    }

    private func invalidateTimer() {
        countdownTimer()?.invalidate()
        countdownTimer = nil
    }
}

Pag-pause ng video kapag itinago

Sa maraming application, ang AVPlayer ay nagpe-play ng video sa built-in na player. Kung ang user ay lumipat sa ibang screen, ang video ay dapat na awtomatikong ma-pause. Ang implementasyon sa viewDidDisappear ay ginagarantiya na ang pag-pause ay nangyayari pagkatapos na ganap na maitago ang screen — pinipigilan nito ang pagkislap ng black frame sa transition.

override func viewDidDisappear(_ animated: Bool) {
    super.viewDidDisappear(animated)
    if player().timeControlStatus == .playing {
        player().pause()
        playerLayer().removeFromSuperlayer()
    }
    player = nil
}

Ang pag-zero ng variable na player pagkatapos ng pause ay nagbabakante rin ng memory na inookupahan ng video buffers. Ang approach na ito ay lalong mahalaga para sa mga application na may mahabang video, kung saan ang buffer ay maaaring umabot ng sampu-sampung megabyte. Ang pagsasama ng pause sa pag-zero ng references ay nagpapaliit sa footprint ng application sa background.

viewDidDisappear at iba pang lifecycle method

viewDidDisappear ay madalas na ikinakalito sa viewWillDisappear at deinit, ngunit ang bawat isa sa mga pamamaraang ito ay may kanya-kanyang zone ng responsibilidad. Ang pag-unawa sa mga hangganan sa pagitan nila ay susi sa matatag na arkitektura ng iOS application. Ang maling paggamit ay maaaring humantong sa dobleng pagbabakante ng resources o, salungat, sa kanilang pagtakas.

Ang pangunahing pagkakaiba ng viewDidDisappear mula sa viewWillDisappear — oras ng pagtawag. Ang viewWillDisappear ay tinatawag kapag ang view ay nakikita pa, ngunit naghahanda na mawala. Ito ay angkop para sa pag-save ng nakikitang data (text sa input fields). Ang viewDidDisappear ay tinatawag pagkatapos ng animation, kapag ang view ay garantisadong hindi nakikita — perpekto para sa pagbabakante ng resources na hindi nauugnay sa visual na estado.

deinit, hindi tulad ng viewDidDisappear, ay tinatawag lamang kapag nawasak ang UIViewController object sa memory. Kung ang controller ay itinago lamang (halimbawa, natakpan ng modal window), hindi tinatawag ang deinit. Sa sitwasyong ito, ang viewDidDisappear ay ang tanging punto para magsagawa ng mga pagsasara ng operasyon. Ang buong pagbabakante ng resources ay dapat mangyari sa deinit, ngunit ang viewDidDisappear ay responsable para sa pansamantalang pagbabakante hanggang sa muling paglitaw.

Kailan gagamitin ang aling method

• viewWillDisappear — pag-save ng input data, pagpapadala ng analytics tungkol sa pagsisimula ng transition
• viewDidDisappear — paghinto ng animation, pag-unsubscribe sa notification, pagtatago ng overlay elements
• deinit — huling pagbabakante ng malalaking resources, pagsasara ng network connections

Sa pag-develop gamit ang SwiftUI, ang method na viewDidDisappear ay hindi ginagamit — ito ay pinapalitan ng modifier na .onDisappear na gumagana sa katulad na paraan. Gayunpaman, sa SwiftUI ay walang direktang kontrol sa lifecycle, at ang mga developer ay umaasa sa Combine at State objects para sa pamamahala ng resources. Para sa UIKit applications, ang viewDidDisappear ay nananatiling pangunahing tool para sa pamamahala ng pagtatago ng screen.

Karaniwang pagkakamali sa implementasyon

Kahit na ang mga bihasang iOS developer ay nagkakamali sa pagtatrabaho sa viewDidDisappear. Tingnan natin ang limang pinakakaraniwang problema at paraan upang maiwasan ang mga ito. Ang kaalaman sa mga anti-pattern na ito ay tumutulong upang maiwasan ang mga bug na mahirap subaybayan na may kaugnayan sa lifecycle ng controllers.

• Pag-alis ng super.viewDidDisappear — ang tawag sa super ay sapilitan para sa tamang paggana ng UIKit, ang kawalan nito ay maaaring maging sanhi ng paglabag sa internal na estado ng controller
• Mabibigat na operasyon sa viewDidDisappear — ang sabay-sabay na pagsulat ng malaking data sa viewDidDisappear ay bumabara sa main thread at sumisira sa transition animation
• Nakalimutang pag-unsubscribe sa notification — kung ang removeObserver ay hindi tinawag sa viewDidDisappear, ang handler ay maaaring mag-activate sa zombie object, na nagdudulot ng EXC_BAD_ACCESS
• Dobleng pag-unsubscribe — pag-alis ng observer na natanggal na sa ibang lugar ay humahantong sa exception na NSInternalInconsistencyException
• Pagdepende sa pagkakasunud-sunod ng pagtawag — sa mga nested container, ang pagkakasunud-sunod ng pagtawag ng viewDidDisappear sa child at parent controllers ay hindi garantisado

Ang espesyal na atensyon ay kinakailangan para sa thread safety. Kung ang viewDidDisappear ay tinatawag sa main thread (na ginagarantiya ng UIKit), ngunit ang pagbabakante ng resources ay may kasamang asynchronous na operasyon, ang pag-access sa shared data ay dapat i-synchronize. Ang paggamit ng DispatchQueue.main.async sa loob ng viewDidDisappear para i-update ang UI pagkatapos ng asynchronous task — isang karaniwan ngunit tamang approach.

Isa pang mahalagang anti-pattern — pagtawag ng delegate methods sa loob ng viewDidDisappear na maaaring magpasimula ng bagong transition o modal presentation. Ito ay lumilikha ng isang cycle kung saan ang viewDidDisappear ay maaaring tawagin muli bago matapos ang unang tawag. Inirerekomenda ng Apple na iwasan ang modal presentations sa loob ng lifecycle methods, ilipat ang mga ito sa hiwalay na event handlers.