2010-06-02 15 views
5

पर संदेश भेजने से पहले जारी किया गया है, मैंने हाल ही में अपने किसी एक ऐप में एक क्रैश देखा है जब किसी ऑब्जेक्ट ने अपने प्रतिनिधि को संदेश देने का प्रयास किया था और प्रतिनिधि पहले से ही जारी कर दिया गया था।यह जांच कर रहा है कि कोई संदेश

फिलहाल, बस किसी भी प्रतिनिधि के तरीकों कॉल करने से पहले, मैं इस जांच चलाने:

if (delegate && [delegate respondsToSelector:...]){ 
    [delegate ...]; 
} 

लेकिन स्पष्ट रूप से यह करता है, तो प्रतिनिधि नहीं के बराबर नहीं है, लेकिन पुनः आवंटित की जाती किया गया है के लिए खाते में नहीं है।

प्रतिनिधि के dealloc विधि में ऑब्जेक्ट के प्रतिनिधि को शून्य करने के अलावा, यह जांचने का एक तरीका है कि क्या प्रतिनिधि पहले ही रिलीज़ हो चुका है या नहीं, अब मुझे ऑब्जेक्ट का संदर्भ नहीं है।

+4

'अगर (प्रतिनिधि)' अनावश्यक है - '[प्रतिनिधि उत्तर देने के लिए चयनकर्ता]]' प्रतिनिधि 'शून्य' होगा। – shosti

+0

दिलचस्प बिंदु। इससे पहले नहीं सोचा था। –

उत्तर

16

नहीं। यह बताए जाने का कोई तरीका नहीं है कि कोई वैरिएबल पॉइंट वैध ऑब्जेक्ट पर है या नहीं। आपको अपने कार्यक्रम को ढूढ़ने की जरूरत है ताकि इस ऑब्जेक्ट का प्रतिनिधि पहले इसे बताने के बिना दूर नहीं जा रहा है।

+2

धन्यवाद। दुर्घटना के बाद से यह ऑब्जेक्ट के प्रतिनिधि को प्रतिनिधि के डीलोक में स्थापित करने का एक साधारण मामला था, लेकिन यह मुझे सामान्य रूप से सोच रहा था :) –

0

प्रत्येक काउंटर का उपयोग करने के बारे में कैसे हर बार जब आप आवंटित करते हैं तो आप हर बार आवंटित करते हैं और कमी करते हैं। इस तरह आप डबल ऑलॉक्स का पता लगा सकते हैं और काउंटर शून्य नहीं होने पर प्रतिनिधि का उपयोग न करने का निर्णय ले सकते हैं लेकिन पता शून्य नहीं है

+0

दुख की बात यह एक अच्छा विचार नहीं है। ऑब्जेक्ट्स अपनी खुद की बरकरार गिनती को ट्रैक करते हैं, इस तरह वे अंतिम रिलीज के बाद "स्वचालित रूप से" हटाए जाते हैं। चूंकि वह प्रतिनिधि को बरकरार नहीं रखता है, यह वास्तव में वैसे भी मदद नहीं करेगा। –

+0

हाँ, यह एक लंबा शॉट था, लेकिन मैं वर्णन करना चाहता था कि कुछ ढांचे –

+0

पर पृष्ठभूमि में संदर्भ और संदर्भण कैसे प्रबंधित किया जाता है, दो साल बाद @tom ने पूछा है कि मुझे यह बहुत उपयोगी लगता है। मैं एक ही परिदृश्य के साथ आया और सबसे अच्छा समाधान मेरी प्रतिनिधि संपत्ति को 'कमजोर' घोषित करना होगा, दुख की बात है कि मुझे इसे पिछड़ा संगत बनाना होगा (आईओएस 4 परिनियोजन लक्ष्यों का भी समर्थन करना चाहिए)। तो मेरा अनुमान है कि प्रतिनिधियों के पैटर्न के बजाय ब्लॉक के साथ जाना है, क्या यह काम करेगा? (मैं पृष्ठभूमि में छवियों को डाउनलोड करने के लिए प्रतिनिधियों का उपयोग करता हूं और इसे पूरा होने के बाद प्रतिनिधि विधि के कॉलबैक का आह्वान करता हूं, मैं ब्लॉक का उपयोग करके भी वही कर सकता हूं। सुनिश्चित नहीं है कि यह हटाए गए ऑब्जेक्ट्स को कॉल करने के पीछे समस्या को हल करेगा) – chathuram

8

मुझे लगता है कि आप जीसी का उपयोग नहीं कर रहे हैं। उस स्थिति में, मानक सम्मेलन यह है कि प्रतिनिधि जो प्रतिनिधि को सेट करता है, प्रतिनिधि को उपयोगकर्ता को nil पर संदर्भित करने के लिए ज़िम्मेदार होता है ताकि प्रतिनिधि को हटा दिया जा सके। यदि आप जीसी का उपयोग कर रहे हैं, तो आप प्रतिनिधि के लिए __weak संदर्भ का उपयोग कर सकते हैं, जिससे कचरा कलेक्टर nil के संदर्भ को सेट करने की अनुमति देता है जब उदाहरण कचरा एकत्र होता है।

+0

+1 '__weak' संदर्भ लाने के लिए +1, और जीसी के संदर्भ में उन्हें अनुशंसा करता है। वास्तव में, कोई तर्क दे सकता है कि इस मामले में '__weak' का उपयोग करना सही बात है, अगर (कब?) कोड अंततः भविष्य में जीसी में स्विच हो जाता है। –

+0

अभी भी विरासत समर्थन के लिए __unsafe_unretained मौजूद है, और यह उपयोग करना बहुत मुश्किल है क्योंकि एआरसी एकत्रित __unsafe_unretained ऑब्जेक्ट्स को शून्य मान निर्दिष्ट नहीं करता है। –

0

डीबग का प्रस्ताव है कि आप अपनी कक्षा में रिलीज विधि को ओवरराइड कर सकते हैं यह देखने के लिए कि इसे कहां कहा जाता है।

-(oneway void)release 
{ 
    NSLog(@"release called"); 
    [super release]; 
} 
संबंधित मुद्दे