🙅🏻 ⏳ ◻️ उद्देश्य-सी में केवीओ के छिपे हुए खतरों पर काबू पाना 🐪 🈁 🎶

एक चीज़ के बीच का मुख्य अंतर जो गलत हो सकता है और एक ऐसी चीज़ जो संभवतः गलत नहीं हो सकती है, वह यह है कि जब कोई चीज़ जो संभवतः गलत नहीं हो सकती है वह गलत हो जाती है, तो आमतौर पर यह असंभव हो जाता है कि मरम्मत करना या मरम्मत करना असंभव है।
- डगलस एडम्स

ऑब्जेक्टिव-सी 1983 से है और सी ++ जैसी ही उम्र है। हालांकि, बाद के विपरीत, आईओएस 2.0 के रिलीज के बाद, यह केवल 2008 में लोकप्रियता हासिल करना शुरू हुआ - क्रांतिकारी आईफोन के लिए ऑपरेटिंग सिस्टम का एक नया संस्करण, जिसमें ऐपस्टोर एप्लिकेशन शामिल था, जो उपयोगकर्ताओं को तृतीय-पक्ष डेवलपर्स द्वारा बनाए गए एप्लिकेशन खरीदने की अनुमति देता है।
उद्देश्य सी की निरंतर सफलता न केवल iOS उपकरणों की लोकप्रियता और AppStore के माध्यम से बिक्री के सापेक्ष आसानी से सुनिश्चित की गई, बल्कि मानक पुस्तकालयों और भाषा दोनों को बेहतर बनाने के लिए ऐप्पल के पर्याप्त प्रयासों द्वारा भी।
TIOBE रेटिंग के अनुसार, उद्देश्य-सी ने 2013 की शुरुआत तक लोकप्रियता में C ++ को पीछे छोड़ दिया और सी और जावा के बाद दूसरे स्थान पर रहा।

आज ऑब्जेक्टिव C में KVC और KVO जैसे अपेक्षाकृत पुराने फ़ंक्शंस शामिल हैं, जो पहले iPhone के 4 साल पहले मौजूद थे, और नए फीचर्स जैसे ब्लॉक (Mac OS 10.6 और iOS 4 में पेश किए गए ब्लॉक) और ऑटोमैटिक रेफरेंस काउंटिंग (ARC) , मैक ओएस 10.7 और आईओएस 5 में उपलब्ध है), जो उन समस्याओं को हल करना आसान बनाता है जो पहले गंभीर कठिनाइयों का कारण बने।

केवीओ एक ऐसी तकनीक है जो आपको किसी वस्तु (प्रेक्षक) में तुरंत प्रतिक्रिया करने के लिए किसी अन्य वस्तु (देखे गए) की स्थिति में परिवर्तन करने की अनुमति देती है, बिना देखे गए वस्तु के कार्यान्वयन में पर्यवेक्षक के प्रकार के बारे में ज्ञान का परिचय दिए बिना। केवीओ के साथ ऑब्जेक्टिव-सी में, इस समस्या को हल करने के कई तरीके हैं:

1. प्रत्यायोजन - वस्तु उन्मुख प्रोग्रामिंग का एक सामान्य पैटर्न, इस तथ्य से मिलकर कि वस्तु एक मनमानी वस्तु (जिसे एक प्रतिनिधि कहा जाता है) के लिए एक लिंक पारित किया जाता है जो एक निश्चित प्रोटोकॉल को लागू करता है - चयनकर्ताओं का एक निश्चित सेट। उसके बाद, "मैन्युअल रूप से" ऑब्जेक्ट का कार्यान्वयन प्रतिनिधि को मामले के लिए उपयुक्त संदेश भेजता है। उदाहरण के लिए, UIScrollView स्क्रॉलव्यूडासक्रोल : चयनकर्ता को आमंत्रित करके अपनी सामग्री की संपत्ति के मूल्य में बदलाव के अपने प्रतिनिधि को सूचित करता है।
यह अनुशंसा की जाती है कि सभी प्रोटोकॉल चयनकर्ताओं में से एक पैरामीटर उस ऑब्जेक्ट का संदर्भ बनाता है जो उसे कॉल करता है, ताकि जब एक ही ऑब्जेक्ट एक ही क्लास के कई ऑब्जेक्ट्स का एक प्रतिनिधि हो, तो इसे अलग किया जा सकता है जिसमें से एक संदेश आया था।

2. लक्ष्य-क्रिया । इस तकनीक और प्रतिनिधिमंडल के बीच का अंतर यह है कि एक विशिष्ट प्रोटोकॉल को लागू करने वाले "प्रतिनिधि" के बजाय, इसके चयनकर्ता को इसके साथ पारित किया जाता है, जिसे एक निश्चित घटना होने पर बुलाया जाएगा। इस तकनीक का उपयोग अक्सर UIControl के वंशजों द्वारा किया जाता है, उदाहरण के लिए, एक UISwitch ऑब्जेक्ट को एक लक्ष्य-एक्शन जोड़ी सौंपी जा सकती है जब उपयोगकर्ता इस नियंत्रण (UIControlEventValueChanged इवेंट) को स्विच करता है। ऐसा समाधान प्रतिनिधिमंडल की तुलना में अधिक सुविधाजनक है, इस मामले में जब एक "लक्ष्य" ऑब्जेक्ट को विभिन्न स्रोतों से एक ही घटनाओं का जवाब देना चाहिए (उदाहरण के लिए, कई यूआईस्विच)।

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

