viewDidDisappear: विधि का सार, UIViewController जीवनचक्र और कब कॉल किया जाता है

viewDidDisappear क्या है?

viewDidDisappear UIViewController सुपरक्लास की एक हुक विधि है जिसे सिस्टम तब कॉल करता है जब व्यू स्क्रीन पर विंडो पदानुक्रम से पूरी तरह हटा दिया जाता है। यह UIKit में मानक व्यू जीवनचक्र का हिस्सा है और डेवलपर को समापन कार्यों को करने के लिए एक बिंदु प्रदान करता है।

यह विधि UIViewController प्रोटोकॉल में घोषित की गई है और सभी उपवर्गों में ओवरराइड करने के लिए उपलब्ध है। विधि का हस्ताक्षर है: override func viewDidDisappear(_ animated: Bool). पैरामीटर animated इंगित करता है कि संक्रमण एनिमेशन के साथ था या नहीं। यह अधिक सटीक व्यवहार नियंत्रण के लिए प्रोग्रामेटिक और एनिमेटेड संक्रमणों के बीच अंतर करने की अनुमति देता है।

viewWillDisappear के विपरीत, जो एनिमेशन शुरू होने से पहले कॉल किया जाता है, viewDidDisappear गारंटी देता है कि व्यू अब उपयोगकर्ता को दिखाई नहीं देता है। यह उन कार्यों के लिए महत्वपूर्ण है जो केवल इंटरफ़ेस पूरी तरह से छिपे होने के बाद ही निष्पादित होने चाहिए — उदाहरण के लिए, पूर्ण-स्क्रीन ओवरले तत्वों को छिपाना या वीडियो रिकॉर्डिंग समाप्त करना।

हस्ताक्षर और घोषणा

यह विधि आधार वर्ग UIViewController में परिभाषित की गई है और इसका निम्न हस्ताक्षर है:

import UIKit

class MyViewController: UIViewController {
    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        // संसाधन मुक्त करना और सदस्यता समाप्त करना
    }
}

कार्यान्वयन की पहली पंक्ति में super.viewDidDisappear(animated) का अनिवार्य कॉल UIKit की आवश्यकता है। इसके बिना, सुपरक्लास व्यू प्रदर्शन से संबंधित आंतरिक प्रक्रियाओं को सही ढंग से पूरा नहीं कर सकता है। इस नियम को अनदेखा करने से अप्रत्याशित नेविगेशन व्यवहार और संभावित क्रैश होते हैं।

UIViewController जीवनचक्र में viewDidDisappear का स्थान

पूर्ण UIViewController जीवनचक्र में छह प्रमुख विधियाँ शामिल हैं, प्रत्येक व्यू के अस्तित्व के एक विशिष्ट चरण के लिए जिम्मेदार है। viewDidDisappear viewWillDisappear के बाद, गायब होने के अनुक्रम को पूरा करता है। संसाधन आवंटन और मुक्ति को ठीक से वितरित करने के लिए सभी विधियों के कॉल क्रम को समझना महत्वपूर्ण है।

व्यू प्रकट होने पर अनुक्रम: viewDidLoad → viewWillAppear → viewDidAppear। छिपाने पर: viewWillDisappear → viewDidDisappear। अंतिम चरण — deinit, जो UIViewController ऑब्जेक्ट नष्ट होने पर कॉल किया जाता है। ये छह विधियाँ एक पूर्ण चक्र बनाती हैं जो पूर्वानुमानित स्थिति प्रबंधन की गारंटी देती हैं।

इनमें से प्रत्येक विधि संबंधित संक्रमण के लिए ठीक एक बार कॉल की जाती है। अपवाद viewDidLoad है, जिसे फिर से कॉल किया जा सकता है यदि संसाधन दबाव के कारण ViewController को मेमोरी से अनलोड किया गया था और फिर पुनर्स्थापित किया गया। ऐसे मामले में, viewDidDisappear बार-बार किए गए viewDidLoad से पहले होगा।

संक्रमण एनिमेशन से संबंध

विधि हस्ताक्षर में पैरामीटर animated इंगित करता है कि संक्रमण एनिमेटेड था या नहीं। यह बिना एनिमेशन के प्रोग्रामेटिक संक्रमणों (उदाहरण के लिए, rootViewController सेट करते समय) और उपयोगकर्ता द्वारा शुरू किए गए एनिमेटेड संक्रमणों के बीच अंतर करने के लिए उपयोगी है। यदि मान false है, तो हो सकता है कि नियंत्रक को सिस्टम द्वारा जबरदस्ती छिपाया गया हो — इस मामले में, कुछ समय-निर्भर संचालन अप्रासंगिक हो सकते हैं।

