viewDidDisappear: esensi metode, siklus hidup UIViewController dan kapan dipanggil

Apa itu viewDidDisappear?

viewDidDisappear — adalah metode hook dari superkelas UIViewController yang dipanggil oleh sistem setelah tampilan (view) benar-benar dihapus dari hierarki jendela di layar. Ini adalah bagian dari siklus hidup standar view di UIKit dan memberikan titik bagi pengembang untuk melakukan operasi penyelesaian.

Metode ini dideklarasikan dalam protokol UIViewController dan tersedia untuk ditimpa di semua subkelas. Signature metode: override func viewDidDisappear(_ animated: Bool). Parameter animated menunjukkan apakah transisi disertai dengan animasi. Ini memungkinkan untuk membedakan transisi terprogram dan beranimasi untuk kontrol perilaku yang lebih tepat.

Tidak seperti viewWillDisappear yang dipanggil sebelum animasi dimulai, viewDidDisappear menjamin bahwa view tidak lagi terlihat oleh pengguna. Ini penting untuk operasi yang hanya boleh dijalankan setelah antarmuka sepenuhnya disembunyikan — misalnya, menyembunyikan elemen overlay layar penuh atau menyelesaikan perekaman video.

Signature dan deklarasi

Metode ini didefinisikan di kelas dasar UIViewController dan memiliki signature berikut:

import UIKit

class MyViewController: UIViewController {
    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        // Membebaskan sumber daya dan berhenti berlangganan
    }
}

Panggilan wajib super.viewDidDisappear(animated) di baris pertama implementasi — ini adalah persyaratan UIKit. Tanpanya, superkelas tidak dapat menyelesaikan proses internal yang terkait dengan tampilan view dengan benar. Mengabaikan aturan ini menyebabkan perilaku navigasi yang tidak dapat diprediksi dan potensi kerusakan.

Posisi viewDidDisappear dalam siklus hidup UIViewController

Siklus hidup lengkap UIViewController terdiri dari enam metode kunci, masing-masing bertanggung jawab atas fase tertentu dari keberadaan view. viewDidDisappear melengkapi urutan penyembunyian, mengikuti viewWillDisappear. Penting untuk memahami urutan panggilan semua metode untuk mendistribusikan inisialisasi dan pembebasan sumber daya dengan benar.

Urutan saat view muncul: viewDidLoad → viewWillAppear → viewDidAppear. Saat menyembunyikan: viewWillDisappear → viewDidDisappear. Fase akhir — deinit, yang dipanggil saat objek UIViewController dihancurkan. Keenam metode ini membentuk siklus lengkap, menjamin manajemen status yang dapat diprediksi.

Masing-masing metode ini dipanggil tepat satu kali untuk transisi yang sesuai. Pengecualian — viewDidLoad, yang dapat dipanggil lagi jika ViewController dibongkar dari memori karena kekurangan sumber daya dan kemudian dipulihkan. Dalam kasus ini, viewDidDisappear akan mendahului viewDidLoad baru.

Hubungan dengan animasi transisi

Parameter animated dalam signature metode menunjukkan apakah transisi dianimasikan. Ini berguna untuk membedakan transisi terprogram tanpa animasi (misalnya, saat mengatur rootViewController) dan transisi beranimasi yang diprakarsai oleh pengguna. Jika nilainya false, mungkin kontroler disembunyikan secara paksa oleh sistem — dalam kasus ini, beberapa operasi yang bergantung pada waktu mungkin tidak relevan.

Kapan viewDidDisappear dipanggil

Sistem memanggil viewDidDisappear tepat dalam dua skenario: ketika ViewController dihapus dari tumpukan navigasi dan ketika ditutupi oleh kontroler lain. Dalam kedua kasus, metode menandakan bahwa view tidak lagi terlihat oleh pengguna dan pengembang harus membebaskan sumber daya yang tidak diperlukan di latar belakang. Memahami skenario ini mencegah asumsi yang salah tentang status aplikasi.

Skenario pertama — pop dari UINavigationController. Saat pengguna menekan tombol “Kembali”, popViewController: animated dipanggil. Kontroler saat ini menerima viewDidDisappear, dan kemudian, jika tidak ada lagi referensi kuat ke sana, deinit. Skenario kedua — present/dismiss. Saat menampilkan kontroler baru secara modal, presentingViewController menerima viewDidDisappear. Saat dismiss, metode ini dipanggil pada kontroler yang ditampilkan secara modal.