4. NSNotificationCenter आपको अलर्ट (NSNotification) भेजने की अनुमति देता है जिसमें एक स्ट्रिंग नाम और किसी भी वर्ग की किसी भी विधि से एक मनमाना वस्तु शामिल है। इस तरह का अलर्ट किसी भी संस्था द्वारा प्राप्त किया जाएगा जो इस नाम और (वैकल्पिक रूप से) एक इकाई के साथ अलर्ट की सदस्यता लेता है। सूचनाओं की सदस्यता को लक्ष्य-कार्रवाई के सिद्धांत या कॉलबैक ब्लॉक का उपयोग करके लागू किया जाता है।
पिछले दृष्टिकोणों के विपरीत, NSNotificationCenter का उपयोग करना वस्तुओं के बीच कमजोर निर्भरता की ओर जाता है और आपको अतिरिक्त प्रयासों के बिना कई वस्तुओं को एक ही चेतावनी पर हस्ताक्षर करने की अनुमति देता है।

5. NSKeyValueObserves NSObject वर्ग में लागू किया गया एक अनौपचारिक प्रोटोकॉल है जो आपको addObserver: forKeyPath: विकल्प: संदर्भ: चयनकर्ता: को कॉल करके निर्दिष्ट ऑब्जेक्ट (ऑब्जर्वेबल) के निर्दिष्ट कुंजी पथ के मान को बदलने के लिए एक मनमाना ऑब्जेक्ट (पर्यवेक्षक) पर हस्ताक्षर करने की अनुमति देता है। उसके बाद, हर बार मूल्य में परिवर्तन होने पर, पर्यवेक्षक को अवलोकन पैटर्न के समान, अवलोकन: परिवर्तन: संदर्भ: संदर्भ: संदेश: संदेश प्राप्त होगा।
इस प्रकार, केवीओ आपको असीमित संख्या में वस्तुओं को न केवल एक विशेषता में परिवर्तन करने की अनुमति देता है, बल्कि प्रेक्षित वस्तु के समग्र कुंजी पथ के मूल्यों में भी होता है, आमतौर पर बिना किसी संशोधन के।

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

मान लीजिए कि हमारे पास शीर्षक और isFiteite विशेषताओं के साथ एक ETRDocument वर्ग है

@interface ETRDocument : NSObject @property (nonatomic, copy) NSString *title; @property (nonatomic) BOOL isFavorite; @end

और हम दस्तावेज़ के बारे में जानकारी प्रदर्शित करने वाले एक सारणीबद्ध सेल को लागू करना चाहते हैं

 @class ETRDocument; @interface ETRDocumentCell : UITableViewCell @property (nonatomic, strong) ETRDocument *document; @property (nonatomic, strong) IBOutlet UILabel *titleLabel; @property (nonatomic, strong) IBOutlet UIButton *isFavoriteButton; - (IBAction)toggleIsFavorite; @end @implementation ETRDocumentCell - (void)updateIsFavoriteButton { self.isFavoriteButton.selected = self.document.isFavorite; } - (void)toggleIsFavorite { self.document.isFavorite = !self.document.isFavorite; [self updateIsFavoriteButton]; } - (void)setDocument:(ETRDocument *)document { _document = document; self.titleLabel.text = self.document.title; [self updateIsFavoriteButton]; } @end

मान लीजिए कि हम पाते हैं कि आइसफ़ाइट का मान न केवल एक बटन दबाकर बदला जा सकता है, बल्कि किसी तरह बाहरी सेल तक भी पहुँचा जा सकता है। यह सेल की उपस्थिति को प्रभावित नहीं करेगा, जिसे तय किया जाना चाहिए। जब परिवर्तन हो रहा हो तो फ़ेवरिटाइट में, हम मैन्युअल रूप से कोशिकाओं को ढूंढ सकते हैं और उन्हें अपडेट करके अपडेट कर सकते हैं ।FavoriteButton, लेकिन यह कक्षाओं के बीच अनावश्यक संचार पैदा करेगा और हमारे सेल के एनकैप्सुलेशन को तोड़ देगा। इसलिए, हम दस्तावेज़ में परिवर्तन के लिए सेल पर ही हस्ताक्षर करने का निर्णय लेते हैं। हम इसे दस्तावेज़ का एक प्रतिनिधि बना सकते हैं, या परिवर्तन होने पर सूचनाएं भेज सकते हैं, लेकिन अगर हम इसके बजाय केवीओ का उपयोग करते हैं, तो हमें दस्तावेज़ वर्ग में कोई बदलाव करने की आवश्यकता नहीं होगी: सभी अतिरिक्त तर्क सेल वर्ग में कूटबद्ध हो जाएंगे।

 - (void)startObservingIsFavorite { [self.document addObserver:self forKeyPath:@"isFavorite" options:0 context:NULL]; } - (void)stopObservingIsFavorite { [self.document removeObserver:self forKeyPath:@"isFavorite"]; } - (void)setDocument:(ETRDocument *)document { [self stopObservingIsFavorite]; _document = document; [self startObservingIsFavorite]; self.titleLabel.text = self.document.title; [self updateIsFavoriteButton]; } - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context { [self updateIsFavoriteButton]; }

लॉन्च - सब कुछ काम करता है, सेल इस्फ़ाइट में बदलाव का जवाब देता है। हम भी toggleIsFavorite से कॉल को अपडेट कर सकते हैं। हालाँकि, आपको तालिका को बंद कर देना चाहिए और दस्तावेज़ में से किसी एक के IsFavorite मान को बदल देना चाहिए, क्योंकि अनुप्रयोग EXC_BAD_ACCESS के साथ क्रैश हो जाता है।
क्या हुआ था? आइए NSZombieEnabled को सक्षम करने और चरणों को दोहराने का प्रयास करें। इस बार गिरने पर हमें एक और सार्थक संदेश मिलेगा:
*** - [ETRDocumentCell रिटेन]: डीलक्लोकेटेड उदाहरण के लिए भेजा गया संदेश 0x8bcda20