viewDidDisappear कब कॉल किया जाता है

सिस्टम viewDidDisappear को ठीक दो परिदृश्यों में कॉल करता है: जब ViewController नेविगेशन स्टैक से हटा दिया जाता है और जब यह दूसरे नियंत्रक द्वारा कवर किया जाता है। दोनों मामलों में, विधि संकेत देती है कि व्यू अब उपयोगकर्ता को दिखाई नहीं देता है, और डेवलपर को उन संसाधनों को मुक्त करना चाहिए जो पृष्ठभूमि में आवश्यक नहीं हैं। इन परिदृश्यों को समझना एप्लिकेशन स्थिति के बारे में गलत धारणाओं को रोकता है।

पहला परिदृश्य — UINavigationController से pop. जब उपयोगकर्ता पीछे बटन दबाता है, तो popViewController:animated कॉल किया जाता है। वर्तमान नियंत्रक viewDidDisappear प्राप्त करता है, और फिर, यदि उसके लिए कोई और मजबूत संदर्भ नहीं हैं, तो deinit। दूसरा परिदृश्य — present/dismiss. जब एक नया नियंत्रक मॉडली प्रस्तुत किया जाता है, तो presentingViewController viewDidDisappear प्राप्त करता है। डिसमिस करने पर, यह विधि उस नियंत्रक पर कॉल की जाती है जो मॉडली प्रस्तुत किया गया था।

तीसरा, कम स्पष्ट परिदृश्य — child ViewController जोड़ना. यदि कंटेनर नियंत्रक (उदाहरण के लिए, UIPageViewController या UITabBarController) में एक नया चाइल्ड नियंत्रक जोड़ा जाता है, तो सक्रिय चाइल्ड नियंत्रक viewDidDisappear प्राप्त करता है। यह टैब या पेज कैरोसेल वाले अनुप्रयोगों के लिए महत्वपूर्ण है — प्रत्येक टैब स्विच को निष्क्रिय स्क्रीन के काम को सही ढंग से निलंबित करना चाहिए।

अपवाद और गैर-स्पष्ट मामले

एक महत्वपूर्ण अपवाद है: यदि UIViewController मॉडल विंडो में प्रदर्शित होता है और उपयोगकर्ता नीचे स्वाइप करके इसे इंटरैक्टिव रूप से बंद करता है, तो सिस्टम अधूरे स्वाइप के लिए viewDidDisappear को कॉल नहीं कर सकता है। यह व्यवहार iOS 13 में इंटरैक्टिव डिसमिस के साथ दिखाई दिया। डेवलपर्स को इवेंट प्राप्त करने की गारंटी के लिए UIAdaptivePresentationControllerDelegate और didDismiss विधि के माध्यम से स्थिति को संभालना चाहिए।

एक और विशेषता — मेमोरी चेतावनी. जब मेमोरी कम होती है, तो सिस्टम स्क्रीन पर दिखाई न देने वाले नियंत्रक के व्यू को अनलोड कर सकता है। इस मामले में, viewDidDisappear आमतौर पर अनलोड करने से पहले कॉल किया जाता है, लेकिन डेवलपर को सुरक्षा जाल के रूप में didReceiveMemoryWarning में महत्वपूर्ण सफाई संचालन को दोहराना चाहिए। यह दृष्टिकोण चरम परिदृश्यों में डेटा हानि को रोकता है।

विशिष्ट उपयोग के मामले

viewDidDisappear का उपयोग तीन मुख्य श्रेणियों के संचालन के लिए किया जाता है: गतिविधियों को रोकना, संसाधनों को मुक्त करना और स्थिति सहेजना। प्रत्येक श्रेणी के अपने सर्वोत्तम अभ्यास हैं जो iOS डेवलपर समुदाय द्वारा विकसित किए गए हैं। आइए कार्यान्वयन उदाहरणों के साथ सबसे सामान्य परिदृश्यों को देखें।

• एनिमेशन रोकना — CALayer के लिए layer.removeAllAnimations() कॉल करना, UIView.animate ब्लॉक रोकना
• संसाधन मुक्त करना — बड़ी छवियों को शून्य करना, कैश्ड डेटा साफ़ करना, फ़ाइल डिस्क्रिप्टर बंद करना
• सूचनाओं से सदस्यता समाप्त करना — NotificationCenter.default से प्रेक्षक हटाना, KVO अवलोकन रोकना
• प्रगति सहेजना — संपादन स्क्रीन बंद करते समय CoreData या UserDefaults में ड्राफ्ट लिखना
• ओवरले छिपाना — लोडिंग संकेतक, टूलटिप्स और पॉपओवर तत्वों को हटाना जो संक्रमण के बाद नहीं रहने चाहिए