Skenario ketiga, yang kurang jelas — menambahkan child ViewController. Jika kontroler anak baru ditambahkan ke kontroler wadah (misalnya, UIPageViewController atau UITabBarController), kontroler anak aktif menerima viewDidDisappear. Ini penting untuk aplikasi dengan tab atau carousel halaman — setiap pergantian tab harus dengan benar menghentikan pekerjaan layar yang tidak aktif.

Pengecualian dan kasus yang tidak jelas

Ada pengecualian penting: jika UIViewController ditampilkan di jendela modal dan pengguna menutupnya secara interaktif dengan menggeser ke bawah, sistem mungkin tidak memanggil viewDidDisappear saat geseran tidak selesai. Perilaku ini muncul di iOS 13 bersama dengan dismiss interaktif. Pengembang harus menangani status melalui UIAdaptivePresentationControllerDelegate dan metode didDismiss untuk menerima jaminan peristiwa.

Fitur lainnya — peringatan memori. Saat kekurangan memori, sistem dapat membongkar view kontroler yang tidak ditampilkan di layar. Dalam kasus ini, viewDidDisappear biasanya dipanggil sebelum pembongkaran, tetapi pengembang harus menduplikasi operasi pembebasan yang sangat penting di didReceiveMemoryWarning untuk keamanan. Pendekatan semacam itu mencegah kehilangan data dalam skenario ekstrem.

Skenario penggunaan tipikal

viewDidDisappear digunakan untuk tiga kategori operasi utama: menghentikan aktivitas, membebaskan sumber daya, dan menyimpan status. Setiap kategori memiliki praktik terbaiknya sendiri yang dikembangkan oleh komunitas pengembang iOS. Mari kita lihat skenario paling umum dengan contoh implementasi.

• Menghentikan animasi — panggilan layer.removeAllAnimations() untuk CALayer, menghentikan blok UIView.animate
• Membebaskan sumber daya — menolkan gambar besar, mereset data cache, menutup deskriptor file
• Berhenti berlangganan notifikasi — menghapus pengamat dari NotificationCenter.default, menghentikan pengamatan KVO
• Menyimpan kemajuan — menulis draf ke CoreData atau UserDefaults saat menutup layar edit
• Menyembunyikan overlay — menghapus indikator pemuatan, tooltip, dan elemen popover yang tidak boleh tersisa setelah transisi

Contoh: berhenti berlangganan dari NotificationCenter

Kesalahan umum — berlangganan notifikasi di viewDidLoad dan tidak pernah berhenti berlangganan. Ini menyebabkan handler dipanggil pada objek yang sudah dihancurkan, yang menyebabkan crash. Pendekatan yang benar — berlangganan di viewWillAppear dan berhenti berlangganan di viewDidDisappear, yang menjamin bahwa langganan hanya aktif selama kontroler ditampilkan di layar.

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)
}

Pola ini menjamin bahwa handler notifikasi hanya aktif ketika kontroler terlihat di layar. Saat beralih ke layar lain, semua langganan secara otomatis dihapus, dan saat kembali dipulihkan. Ini meningkatkan keandalan aplikasi dan menghilangkan kelas bug yang terkait dengan notifikasi.

Contoh kode di Swift

Mari kita lihat dua contoh praktis penggunaan viewDidDisappear di proyek nyata. Contoh pertama menunjukkan penghentian timer saat layar disembunyikan, contoh kedua — penghentian pengamatan keyboard yang benar. Kedua contoh mengikuti prinsip pembebasan sumber daya saat kontroler tidak aktif.

Menghentikan timer

Jika di layar berjalan Timer untuk memperbarui UI (misalnya, hitungan mundur atau carousel), ia harus dihentikan saat kontroler disembunyikan. Melanjutkan kerja timer di latar belakang tidak hanya menghabiskan sumber daya prosesor, tetapi juga dapat menyebabkan pengecualian saat mencoba memperbarui UI yang tidak terlihat.

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
    }
}

Menjeda video saat disembunyikan

Di banyak aplikasi, AVPlayer memutar video di pemutar bawaan. Jika pengguna pergi ke layar lain, video harus secara otomatis dijeda. Implementasi di viewDidDisappear menjamin bahwa jeda terjadi setelah layar sepenuhnya disembunyikan — ini mencegah kedipan bingkai hitam saat transisi.

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