दरअसल, केवीओ प्रलेखन को देखते हुए हम निम्नलिखित देखेंगे:
नोट: Add -bserver को देखने वाला मुख्य-मूल्य: forKeyPath: विकल्प: संदर्भ: विधि अवलोकन ऑब्जेक्ट, प्रेक्षित ऑब्जेक्ट्स या संदर्भ के लिए मजबूत संदर्भ नहीं रखता है। आपको यह सुनिश्चित करना चाहिए कि आप अवलोकन के लिए मजबूत संदर्भ बनाए रखें, और अवलोकन किए गए, वस्तुओं और आवश्यक संदर्भ।

अवलोकन पर्यवेक्षक या प्रेक्षित वस्तु के संदर्भ में या संदर्भ के लिए मजबूत संदर्भ नहीं बनाता है। हालाँकि, दस्तावेज़ीकरण इस बारे में चुप है कि इन वस्तुओं में से एक को हटा दिए जाने पर क्या होगा।

केवीओ के लिए संदर्भ सी से एक नियमित सूचक है। यहां तक कि अगर यह एक उद्देश्य-सी वस्तु की ओर इशारा करता है, तो केवीओ इसे इस तरह नहीं मानेगा: यह इसे संदेश नहीं भेजेगा या इसके जीवनकाल को ट्रैक नहीं करेगा। इसलिए, यदि संदर्भ हटा दिया जाता है, तो अवलोकन के लिए एक "हैंगिंग" लिंक पारित किया जाएगा, और इसके माध्यम से एक संदेश पास करने का प्रयास उन लोगों के समान परिणाम देगा। हालाँकि, हमने अपने उदाहरण में संदर्भ का उपयोग नहीं किया। इसके अलावा, यह आगे स्पष्ट हो जाएगा कि संदर्भ का एक अलग "सच" उद्देश्य है।

यदि देखी गई वस्तु नष्ट हो जाती है, तो मॉनिटरिंग को रोकने के बजाय (आखिरकार, कोई मान अब और नहीं बदल सकता है), कंसोल में एक चेतावनी प्रदर्शित की जाएगी:

कक्षा ETRDocument का एक उदाहरण 0xac62490 निपटाया गया था, जबकि प्रमुख मूल्य पर्यवेक्षक अभी भी पंजीकृत थे
इसके साथ। अवलोकन जानकारी लीक हो गई थी, और यहां तक कि गलती से किसी अन्य वस्तु से जुड़ी हो सकती है।
यहां डिबगर में रुकने के लिए NSKVODeallocateBreak पर एक विराम बिंदु सेट करें। यहाँ वर्तमान अवलोकन जानकारी है:
<NSKeyValueObservationInfo 0xaaa77e0> (
<NSKeyValueObservance 0xaaa77a0: ऑब्जर्वर: 0xaaa2100, मुख्य पथ: isFavorite, विकल्प:
<नया: नहीं, पुराना: नहीं, पूर्व: नहीं> संदर्भ: 0x0, संपत्ति: 0xabf12e0>
)

जिसके बाद आवेदन अप्रत्याशित तरीके से व्यवहार करेगा, और जल्द या बाद में दुर्घटनाग्रस्त हो जाएगा। हालाँकि, हमारे मामले में, सेल देखे गए ऑब्जेक्ट का एक मजबूत संदर्भ संग्रहीत करता है, और सेल को हटाए जाने से पहले इसे हटाया नहीं जा सकता है।

यदि पर्यवेक्षक को हटा दिया जाता है, तो KVO इसे "हैंगिंग" लिंक (जो ARC शब्दावली में असुरक्षित_सुधार संशोधक से मेल खाती है) से बचाएगा, और परिवर्तन होने पर उस पर संदेश भेजेगा। हमारे उदाहरण में ठीक यही होता है। यह संभव है कि भविष्य के संस्करणों में "असुरक्षित_सुंदर" के व्यवहार को एक अधिक सुरक्षित "कमजोर" द्वारा बदल दिया जाएगा, और पर्यवेक्षकों के "फांसी" लिंक स्वचालित रूप से रीसेट हो जाएंगे।
इस क्रैश को ठीक करने के लिए, डीलक्लॉक से केवल stopObservesIsFavorite को कॉल करें।

हमारे सेल के तर्क को सरल बनाने का एक तरीका है। दस्तावेज़ के मुख्य पथ "फ़ॉरफ़ाइट" का अवलोकन करने के बजाय, सेल स्वयं पर मुख्य पथ "document.isFavorite" का निरीक्षण कर सकता है। नतीजतन, सेल को दोनों को अधिसूचित किया जाएगा जब लिंक किए गए दस्तावेज़ में isFavorite विशेषता बदल जाती है, और जब दस्तावेज़ के लिए इसका लिंक बदल जाता है। इस मामले में, अभी भी डील ऑवर से रिमूवर को कॉल करना आवश्यक है, लेकिन हर बार जब आप वर्तमान दस्तावेज़ को बदलते हैं, तो आपको रोकने और निगरानी शुरू करने की आवश्यकता नहीं है।
आप आगे जा सकते हैं और न केवल निरीक्षण कर सकते हैं, बल्कि शीर्षक भी देख सकते हैं। यह हमें ओवरडाइडिंग से बचा सकता है: लेकिन यह अभी तक एक और KVO असुविधा में चलेगा:

 @implementation ETRDocumentCell - (void)awakeFromNib { [super awakeFromNib]; [self addObserver:self forKeyPath:@"document.isFavorite" options:0 context:NULL]; [self addObserver:self forKeyPath:@"document.title" options:0 context:NULL]; } - (void)dealloc { [self removeObserver:self forKeyPath:@"document.isFavorite"]; [self removeObserver:self forKeyPath:@"document.title"]; } - (void)toggleIsFavorite { self.document.isFavorite = !self.document.isFavorite; } - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context { if ([keyPath isEqualToString:@"document.isFavorite"]) { self.isFavoriteButton.selected = self.document.isFavorite; } else if ([keyPath isEqualToString:@"document.title"]) { self.titleLabel.text = self.document.title; } } @end