उदाहरण: NotificationCenter से सदस्यता समाप्त करना

एक सामान्य गलती viewDidLoad में सूचनाओं की सदस्यता लेना और कभी सदस्यता समाप्त न करना है। इससे हैंडलर एक डीलोकेटेड ऑब्जेक्ट पर कॉल हो जाता है, जिससे क्रैश होता है। सही दृष्टिकोण viewWillAppear में सदस्यता लेना और viewDidDisappear में सदस्यता समाप्त करना है, जो सुनिश्चित करता है कि सदस्यता केवल तभी सक्रिय है जब नियंत्रक स्क्रीन पर प्रदर्शित होता है।

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

यह पैटर्न गारंटी देता है कि सूचना हैंडलर केवल तभी सक्रिय है जब नियंत्रक स्क्रीन पर दिखाई देता है। दूसरी स्क्रीन पर नेविगेट करते समय, सभी सदस्यताएँ स्वचालित रूप से हटा दी जाती हैं, और वापस लौटने पर बहाल हो जाती हैं। यह एप्लिकेशन की विश्वसनीयता बढ़ाता है और सूचनाओं से संबंधित बग की एक श्रेणी को समाप्त करता है।

Swift कोड उदाहरण

आइए वास्तविक परियोजनाओं में viewDidDisappear के उपयोग के दो व्यावहारिक उदाहरणों की जाँच करें। पहला उदाहरण स्क्रीन छिपाए जाने पर टाइमर रोकने का प्रदर्शन करता है, दूसरा कीबोर्ड अवलोकन को सही ढंग से समाप्त करने का दिखाता है। दोनों उदाहरण नियंत्रक के निष्क्रिय होने पर संसाधनों को मुक्त करने के सिद्धांत का पालन करते हैं।

टाइमर रोकना

यदि UI को अपडेट करने के लिए स्क्रीन पर Timer चल रहा है (उदाहरण के लिए, काउंटडाउन या कैरोसेल), तो इसे नियंत्रक छिपाए जाने पर रोका जाना चाहिए। पृष्ठभूमि में टाइमर जारी रखना न केवल CPU संसाधनों की खपत करता है बल्कि अदृश्य 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
    }
}

छिपाने पर वीडियो रोकना

कई ऐप्स में, AVPlayer एक अंतर्निर्मित प्लेयर में वीडियो चलाता है। यदि उपयोगकर्ता दूसरी स्क्रीन पर नेविगेट करता है, तो वीडियो स्वचालित रूप से रुकना चाहिए। viewDidDisappear में इसे लागू करना सुनिश्चित करता है कि स्क्रीन पूरी तरह से छिपने के बाद रुकता है — यह संक्रमण के दौरान काले फ्रेम की चमक को रोकता है।

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

रोकने के बाद player चर को शून्य करना वीडियो बफ़र्स द्वारा कब्जा की गई मेमोरी को अतिरिक्त रूप से मुक्त करता है। यह दृष्टिकोण लंबे वीडियो वाले ऐप्स के लिए विशेष रूप से महत्वपूर्ण है, जहां बफ़र दसियों मेगाबाइट ले सकता है। रोकने को संदर्भों को शून्य करने के साथ जोड़ना पृष्ठभूमि में ऐप के पदचिह्न को कम करता है।

viewDidDisappear और अन्य जीवनचक्र विधियाँ

viewDidDisappear अक्सर viewWillDisappear और deinit के साथ भ्रमित होता है, लेकिन इनमें से प्रत्येक विधि की अपनी जिम्मेदारी का क्षेत्र है। उनके बीच की सीमाओं को समझना स्थिर iOS ऐप आर्किटेक्चर की कुंजी है। गलत उपयोग से संसाधनों का दोहरा मुक्ति या, इसके विपरीत, संसाधन लीक हो सकता है।

viewDidDisappear और viewWillDisappear के बीच मुख्य अंतर कॉल का क्षण है। viewWillDisappear तब कॉल किया जाता है जब व्यू अभी भी दिखाई देता है लेकिन गायब होने की तैयारी कर रहा होता है। यह दृश्य डेटा (इनपुट फ़ील्ड में टेक्स्ट) सहेजने के लिए उपयुक्त है। viewDidDisappear एनिमेशन पूरा होने के बाद कॉल किया जाता है, जब व्यू गारंटीकृत रूप से दिखाई नहीं देता है — दृश्य स्थिति से संबंधित नहीं संसाधनों को मुक्त करने के लिए आदर्श।