Menolkan variabel player setelah jeda juga membebaskan memori yang ditempati oleh buffer video. Pendekatan ini sangat penting untuk aplikasi dengan video panjang, di mana buffer dapat memakan puluhan megabita. Menggabungkan jeda dengan menolkan referensi meminimalkan jejak aplikasi di latar belakang.

viewDidDisappear dan metode siklus hidup lainnya

viewDidDisappear sering disamakan dengan viewWillDisappear dan deinit, namun masing-masing metode ini memiliki zona tanggung jawabnya sendiri. Memahami batas di antara mereka adalah kunci arsitektur aplikasi iOS yang stabil. Penggunaan yang salah dapat menyebabkan pembebasan sumber daya ganda atau, sebaliknya, kebocoran.

Perbedaan utama viewDidDisappear dari viewWillDisappear — saat pemanggilan. viewWillDisappear dipanggil ketika view masih terlihat tetapi sudah bersiap untuk menghilang. Ini cocok untuk menyimpan data yang terlihat (teks di bidang input). viewDidDisappear dipanggil setelah animasi selesai, ketika view dijamin tidak terlihat — ideal untuk membebaskan sumber daya yang tidak terkait dengan status visual.

deinit, tidak seperti viewDidDisappear, hanya dipanggil saat objek UIViewController dihancurkan di memori. Jika kontroler hanya disembunyikan (misalnya, ditutupi oleh jendela modal), deinit tidak dipanggil. Dalam situasi ini, viewDidDisappear adalah satu-satunya titik untuk melakukan operasi penyelesaian. Pembebasan sumber daya penuh harus terjadi di deinit, tetapi viewDidDisappear bertanggung jawab atas pembebasan sementara sampai kemunculan kembali.

Kapan menggunakan metode mana

• viewWillDisappear — menyimpan data yang dimasukkan, mengirim analitik tentang dimulainya transisi
• viewDidDisappear — menghentikan animasi, berhenti berlangganan notifikasi, menyembunyikan elemen overlay
• deinit — pembebasan akhir sumber daya besar, menutup koneksi jaringan

Dalam pengembangan dengan SwiftUI, metode viewDidDisappear tidak digunakan — digantikan oleh pengubah .onDisappear yang bekerja dengan cara yang sama. Namun, di SwiftUI tidak ada kontrol langsung atas siklus hidup, dan pengembang mengandalkan Combine dan objek State untuk manajemen sumber daya. Untuk aplikasi UIKit, viewDidDisappear tetap menjadi alat utama untuk mengelola penyembunyian layar.

Kesalahan umum dalam implementasi

Bahkan pengembang iOS berpengalaman membuat kesalahan dalam bekerja dengan viewDidDisappear. Mari kita lihat lima masalah paling umum dan cara mencegahnya. Pengetahuan tentang anti-pola ini membantu menghindari bug yang sulit dilacak terkait dengan siklus hidup kontroler.

• Melewatkan super.viewDidDisappear — panggilan super wajib untuk kerja UIKit yang benar, ketiadaannya dapat menyebabkan pelanggaran status internal kontroler
• Operasi berat di viewDidDisappear — penulisan data besar secara sinkron di viewDidDisappear memblokir utas utama dan merusak animasi transisi
• Lupa berhenti berlangganan notifikasi — jika removeObserver tidak dipanggil di viewDidDisappear, handler dapat aktif pada objek zombie, menyebabkan EXC_BAD_ACCESS
• Berhenti berlangganan ganda — menghapus pengamat yang sudah dihapus di tempat lain menyebabkan pengecualian NSInternalInconsistencyException
• Ketergantungan pada urutan panggilan — dalam wadah bersarang, urutan panggilan viewDidDisappear pada kontroler anak dan induk tidak dijamin

Perhatian khusus diperlukan untuk keamanan utas. Jika viewDidDisappear dipanggil di utas utama (yang dijamin oleh UIKit), tetapi pembebasan sumber daya mencakup operasi asinkron, akses ke data bersama harus disinkronkan. Menggunakan DispatchQueue.main.async di dalam viewDidDisappear untuk memperbarui UI setelah tugas asinkron selesai — pendekatan yang umum tetapi benar.

Anti-pola penting lainnya — memanggil metode delegasi di dalam viewDidDisappear yang dapat memulai transisi baru atau tampilan modal. Ini menciptakan siklus di mana viewDidDisappear dapat dipanggil lagi sebelum panggilan pertama selesai. Apple merekomendasikan untuk menghindari tampilan modal di dalam metode siklus hidup, memindahkannya ke penangan peristiwa terpisah.