एक पुरानी (लेकिन बहुत तरह की नहीं) दो अन्य स्थानों में नकल किए गए तार की तुलना के साथ एक विधि में मामलों का विश्लेषण। यह न केवल बदसूरत है, बल्कि किसी अन्य "कॉपी-पेस्ट" की तरह त्रुटियों से भी भरा हुआ है।

हम इस पर रोक लगा सकते हैं, उम्मीद करते हैं कि कुछ भी बुरा नहीं होगा, और सब कुछ काम करेगा। और अब यह वास्तव में काम करेगा। लेकिन जल्दी या बाद में, कुछ बुरा अभी भी हो सकता है, और डीबगर में कुछ घंटों के बाद, हम आश्वस्त हो जाएंगे कि केवीओ के साथ गड़बड़ न करना बेहतर है।
क्या हो सकता है? आइए अपने उदाहरण को थोड़ा जटिल करें, और मान लें कि हमने अपने दस्तावेज़ों को प्रदर्शित करने के लिए एक और तालिका बनाने का फैसला किया, लेकिन थोड़ी और "परिष्कृत" कोशिकाओं के साथ, जिसमें दस्तावेज़ शीर्षक और समान बटन भी होंगे, लेकिन अन्य परिवर्तनों के साथ पृष्ठभूमि का रंग बदल जाएगा इस पर निर्भर करता है कि दस्तावेज़ चुना गया है या नहीं।
ताकि पहले से किया गया कार्य व्यर्थ न हो, हम पुराने से एक नया सेल प्राप्त करने का निर्णय लेते हैं।
और सेल की पृष्ठभूमि बदलने के लिए, हम उसी KVO तकनीक का उपयोग करते हैं:

 @implementation ETRAdvancedDocumentCell - (void)awakeFromNib { [super awakeFromNib]; [self addObserver:self forKeyPath:@"document.isFavorite" options:0 context:NULL]; } - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context { [self updateBackgroundColor]; } ...

महान, पृष्ठभूमि रंग बदलती है। लेकिन बटन ने हाइलाइट करना बंद कर दिया, शीर्षक अपडेट करना बंद कर दिया, और अपडेटबैकग्राउंडकोलर को बहुत बार कहा जाता है। जाहिर है, ETRAdvancedDocumentCell को ऑब्ज़र्ववैलफॉरकेईपैथ संदेश प्राप्त होता है जो अपने स्वयं के अवलोकन और ETRDocumentCell दोनों टिप्पणियों से संबंधित है। इस दस्तावेज में क्या लिखा है? एक उदाहरण के कोड के अंदर टिप्पणी में हम निम्नलिखित पंक्तियों को पाते हैं :
सुपरक्लास के कार्यान्वयन को कॉल करना सुनिश्चित करें * यदि यह इसे लागू करता है *।
NSObject विधि को लागू नहीं करता है।

बेशक, हम जानते हैं कि ETRDocumentCell लागू होते हैंवैल्यू फ़ॉरकेथ, जिसका अर्थ है कि कॉल करने की आवश्यकता है
[सुपर ओवरवैल्यूफ़ोरकेपैथ: कीपथ ऑफ़ऑबजेक्ट: ऑब्जेक्ट चेंज: चेंज संदर्भ: संदर्भ] ETRAdvancedDocumentCell से।

लेकिन सब कुछ माता-पिता वर्ग से कार्यान्वयन को कॉल करने तक सीमित नहीं है। आपको उन परिवर्तनों को संसाधित करना चाहिए जो ETRAdvancedDocumentCell ने खुद को सब्सक्राइब किया है और मूल वर्ग में केवल अन्य परिवर्तन पास करते हैं। जाहिर है, की -पैथ और ऑब्जेक्ट के मूल्यों की जांच करना पर्याप्त नहीं है: मूल कक्षा को एक ही ऑब्जेक्ट (स्वयं) के बिल्कुल एक ही keyPath (document.isFavorite) की सदस्यता दी जाती है। यह वह जगह है जहाँ संदर्भ तर्क का "सही" उद्देश्य दिखाई देता है।

 static void* ETRAdvancedDocumentCellIsFavoriteContext = &ETRAdvancedDocumentCellIsFavoriteContext; @implementation ETRAdvancedDocumentCell - (void)awakeFromNib { [super awakeFromNib]; [self addObserver:self forKeyPath:@"document.isFavorite" options:0 context:ETRAdvancedDocumentCellIsFavoriteContext]; } - (void)dealloc { [self removeObserver:self forKeyPath:@"document.isFavorite" context:ETRAdvancedDocumentCellIsFavoriteContext]; } - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context { if (context == ETRAdvancedDocumentCellIsFavoriteContext) { [self updateBackgroundColor]; } else { [super observeValueForKeyPath:keyPath ofObject:object change:change context:context]; } } ...