deinit, viewDidDisappear के विपरीत, केवल तब कॉल किया जाता है जब UIViewController ऑब्जेक्ट मेमोरी में नष्ट होता है। यदि नियंत्रक बस छिपा हुआ है (उदाहरण के लिए, मॉडल विंडो से ढका हुआ है), तो deinit कॉल नहीं किया जाता है। इस स्थिति में, viewDidDisappear समापन कार्यों को करने का एकमात्र बिंदु है। पूर्ण संसाधन सफाई deinit में होनी चाहिए, लेकिन viewDidDisappear अगली उपस्थिति तक अस्थायी मुक्ति संभालता है।

कौन सी विधि कब उपयोग करें

• viewWillDisappear — इनपुट डेटा सहेजना, संक्रमण शुरू होने के बारे में विश्लेषण भेजना
• viewDidDisappear — एनिमेशन रोकना, सूचनाओं से सदस्यता समाप्त करना, ओवरले तत्व छिपाना
• deinit — बड़े संसाधनों की अंतिम मुक्ति, नेटवर्क कनेक्शन बंद करना

SwiftUI के साथ विकास करते समय, viewDidDisappear विधि का उपयोग नहीं किया जाता है — इसे .onDisappear मॉडिफायर द्वारा बदल दिया जाता है जो समान रूप से काम करता है। हालांकि, SwiftUI में प्रत्यक्ष जीवनचक्र नियंत्रण का अभाव है, और डेवलपर संसाधन प्रबंधन के लिए Combine और State ऑब्जेक्ट पर निर्भर करते हैं। UIKit ऐप्स के लिए, viewDidDisappear स्क्रीन गायब होने के प्रबंधन के लिए प्राथमिक उपकरण बना हुआ है।

कार्यान्वयन में सामान्य गलतियाँ

अनुभवी iOS डेवलपर भी viewDidDisappear के साथ काम करते समय गलतियाँ करते हैं। आइए पाँच सबसे सामान्य समस्याओं और उन्हें रोकने के तरीकों की जाँच करें। इन एंटी-पैटर्न को जानने से नियंत्रक जीवनचक्र से संबंधित मुश्किल-से-पकड़ बग से बचने में मदद मिलेगी।

• super.viewDidDisappear का अभाव — UIKit के सही संचालन के लिए super कॉल अनिवार्य है; इसकी अनुपस्थिति नियंत्रक की आंतरिक स्थिति में व्यवधान पैदा कर सकती है
• viewDidDisappear में भारी संचालन — viewDidDisappear में बड़े डेटा का तुल्यकालिक लेखन मुख्य थ्रेड को ब्लॉक करता है और संक्रमण एनिमेशन को ख़राब करता है
• भूली हुई सूचना सदस्यता समाप्ति — यदि viewDidDisappear में removeObserver कॉल नहीं किया जाता है, तो हैंडलर ज़ोंबी ऑब्जेक्ट पर फायर हो सकता है, जिससे EXC_BAD_ACCESS होता है
• दोहरी सदस्यता समाप्ति — एक प्रेक्षक को हटाना जो पहले से कहीं और हटा दिया गया था, NSInternalInconsistencyException की ओर ले जाता है
• कॉल क्रम पर निर्भरता — नेस्टेड कंटेनरों में, चाइल्ड और पैरेंट नियंत्रकों के लिए viewDidDisappear के कॉल क्रम की गारंटी नहीं है

थ्रेड सुरक्षा पर विशेष ध्यान दिया जाना चाहिए। यदि viewDidDisappear मुख्य थ्रेड पर कॉल किया जाता है (जो UIKit द्वारा गारंटीकृत है), लेकिन संसाधन सफाई में अतुल्यकालिक संचालन शामिल हैं, तो साझा डेटा तक पहुंच को सिंक्रनाइज़ किया जाना चाहिए। अतुल्यकालिक कार्य पूरा करने के बाद UI को अपडेट करने के लिए viewDidDisappear के अंदर DispatchQueue.main.async का उपयोग करना एक सामान्य लेकिन सही दृष्टिकोण है।

एक और महत्वपूर्ण एंटी-पैटर्न — viewDidDisappear के अंदर डेलीगेट विधियों को कॉल करना जो एक नया संक्रमण या मॉडल प्रस्तुति शुरू कर सकते हैं। यह एक चक्र बनाता है जहां पहली कॉल पूरी होने से पहले viewDidDisappear फिर से कॉल किया जा सकता है। Apple जीवनचक्र विधियों के अंदर मॉडल प्रस्तुतियों से बचने की सलाह देता है, उन्हें अलग इवेंट हैंडलर में ले जाने की।