ETRAdvancedDocumentCellIsFavoriteContext स्टैटिक वैरिएबल में मेमोरी के एक निश्चित क्षेत्र के लिए एक पॉइंटर होता है जिसमें उसका अपना पता होता है। यह इस तरह से घोषित सभी चर के लिए विभिन्न मूल्यों की गारंटी देता है।

जाहिर है, संदर्भ के संकेत के साथ निगरानी को भी रोका जाना चाहिए। यह उत्सुक है कि संबंधित विधि केवल iOS 5 में जोड़ी गई थी, और इससे पहले केवल संदर्भ तर्क के बिना एक विकल्प था। इसने अन्य मापदंडों द्वारा अप्रत्यक्ष रूप से टिप्पणियों में से एक को सही ढंग से समाप्त करना असंभव बना दिया।

लेकिन ETRDocumentCell के बारे में क्या: क्या मुझे इससे सुपर कॉल करने की आवश्यकता है? क्या UITableViewCell वर्ग ओवरव्यू लागू करता हैForKeyPath चयनकर्ता? आप परीक्षण और त्रुटि का सहारा ले सकते हैं, सुपर को कॉल करने का प्रयास कर सकते हैं, अपवाद के साथ अपेक्षित ड्रॉप प्राप्त कर सकते हैं

*** अनकैप्ड अपवाद 'NSInternalInconsistencyException' के कारण समाप्ति ऐप,
कारण: '<ETRDocumentCell: 0x8d3c540; baseClass = UITableViewCell;
फ्रेम = (0 0; 320 64); autoresize = डब्ल्यू; परत = <CALayer: 0x8d3c730 >>:
An -oberveValueForKeyPath: OfObject: परिवर्तन: संदर्भ: संदेश प्राप्त हुआ था, लेकिन संभाला नहीं गया था।
मुख्य पथ: document.title
देखे गए ऑब्जेक्ट: <ETRDocumentCell: 0x8d3c540; baseClass = UITableViewCell;
फ्रेम = (0 0; 320 64); autoresize = डब्ल्यू; परत = <CALayer: 0x8d3c730 >>
बदलें: {
दयालु = 1;
}
संदर्भ: 0x0 '
*** पहले फेंक कॉल ढेर:
(
0 CoreFoundation 0x0173b5e4 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x014be8b6 objc_exception_throw + 44
2 CoreFoundation 0x0173b3bb + [NSException बढ़ाएँ: प्रारूप:] + 139
3 फाउंडेशन 0x0118863f - [NSObject (NSKeyValueObserves) अवलोकन करेंव्यूफ़ोरकेपैथ: विषय: परिवर्तन: संदर्भ:] + 94
4 ETRKVO 0x00002e35 - [ETRDocumentCell अवलोकनValueForKeyPath: विषय: परिवर्तन: संदर्भ:] + 229
5 फाउंडेशन 0x0110d8c7 NSKeyValueNotifyObserver + 362
6 फाउंडेशन 0x0110f206 NSKeyValueDidChange + 458
...

और कॉल वापस निकालें। लेकिन इस बात की क्या गारंटी है कि अगले संस्करण में ओवरव्यू फ़ोरकाइपैथ को लागू करने के लिए मूल वर्ग शुरू नहीं होगा (या इसके विपरीत)? यहां तक कि अगर आप स्वयं अभिभावक वर्ग को लागू करते हैं, तो आप बच्चे की कक्षाओं में सुपर कॉल जोड़ने या हटाने के लिए भूल जाते हैं। सबसे विश्वसनीय समाधान रनटाइम पर एक उचित जांच करना होगा। ऐसा बिल्कुल भी नहीं किया जाता है, [सुपर रेस्पोंडॉटसेलेक्टर: ...], जो हमेशा यस लौटाता है, क्योंकि हमारी कक्षा रिस्पॉन्ड्सटाइटर को ओवरराइड नहीं करती है: और इसे सुपर पर कॉल करना स्वयं को कॉल करने जैसा है। यह थोड़ी लंबी अभिव्यक्ति का उपयोग करके किया जाता है [[ETRDocumentCell superclass] instancesRespondToSelector: ...]। लेकिन जैसा कि यह पता चला है, प्रलेखन हमें धोखा दे रहा है, और [[NSObject वर्ग] instancesRespondToSelector: @selector (ओवरव्यू देखें): TheObject का: परिवर्तन: संदर्भ :)] रिटर्न YES, और संबंधित कार्यान्वयन उपरोक्त अपवाद के लिए केवल एक ही जिम्मेदार है। यह पता चला है कि हमारे पास दो विकल्प हैं: या तो कभी भी सुपर कॉल न करें और अभिभावक वर्ग के तर्क को तोड़ दें, या केवल उन टिप्पणियों के लिए सुपर कॉल करें, जो हमारे कोड द्वारा कॉल किए जाने की गारंटी नहीं हैं, अपवाद होने के जोखिम पर, कुछ अतिशयोक्ति को छोड़ दें।

 static void* ETRDocumentCellIsFavoriteContext = &ETRDocumentCellIsFavoriteContext; static void* ETRDocumentCellTitleContext = &ETRDocumentCellTitleContext; @implementation ETRDocumentCell - (void)awakeFromNib { [super awakeFromNib]; [self addObserver:self forKeyPath:@"document.isFavorite" options:0 context:ETRDocumentCellIsFavoriteContext]; [self addObserver:self forKeyPath:@"document.title" options:0 context:ETRDocumentCellTitleContext]; } - (void)dealloc { [self removeObserver:self forKeyPath:@"document.isFavorite" context:ETRDocumentCellIsFavoriteContext]; [self removeObserver:self forKeyPath:@"document.title" context:ETRDocumentCellTitleContext]; } - (void)toggleIsFavorite { self.document.isFavorite = !self.document.isFavorite; } - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context { if (context == ETRDocumentCellIsFavoriteContext) { self.isFavoriteButton.selected = self.document.isFavorite; } else if (context == ETRDocumentCellTitleContext) { self.titleLabel.text = self.document.title; } else { [super observeValueForKeyPath:keyPath ofObject:object change:change context:context]; } } @end

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

*** अनकहा अपवाद 'NSRangeException' के कारण समाप्ति एप्लिकेशन,
कारण: 'प्रेक्षक <ETRAdvancedDocumentCell 0x1566cdd0> को नहीं हटा सकता
मुख्य पथ "document.title" के लिए <ETRAdvancedDocumentCell 0x1566cdd0> से
क्योंकि यह पर्यवेक्षक के रूप में पंजीकृत नहीं है। '

आप अक्सर UIViewControllers पा सकते हैं जो किसी एक तरीके ViewDidLoad, vewDidUnload, viewWillAppear, viewDidAppear, viewWillAppisappear या viewDidDisappear के कार्यान्वयन के अंदर एक पर्यवेक्षक के रूप में खुद को जोड़ते हैं, और इनमें से किसी अन्य तरीके को देखना बंद कर देते हैं। हालांकि, कोई भी इन कॉलों के सख्त मिलान की गारंटी नहीं देता है, खासकर जब कस्टम कंटेनर व्यू कंट्रोलर्स का उपयोग करते हुए, विशेष रूप से कंधे के सहारे के साथ। विशेष रूप से, UINavigationController स्टैक में निहित नियंत्रकों के लिए इन कॉलों का तर्क आईओएस 7 में नेविगेशन स्टैक के माध्यम से पीछे की ओर जाने के लिए एक इंटरैक्टिव इशारा की शुरूआत के साथ बदल गया है। और अवलोकन के रूप में पारित वस्तु के संदर्भ इन कॉलों के बीच बदल सकते हैं।
परिणामस्वरूप, कुछ डेवलपर्स गंभीरता से निम्नलिखित जैसे समाधानों का उपयोग करने का सुझाव देते हैं :

 @try { [self.document removeObserver:self forKeyPath:@"isFavorite" context:DocumentCellIsFavoriteContext]; } @catch (NSException *exception) {}

जब मुझे ऐसा कुछ दिखाई देता है, तो मुझे याद आता है कि बचपन में मैंने Visual Basic में "ऑन एरर रिज्यूमे नेक्स्ट" लाइन कैसे लिखी थी, और मेरी "कृतियों" को चमत्कारिक रूप से गिरना बंद हो गया था।

उन सभी से जो लिखा गया है, यह निम्नानुसार है कि केवीओ एक बहुत शक्तिशाली तकनीक है, जिसकी पहुंच हमारे पास एक एपीआई के माध्यम से है जो न केवल असुविधाजनक है, बल्कि इसका उपयोग करने वाले अनुप्रयोगों के लिए भी घातक है। प्रोग्रामिंग के क्षेत्र में ऐसी स्थितियां असामान्य नहीं हैं, और उनमें से एक निश्चित तरीका एक अधिक सुविधाजनक और सुरक्षित इंटरफ़ेस लिखना है जो इसके कार्यान्वयन के भीतर सभी कमियों को अलग और बेअसर करता है।

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

इन विचारों से यह निम्नानुसार है कि KVO के अधिक विश्वसनीय उपयोग के लिए, प्रत्येक अवलोकन के लिए एक अलग वस्तु बनाने के लिए, अर्थात् प्रत्येक व्यक्ति अवलोकन को पहचान देना आवश्यक है। मानक KVO इंटरफ़ेस के संदर्भ में एक ही ऑब्जेक्ट एक पर्यवेक्षक होना चाहिए। वास्तव में एक वस्तु के ठीक एक कीपाथ का अवलोकन करके, और इस अवलोकन को स्पष्ट रूप से अपने जीवनकाल से जोड़कर, इस वस्तु को ऊपर वर्णित खतरों से मज़बूती से संरक्षित किया जाएगा। जब देखे गए मूल्य में बदलाव के बारे में एक संदेश प्राप्त होता है, तो वह केवल यही करेगा कि लेख की शुरुआत में इंगित पहले तीन तरीकों में से एक द्वारा किसी अन्य वस्तु को सूचित किया जाए।
आइए ऐसी वस्तु को कार्यान्वित करने का प्रयास करें:

 @interface ETRKVO : NSObject @property (nonatomic, unsafe_unretained, readonly) id subject; @property (nonatomic, copy, readonly) NSString *keyPath; @property (nonatomic, copy) void (^block)(ETRKVO *kvo, NSDictionary *change); - (id)initWithSubject:(id)subject keyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options block:(void (^)(ETRKVO *kvo, NSDictionary *change))block; - (void)stopObservation; @end static void* ETRKVOContext = &ETRKVOContext; @implementation ETRKVO - (id)initWithSubject:(id)subject keyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options block:(void (^)(ETRKVO *kvo, NSDictionary *change))block { self = [super init]; if (self) { _subject = subject; _keyPath = [keyPath copy]; _block = [block copy]; [subject addObserver:self forKeyPath:keyPath options:options context:ETRKVOContext]; } return self; } - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context { if (context == ETRKVOContext) { if (self.block) self.block(self, change); } // NSObject does not implement observeValueForKeyPath } - (void)stopObservation { [self.subject removeObserver:self forKeyPath:self.keyPath context:ETRKVOContext]; _subject = nil; } - (void)dealloc { [self stopObservation]; } @end

वैकल्पिक समाधान ReactiveCocoa लाइब्रेरी में पाया जा सकता है, जो उद्देश्य-सी में प्रोग्रामिंग प्रतिमान को मौलिक रूप से स्थानांतरित करने का दावा करता है, और कुछ हद तक पुराने MAKVONotificationCenter में ।
इसके अलावा, NSNotificationCenter: iOS 4 में इसी तरह के कारणों के लिए समान परिवर्तन किए गए थे, addObserverForName: ऑब्जेक्ट: कतार: usingBlock : पद्धति को जोड़ा गया था, जो एक वस्तु को रिटर्न करता है जो अधिसूचना सदस्यता की पहचान करता है।

ETRKVO इंटरफ़ेस को विकल्पों के व्यवहार को देखकर और तर्कों को बदलकर सरल बनाया जा सकता है।
NSKeyValueObservesOptions एक बिटमास्क है जो निम्नलिखित झंडे को संयोजित कर सकता है:

NSKeyValueObservingOptionNew
NSKeyValueObservingOptionOld
NSKeyValueObservingOptionInitial
NSKeyValueObservingOptionPrior

पहले दो संकेत देते हैं कि देखे गए विशेषता के पुराने और नए मूल्य परिवर्तन तर्क में मौजूद होने चाहिए। यह मामूली मंदी को छोड़कर, कोई नकारात्मक परिणाम नहीं दे सकता है।
निर्दिष्ट NSKeyValueObservesOptionInitial कारणों में ऑब्जरवैल्यू फ़ोरकेयपाथ को तुरंत बुलाया जाता है जब एक अवलोकन जोड़ा जाता है, जो आम तौर पर बोल रहा है, बेकार है।
NSKeyValueObservesOptionPyer को निर्दिष्ट करने से obserValueForKeyPath को न केवल मूल्य बदलने के बाद, बल्कि इसके पहले भी कहा जाता है। हालाँकि, नया मान प्रेषित नहीं किया जाएगा, भले ही NSKeyValueObservesOptionNew ध्वज निर्दिष्ट किया गया हो। इसके लिए आवश्यकता को शायद ही कभी पूरा किया जा सकता है, और सबसे अधिक संभावना है कि यह केवल "बैसाखी" को लागू करने की प्रक्रिया में उत्पन्न होता है।
इसलिए, आप हमेशा विकल्प (NSKeyValueObservesOptionNew | NSKeyValueObservesOptionOld) के रूप में पास कर सकते हैं।

तर्क (NSDictionary *) परिवर्तन में निम्नलिखित कुंजियाँ हो सकती हैं:

NSKeyValueChangeNewKey
NSKeyValueChangeOldKey
NSKeyValueChangeKindKey
NSKeyValueChangeIndexesKey
NSKeyValueChangeNotificationIsPriorKey

पहले दो में वही पुराने और नए मूल्य हैं जो संबंधित विकल्पों द्वारा अनुरोध किए जा सकते हैं। स्केलर प्रकार के मान NSNumber या NSValue में लिपटे होते हैं, और नील की बजाय सिंगलटन ऑब्जेक्ट [NSNull null] को स्थानांतरित किया जाता है।
एक उत्परिवर्तित संग्रह का अवलोकन करते समय निम्नलिखित दो की आवश्यकता होती है, जो कि एक बुरा विचार है।
अंतिम कुंजी केवल NSKeyValueObservesOptionPption विकल्प के साथ किए गए पूर्ववर्ती परिवर्तन कॉल के मामले में प्रेषित की जाती है।
इसलिए, आप केवल कुंजी NSKeyValueChangeNewKey और NSKeyValueChangeOldKey पर विचार कर सकते हैं, और विस्तारित रूप में उनके मूल्यों को ब्लॉक कर सकते हैं।
इसलिए, ETRKVO को निम्नानुसार बदला जा सकता है:

 - (id)initWithSubject:(id)subject keyPath:(NSString *)keyPath block:(void (^)(ETRKVO *kvo, id oldValue, id newValue))block { self = [super init]; if (self) { _subject = subject; _keyPath = [keyPath copy]; _block = [block copy]; [subject addObserver:self forKeyPath:keyPath options:(NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld) context:ETRKVOContext]; } return self; } - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context { if (context == ETRKVOContext) { if (self.block) { id oldValue = change[NSKeyValueChangeOldKey]; if (oldValue == [NSNull null]) oldValue = nil; id newValue = change[NSKeyValueChangeNewKey]; if (newValue == [NSNull null]) newValue = nil; self.block(self, oldValue, newValue); } } // NSObject does not implement observeValueForKeyPath }          NSObject,    : - (ETRKVO *)observeKeyPath:(NSString *)keyPath withBlock:(void (^)(ETRKVO *kvo, id oldValue, id newValue))block;

चूँकि कीपाथ प्रायः एक संपत्ति का नाम होता है जो संबंधित गॉटर से मेल खाता है, इसलिए कीपथ स्ट्रिंग के बजाय इस गेटर के चयनकर्ता का उपयोग करना अधिक सुविधाजनक होता है। इस मामले में, स्वत: पूर्णता काम करेगी, और यह लिखते समय या संपत्ति का नाम बदलने पर गलती करने की संभावना कम होगी।

 - (ETRKVO *)observeSelector:(SEL)selector withBlock:(void (^)(ETRKVO *kvo, id oldValue, id newValue))block { return [[ETRKVO alloc] initWithSubject:self keyPath:NSStringFromSelector(selector) block:block]; }

इस वर्ग और श्रेणी का उपयोग करके हमारी कोशिकाओं को फिर से लिखें

 @interface ETRDocumentCell () @property (nonatomic, strong) ETRKVO* isFavoriteKVO; @property (nonatomic, strong) ETRKVO* titleKVO; @end @implementation ETRDocumentCell - (void)awakeFromNib { [super awakeFromNib]; typeof(self) __weak weakSelf = self; self.isFavoriteKVO = [self observeKeyPath:@"document.isFavorite" withBlock:^(ETRKVO *kvo, id oldValue, id newValue) { weakSelf.isFavoriteButton.selected = weakSelf.document.isFavorite; }]; self.titleKVO = [self observeKeyPath:@"document.title" withBlock:^(ETRKVO *kvo, id oldValue, id newValue) { weakSelf.titleLabel.text = weakSelf.document.title; }]; } - (void)dealloc { [self.isFavoriteKVO stopObservation]; [self.titleKVO stopObservation]; } - (void)toggleIsFavorite { self.document.isFavorite = !self.document.isFavorite; } @end @interface ETRAdvancedDocumentCell () @property (nonatomic, strong) ETRKVO* advancedIsFavoriteKVO; @end @implementation ETRAdvancedDocumentCell - (void)awakeFromNib { [super awakeFromNib]; typeof(self) __weak weakSelf = self; self.advancedIsFavoriteKVO = [self observeKeyPath:@"document.isFavorite" withBlock:^(ETRKVO *kvo, id oldValue, id newValue) { [weakSelf updateBackgroundColor]; }]; } - (void)dealloc { [self.advancedIsFavoriteKVO stopObservation]; } ...

एक उदाहरण के साथ ETRKVO का पूर्ण कार्यान्वयन यहां डाउनलोड किया जा सकता है।

स्मृति लीक को रोकने के लिए यहां केवल गैर-स्पष्ट चाल का उपयोग कमजोर है। यदि ब्लॉक एक मजबूत लिंक द्वारा स्वयं पर कब्जा कर लिया है, तो एक मजबूत लिंक चक्र बन जाएगा: ETRDocumentCell → isFavoriteKVO → ब्लॉक → ETRDocumentCell। हालांकि, यदि आप सक्रिय रूप से ब्लॉक का उपयोग कर रहे हैं, तो कमजोर लिंक का उपयोग करने वाले ऑब्जेक्ट्स को कैप्चर करना आपके लिए पहले से ही एक आदत बन जाना चाहिए।

यह ध्यान देने योग्य है कि हालांकि ETRKVO वर्ग की वस्तुओं को कोशिकाओं द्वारा उनके संदर्भ खो देने के बाद हटा दिया जाता है (वे स्वयं हटा दिए जाते हैं), और जब लिंक की गिनती होती है तो कचरा संग्रह की प्रतीक्षा करने जैसे कोई प्रभाव नहीं होते हैं, फिर भी लिंक ऑटोरेलिज़ में होने पर तुरंत नष्ट नहीं हो सकता है। पूल।इसलिए, आपको हमेशा ETRKVO से पहले मैन्युअल रूप से stopObservation को कॉल करना चाहिए या ऑब्‍जेक्‍ट की गई वस्तु को हटा दिया जाना चाहिए। विभिन्न अवलोकनों के अनुक्रम के लिए एक ही संपत्ति का उपयोग करते समय, इसके सेटर में स्टॉपऑब्जर्वेशन को कॉल करना सुविधाजनक है।

 - (void)setIsFavoriteKVO:(ETRKVO *)isFavoriteKVO { [_isFavoriteKVO stopObservation]; _isFavoriteKVO = isFavoriteKVO; } - (void)dealloc { self.isFavoriteKVO = nil; }

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

यह नहीं भूलना चाहिए कि परिवर्तन हैंडलर निष्पादन के उसी धागे में कहा जाता है जिसमें परिवर्तन होता है। वस्तु है, जो एक और धागे से बदला जा सकता है, जायज़, और सूत्रण के लिए तुच्छ संबंध की नहीं एक परिणाम के अवलोकन, तो हैंडलर कोड आम तौर पर में लिपटे किया जाना चाहिए dispatch_async। इस मामले में, आपको इस तथ्य पर विशेष ध्यान देना चाहिए कि बाहरी ब्लॉक मजबूत लिंक द्वारा कड़ाई से परिभाषित धारा से संबंधित वस्तुओं (उदाहरण के लिए, UIView, UIViewController या NSManagedObject) पर कब्जा नहीं करता है, क्योंकि इससे तथाकथित डीललोकेशन समस्या हो सकती है ।

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

यहां तक कि केवीओ के सभी संभावित खतरों से अवगत होने और उनमें से कुछ को बेअसर करने के बाद, आपको किसी भी स्थिति में केवीओ का उपयोग नहीं करना चाहिए। किसी भी तकनीक का दुरुपयोग "[प्रौद्योगिकी नाम] नरक" नामक एक घटना की ओर जाता है। यद्यपि केवीओ का उपयोग करके बनाई गई वस्तुओं के बीच संबंध बहुत कमजोर दिखते हैं, नियंत्रण से बाहर निकलते हुए, वे वास्तव में चोट पहुंचा सकते हैं। हमारे मामले में, "केवीओ नरक" को अवलोकन प्रोसेसर के अप्रत्याशित हिमस्खलन की तरह ट्रिगर में व्यक्त किया जा सकता है, जिससे अप्रत्याशित परिणाम हो सकते हैं और प्रदर्शन को मार सकते हैं, या यहां तक कि चक्रीय अतिप्रवाह में समाप्त होने वाले चक्रीय कॉल में भी।

उद्देश्य-सी में केवीओ के छिपे हुए खतरों पर काबू पाना

More articles: