क्या IBOutlets ARC के तहत मजबूत या कमजोर होना चाहिए?

551

मैं एआरसी का उपयोग करके आईओएस 5 के लिए विशेष रूप से विकसित कर रहा हूं। क्या IBOutletएस UIView(और उपवर्ग) के लिए होना चाहिए strongया weak?

निम्नलिखित:

@property (nonatomic, weak) IBOutlet UIButton *button;

इस सब से छुटकारा मिलेगा:

- (void)viewDidUnload
{
    // ...
    self.button = nil;
    // ...
}

क्या ऐसा करने में कोई समस्या है? टेम्प्लेट strong'इंटरफ़ेस बिल्डर' संपादक से सीधे हेडर से कनेक्ट करते समय बनाए गए स्वचालित रूप से बनाए गए गुणों का उपयोग कर रहे हैं, लेकिन क्यों? UIViewControllerपहले से ही एक है strongइसकी के संदर्भ में viewजो अपने subviews बरकरार रखती है।

— hypercrypt
स्रोत

11

नोट के रूप में, IBOutletCollection()नहीं होना चाहिए weak, अन्यथा यह वापस आ जाता है nil।

— ओहो

इंटरफ़ेस बिल्डर के माध्यम से IBOutlets बनाते समय Xcode 8.2.1 कमजोर का उपयोग करता है। हालाँकि, SO पर यहाँ दिए गए कई उत्तर मजबूत उपयोग करने की सलाह देते हैं।

— neoneye

1

@neoneye मैंने अभी-अभी xcode 8.3.2 के साथ स्टोरीबोर्ड से स्विफ्ट फ़ाइल तक खींचने की कोशिश की है और यह डिफॉल्ट करता हैstrong

— CupawnTae

252

Apple से वर्तमान में अनुशंसित सर्वोत्तम अभ्यास IBOutlets के मजबूत होने के लिए है जब तक कि कमजोर को बनाए रखने के चक्र से बचने के लिए विशेष रूप से आवश्यक नहीं है। जैसा कि ऊपर उल्लेख किया गया है, जोहान्स ने डब्ल्यूडब्ल्यूडीसी के 2015 के "इंजीयनिंग यूआई डिज़ाइन्स इन इंटरफेस बिल्डर" सत्र में यह टिप्पणी की थी जहां एक एप्पल इंजीनियर ने कहा:

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

मैंने ट्विटर पर आईबी टीम के एक इंजीनियर से इस बारे में पूछा और उन्होंने पुष्टि की कि मजबूत डिफ़ॉल्ट होना चाहिए और डेवलपर डॉक्स अपडेट किए जा रहे हैं।

https://twitter.com/_danielhall/status/620716996326350848 https://twitter.com/_danielhall/status/620717252216623104

— डैनियल हॉल
स्रोत

33

क्या यह वास्तव में सही है या 300+ के साथ उत्तर सही है? मैंने देखा कि जब आप स्टोरीबोर्ड से .h

— अरुणाभ दास

4

400+ वोटों वाला एक सही है, लेकिन पुराना है। चूंकि iOS 6 viewDidUnload को कॉल नहीं किया जाता है, इसलिए कमजोर आउटलेट होने के कोई लाभ नहीं हैं।

— kjam

7

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

— कैमरन लोवेल पामर

5

मुझे आपसे असहमत होना चाहिए। ऑब्जेक्टिव-सी में हर समय कुछ ऐसा मजबूत संदर्भ होता है जिसे आपने नहीं बनाया है। इसलिए वहाँ एक संदर्भ गिनती है , बल्कि तब एक ही मालिक है। क्या आपके पास इस अनुशंसा का कोई संदर्भ है? क्या आप कमजोर आउटलेट के अन्य लाभों को सूचीबद्ध कर सकते हैं?

— kjam

4

यहाँ WWDC वीडियो का उल्लेख डेवलपर

— ।apple.com

450

चेतावनी, स्वीकृत उत्तर : ऊपर दिए गए स्वीकृत उत्तर (डैनियल हॉल) के सही उत्तर के लिए यह उत्तर डब्ल्यूडब्ल्यूडीसी 2015 के अनुसार अद्यतित नहीं है। यह जवाब रिकॉर्ड के लिए रहेगा।

डेवलपर लाइब्रेरी से सारांशित :

व्यावहारिक दृष्टिकोण से, आईओएस और ओएस एक्स आउटलेट में घोषित गुणों के रूप में परिभाषित किया जाना चाहिए। आउटलेट आमतौर पर कमज़ोर होने चाहिए, सिवाय फ़ाइल के स्वामी से लेकर निब फ़ाइल (या आईओएस में, स्टोरीबोर्ड दृश्य) में शीर्ष-स्तरीय ऑब्जेक्ट के लिए जो मजबूत होना चाहिए। इसलिए आपके द्वारा बनाए गए आउटलेट आम तौर पर डिफ़ॉल्ट रूप से कमजोर होंगे, क्योंकि:
उदाहरण के लिए, आपके द्वारा बनाए गए आउटलेट्स, व्यू कंट्रोलर के दृश्य या विंडो कंट्रोलर की विंडो के सब-वे, उन वस्तुओं के बीच मनमाने संदर्भ हैं जो स्वामित्व में नहीं हैं।
मजबूत आउटलेट अक्सर फ्रेमवर्क क्लासेस (उदाहरण के लिए, UIViewController के व्यू आउटलेट या NSWindowController के विंडो आउटलेट) द्वारा निर्दिष्ट किए जाते हैं।
@property (weak) IBOutlet MyView *viewContainerSubview;
@property (strong) IBOutlet MyOtherClass *topLevelObject;

— अलेक्जेंडर अकर्स
स्रोत

10

ऐप्पल डॉक पेज के विशेष भाग में कूदने के लिए आपको "डेवलपर लाइब्रेरी" लिंक कैसे मिला? जब भी मैं ऐप्पल डॉक्स से लिंक करता हूं, तो यह हमेशा पृष्ठ के शीर्ष पर लिंक होता है (भले ही ब्याज की सामग्री पृष्ठ के आधे रास्ते पर हो)। धन्यवाद।

— भालूमाँ

68

मैंने बाईं ओर नेविगेशन फलक से लिंक की प्रतिलिपि बनाई है। : डी

— एलेक्ज़ेंडर अकर्स

27

"फ़ाइल के मालिक से लेकर निब फाइल (या आईओएस, स्टोरीबोर्ड दृश्य में आईओएस में) शीर्ष स्तर की वस्तुओं के अलावा क्या मतलब है?"

— वैन ड्यू ट्रान

16

@VanDuTran - इसका अर्थ है एनआईबी में ऐसी वस्तुएं जो रूट स्तर पर हैं, यानी आप का कहना है कि इसमें एक और दृश्य है, जो सीधे मुख्य दृश्य का एक उप-वर्ग नहीं है, तो इसे एक मजबूत संदर्भ होने की आवश्यकता है।

— १६:०६ पर मटजग्लू

6

शीर्ष स्तर का मतलब है कि जब आप निब को देखते हैं, तो ऑब्जेक्ट बाईं तरफ की सूची में दिखाई देता है। लगभग सभी nibs में एक UIView है - यह केवल शीर्ष स्तर की वस्तु हो सकती है। यदि आप अन्य आइटम जोड़ते हैं, और वे सूची में दिखाते हैं, तो वे "शीर्ष स्तर की वस्तुएं" हैं

— डेविड एच।

50

जबकि दस्तावेज़ीकरण weakसाक्षात्कार के लिए संपत्तियों पर उपयोग करने की अनुशंसा करता है , क्योंकि iOS 6 के strongबजाय इसके बजाय (डिफ़ॉल्ट स्वामित्व योग्यता) का उपयोग करना ठीक प्रतीत होता है । इस कारण से UIViewControllerउस दृश्य में परिवर्तन नहीं हुए हैं।

IOS 6 से पहले, यदि आपने नियंत्रक के दृश्य के सबव्यू के लिए मजबूत लिंक बनाए रखा है, यदि व्यू कंट्रोलर का मुख्य दृश्य अनलोड हो गया है, तो वे तब तक इंटरव्यू पर पकड़ बनाएंगे, जब तक व्यू कंट्रोलर आसपास है।
IOS 6 के बाद से, दृश्य अब अनलोड नहीं किए गए हैं, लेकिन एक बार लोड किए गए हैं और तब तक चारों ओर चिपकते हैं जब तक कि उनका नियंत्रक नहीं है। इतना मजबूत गुण मायने नहीं रखेगा। वे मजबूत संदर्भ चक्र भी नहीं बनाएंगे, क्योंकि वे मजबूत संदर्भ ग्राफ को नीचे इंगित करते हैं।

उस ने कहा, मैं उपयोग करने के बीच फटा हुआ हूं

@property (nonatomic, weak) IBOutlet UIButton *button;

तथा

@property (nonatomic) IBOutlet UIButton *button;

iOS 6 और उसके बाद:

weakस्पष्ट रूप से उपयोग करने से पता चलता है कि नियंत्रक बटन का स्वामित्व नहीं चाहता है।
लेकिन छूटना weakiOS 6 में उतार-चढ़ाव के बिना चोट नहीं करता है, और छोटा होता है। कुछ इस ओर इशारा कर सकते हैं कि यह भी तेज़ है, लेकिन मुझे अभी तक एक ऐप का सामना करना पड़ा है जो कि एस के कारण बहुत धीमा है weak IBOutlet।
उपयोग न करने weakको त्रुटि के रूप में माना जा सकता है।

नीचे पंक्ति: iOS 6 के बाद से हम इसे गलत नहीं पा सकते हैं जब तक कि हम अनलोडिंग का उपयोग नहीं करते हैं। पार्टी करने का समय। ;)

— तम्मो फ्रीज
स्रोत

यह सच है, लेकिन आप अभी भी दृश्य को अनलोड करना चाह सकते हैं। जिस स्थिति में आपको अपने सभी आउटलेट nilमैन्युअल रूप से सेट करने होंगे ।

— हाइपरक्रिप्ट क्रॉप

PS: weakARM64 में काफी सस्ता है: D

— hypercrypt

यह सही है, यदि आप दृश्य अनलोडिंग को लागू करते हैं, तो weakगुण या __weakउदाहरण चर जाने का रास्ता है। मैं केवल यह बताना चाहता था कि यहाँ त्रुटि की संभावना कम है। weakArm64 पर सस्ता होने के कारण, मैंने weak IBOutletarmv7 के साथ वास्तविक जीवन प्रदर्शन की समस्या भी नहीं देखी है । :)

— Tammo Freese

उस मामले में, के strongरूप में अच्छी तरह से समझ में आता है। strongकेवल यदि आप अनलोडिंग का उपयोग करते हैं तो हानिकारक है - लेकिन इन दिनों कौन करता है? :)

— टामो फ्रेसे

2

@Rocotilos पहले iPhone में बहुत सीमित रैम थी। अगर मुझे सही तरीके से याद है, तो 128 एमबी, सक्रिय ऐप के लिए लगभग 10 एमबी छोड़ रहा है। एक छोटी सी स्मृति पदचिह्न महत्वपूर्ण था, इसलिए वहाँ उतराई थी। यह बदल गया है क्योंकि अब हमारे पास अधिक से अधिक रैम है, और Apple ने iOS 6 में UIView को अनुकूलित किया है, ताकि मेमोरी चेतावनियों पर, दृश्य को उतारने के बिना बहुत सारी मेमोरी को मुक्त किया जा सके।

— तम्मो फ्रीज़

34

मुझे इसमें कोई समस्या नहीं दिख रही है। पूर्व-एआरसी, मैंने हमेशा अपने IBOutlets assignबनाए हैं, क्योंकि वे पहले से ही अपने पर्यवेक्षकों द्वारा बनाए रखे गए हैं। यदि आप उन्हें बनाते हैं weak, तो आपको उन्हें व्यूडाउन में लोड नहीं करना चाहिए, जैसा कि आप बताते हैं।

एक चेतावनी: आप ARC प्रोजेक्ट में iOS 4.x का समर्थन कर सकते हैं, लेकिन यदि आप करते हैं weak, तो आप उपयोग नहीं कर सकते हैं , इसलिए आपको उन्हें बनाना होगा assign, जिस स्थिति में आप अभी भी viewDidUnloadबचने के लिए संदर्भ को शून्य करना चाहते हैं। झूलने का सूचक। यहाँ मैंने एक झूलने वाले सूचक बग का अनुभव किया है:

एक UIViewController ज़िप कोड के लिए एक UITextField है। यह उपयोगकर्ता के स्थान को जियोकोड रिवर्स करने और ज़िप कोड सेट करने के लिए CLLocationManager का उपयोग करता है। यहाँ प्रतिनिधि कॉलबैक है:

-(void)locationManager:(CLLocationManager *)manager
   didUpdateToLocation:(CLLocation *)newLocation
          fromLocation:(CLLocation *)oldLocation {
    Class geocoderClass = NSClassFromString(@"CLGeocoder");
    if (geocoderClass && IsEmpty(self.zip.text)) {
        id geocoder = [[geocoderClass alloc] init];
        [geocoder reverseGeocodeLocation:newLocation completionHandler:^(NSArray *placemarks, NSError *error) {
            if (self.zip && IsEmpty(self.zip.text)) {
                self.zip.text = [[placemarks objectAtIndex:0] postalCode];
            }
        }];    
    }
    [self.locationManager stopUpdatingLocation];
}

मैंने पाया कि अगर मैंने सही समय पर इस दृश्य को खारिज कर दिया और स्वयं को शून्य नहीं किया viewDidUnload, तो प्रतिनिधि कॉलबैक self.zip.text पर एक खराब एक्सेस अपवाद फेंक सकता है।

— क्रिस्टोफर पिक्ससेले
स्रोत

4

यह भी मेरी समझ है कि weakगुणों को शून्य करने की आवश्यकता नहीं है viewDidUnload। लेकिन ऐप्पल के आउटलेट बनाने के लिए टेम्प्लेट में एक [self setMySubview:nil]क्यों शामिल है ?

— यांग मेयर

3

क्या कोई वास्तविक दुनिया के मामले हैं जहां आपके IBOutlet के लिए मजबूत / बनाए रखने से समस्या पैदा हो सकती है? या यह सिर्फ एक निरर्थक प्रतिधारण है, जिसका अर्थ है कि खराब कोडिंग शैली लेकिन आपके कोड को प्रभावित नहीं करेगा?

— Enzo Tran

1

क्या कोई ऐसी चीज है जो एक अनावश्यक रूप से बरकरार है? यदि कोई अतिरिक्त अनुरक्षण है, तो इसका कारण यह होगा कि इसे ठीक से नहीं गिना जा सकता है, और इसलिए इसे जल्द से जल्द मुक्त नहीं किया जाएगा, क्योंकि इसके रख-रखाव की गिनती पर एक अतिरिक्त रख रखाव हो सकता है।

— karlbecker_com

25

IBOutletप्रदर्शन के कारण मजबूत होना चाहिए। आईओएस 9 में स्टोरीबोर्ड संदर्भ, मजबूत IBOutlet, दृश्य डॉक देखें

जैसा कि इस पैराग्राफ में बताया गया है, व्यू कंट्रोलर के व्यू के सब-वे के आउटलेट कमजोर हो सकते हैं, क्योंकि ये सब पहले से ही nib फाइल के टॉप लेवल ऑब्जेक्ट के स्वामित्व में हैं। हालाँकि, जब आउटलेट को एक कमजोर पॉइंटर के रूप में परिभाषित किया जाता है और पॉइंटर सेट किया जाता है, तो ARC रनटाइम फ़ंक्शन को कॉल करता है:

id objc_storeWeak(id *object, id value);

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

void objc_destroyWeak(id * object)

फिर, ऑब्जेक्ट अपंजीकृत है और objc_destroyWeak फिर से कॉल करता है:

objc_storeWeak(id *object, nil)

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

Xcode 7 के रूप में, यह सुझाव देता है strong

यदि आप इंटरफ़ेस बिल्डर में WWDC 2015 के सत्र 407 में यूआई डिज़ाइनों को लागू करते हुए देखते हैं , तो यह सुझाव देता है (से प्रतिलिपि http://asciiwwdc.com/2015/session/407 )

और अंतिम विकल्प जो मैं इंगित करना चाहता हूं वह भंडारण प्रकार है, जो या तो मजबूत या कमजोर हो सकता है।

सामान्य तौर पर आपको अपने आउटलेट को मजबूत बनाना चाहिए, खासकर यदि आप किसी आउटलेट को उप-दृश्य से या किसी बाधा से जोड़ रहे हों जो कि दृश्य पदानुक्रम द्वारा हमेशा बनाए नहीं रखा जाएगा।

केवल एक बार जब आपको वास्तव में एक आउटलेट को कमजोर बनाने की आवश्यकता होती है, तो यदि आपके पास एक कस्टम दृश्य है जो दृश्य पदानुक्रम और सामान्य रूप से अनुशंसित नहीं है, तो कुछ का संदर्भ देता है।

इसलिए मैं मजबूत चुनने जा रहा हूं और मैं कनेक्ट पर क्लिक करूंगा जो मेरा आउटलेट उत्पन्न करेगा।

— onmyway133
स्रोत

1

महान कारण जो वास्तविक कारण बताता है -यही

— micnguyen

यह अच्छा है और सभी लेकिन मैंने स्टोरीबोर्ड में लागू किए गए जेस्चर पहचानकर्ताओं से लीक को देखा है।

— थिबुत नूह

1

मैं इस लाइन को नहीं समझ सकता। "केवल एक बार जब आपको वास्तव में एक आउटलेट को कमजोर बनाने की आवश्यकता होती है, यदि आपके पास एक कस्टम दृश्य है जो पदानुक्रम को देखने और सामान्य रूप से अनुशंसित किसी चीज़ का संदर्भ देता है।" कोई उदाहरण?

— user1872384

मैंने कमजोर समय और मजबूत लगने वाले समय की गणना की, और यह बिल्कुल वैसा ही है।

— टाटी

लेकिन स्विफ्ट में यह मामला अधिक है। कमजोर संदर्भ तेज हैं।

— थिसुमर्सगिन

20

IOS डेवलपमेंट में NIB लोडिंग मैक डेवलपमेंट से थोड़ी अलग है।

मैक विकास में एक IBOutlet आमतौर पर एक कमजोर संदर्भ होता है: यदि आपके पास NSViewController का एक उपवर्ग है, तो केवल शीर्ष-स्तरीय दृश्य बनाए रखा जाएगा और जब आप नियंत्रक को डील करते हैं तो इसके सभी साक्षात्कार और आउटलेट स्वचालित रूप से मुक्त हो जाते हैं।

UiViewController मजबूत संदर्भों का उपयोग करके आउटलेट्स सेट करने के लिए कुंजी मूल्य कोडिंग का उपयोग करता है। इसलिए जब आप अपने UIViewController की डील करते हैं, तो शीर्ष दृश्य स्वचालित रूप से डीलॉक्लेट हो जाएगा, लेकिन आपको डीलॉक विधि में इसके सभी आउटलेट्स को भी निपटाना होगा।

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

— ग्यूसेप
स्रोत

16

यह 2009 की तरह इसे समझाता है। एआरसी के साथ, यह काफी बदल गया है।

— डैफिड विलियम्स

1

:( बिग नर्ड रेंच लिंक मर चुका है ... फिर भी मुझे वास्तव में इसे पढ़ने की जरूरत है। किसी को भी उस पोस्ट के बारे में अधिक जानकारी पता है, इसलिए मैं इसे पा सकता हूं?

— मोतिनोर

@MottiShneor चिंता न करें, यह कोई बड़ी बात नहीं है क्योंकि लिंक एआरसी से पहले कई बार था और अब प्रासंगिक नहीं है।

— सर्गेई ग्रिश्च्योव

18

एक बात जो मैं यहाँ बताना चाहता हूँ, और वह यह है कि Apple इंजीनियरों ने अपने WWDC 2015 के वीडियो में यहाँ क्या कहा है, इसके बावजूद:

https://developer.apple.com/videos/play/wwdc2015/407/

Apple विषय पर अपना विचार बदलता रहता है, जो हमें बताता है कि इस प्रश्न का एक भी सही उत्तर नहीं है। यह दिखाने के लिए कि इस विषय पर भी Apple इंजीनियर विभाजित हैं, Apple के सबसे हालिया नमूना कोड पर एक नज़र डालें, और आप देखेंगे कि कुछ लोग कमजोर उपयोग करते हैं, और कुछ नहीं करते हैं।

यह Apple पे उदाहरण कमजोर का उपयोग करता है: https://developer.apple.com/library/ios/samplecode/Emporium/Listings/Emporium_ProductTableViewController_swift.html#//apple_ref/doc/uid/TP40016175-Emporium_ProductTableViewController_swift_swift/

जैसा कि यह चित्र-इन-पिक्चर उदाहरण है: https://developer.apple.com/library/ios/samplecode/AVFoundationPiPPlayer/Listings/AVFoundationPiPPayer_Player_Controller_swift.html#//apple_ref/doc/uoc/uid/vid/6/6/6/6/6/6/6/6/6/6/6/6/6/6&hl=hi

जैसा कि लिस्टर उदाहरण देता है: https://developer.apple.com/library/ios/samplecode/Lister/Listings/Lister_ListCell_swift.html#//apple_ref/doc/uid/TP400b701-Lister_ListCell_swift-DontLinkElementID_57

जैसा कि कोर स्थान का उदाहरण है: https://developer.apple.com/library/ios/samplecode/PotLoc/Listings/Potloc_PotlocViewController_swift.html#//apple_ref/doc/uid/TP40016176-Potloc_PotlocViewPontroller_swift_swift/swift/

जैसा कि व्यू कंट्रोलर प्रीव्यू उदाहरण देता है: https://developer.apple.com/library/ios/samplecode/ViewControllerPreviews/Listings/Projects_PreviewUsingDelegate_PreviewUsingelegate_DetailViewController_swift.html#//apple_ref/uid.uid/Q/QFQQ/UpQ/Uid.Q/

जैसा कि होमकिट उदाहरण है: https://developer.apple.com/library/ios/samplecode/HomeKitCatalog/Listings/HMCatalog_Homes_Action_Sets_ActionSetViewContView_swift.html#//apple_ref/doc/uid/TP40015048-Hotatalog/mscatalog/mspatalog/mspatalog/msk/

वे सभी iOS 9 के लिए पूरी तरह से अपडेट हैं, और सभी कमजोर आउटलेट का उपयोग करते हैं। इससे हम सीखते हैं कि ए। मुद्दा उतना सरल नहीं है, जितना कि कुछ लोग इसे समझ लेते हैं। B. Apple ने बार-बार अपना मन बदला है, और C. आप जो कुछ भी उपयोग कर सकते हैं वह आपको खुश करता है :)

पॉल हडसन (www.hackingwithsift.com के लेखक) के लिए विशेष धन्यवाद जिन्होंने मुझे इस जवाब के लिए स्पष्टीकरण और संदर्भ दिए।

मुझे आशा है कि यह इस विषय को थोड़ा बेहतर बताता है!

ख्याल रखना।

— syedfa
स्रोत

मैं कुछ समय से इस मुद्दे पर जाँच कर रहा हूँ और कोई ठोस जवाब नहीं मिला है। चूंकि उपरोक्त लिंक बताता है कि दोनों ठीक हैं और सामान्य रूप से एक्सकोड ऑटोसगेट्स के साथ चलते हैं।

— उपिन 272

9

WWDC 2015 से इंटरफ़ेस बिल्डर में UI डिज़ाइन को लागू करने पर एक सत्र है । 32 मिनट के निशान के आसपास वह कहता है कि आप हमेशा अपना @IBOutlet मजबूत बनाना चाहते हैं ।

— जोहानिस
स्रोत

दिलचस्प। मुझे लगता है कि जब अनलोडिंग को हटा दिया गया था तो यह बदल गया है?

— hypercrypt

6

जागरूक IBOutletCollectionहोना चाहिए , होना चाहिए @property (strong, nonatomic)।

— landonandrey
स्रोत

3

क्यों नहीं copyजैसा कि यह एक है NSArray?

— हाइपरक्रिप्ट

5

ऐसा लग रहा है कि कुछ वर्षों में बदल गया है और अब Apple सामान्य रूप से मजबूत उपयोग करने की सिफारिश करता है। उनके WWDC सत्र पर साक्ष्य 407 सत्र में है - इंटरफेस बिल्डर में यूआई डिजाइन को लागू करना और 32:30 से शुरू होता है। वह जो कहता है, उससे मेरा ध्यान दें (लगभग, यदि बिल्कुल नहीं, उसे उद्धृत करते हुए):

सामान्य तौर पर आउटलेट कनेक्शन मजबूत होना चाहिए, खासकर अगर हम एक सबव्यू या बाधा को जोड़ते हैं जो हमेशा पदानुक्रम द्वारा बनाए नहीं रखा जाता है
कस्टम व्यू बनाते समय कमजोर आउटलेट कनेक्शन की आवश्यकता हो सकती है जिसमें पदानुक्रम में किसी चीज़ का कुछ संदर्भ होता है और सामान्य तौर पर इसकी अनुशंसा नहीं की जाती है

अन्य वार्डों में यह हमेशा मजबूत होना चाहिए, जब तक कि हमारे कुछ कस्टम दृश्य दृश्य पदानुक्रम में कुछ के साथ एक अनुरक्षण चक्र नहीं बनाते हैं।

संपादित करें:

कुछ सवाल पूछ सकते हैं। क्या इसे एक मजबूत संदर्भ के साथ रखने से रूट व्यू कंट्रोलर के रूप में एक बनाए रखने का चक्र नहीं बनता है और मालिक का दृष्टिकोण इसका संदर्भ रखता है? या ऐसा क्यों हुआ? मुझे लगता है कि उत्तर इस बात में है जब वे वर्णन करते हैं कि कैसे निब को xib से बनाया जाता है। एक VC के लिए और देखने के लिए एक अलग nib बनाया गया है। मुझे लगता है कि यही वजह हो सकती है कि उन्होंने सिफारिशें बदल दीं। फिर भी Apple से गहन विवरण प्राप्त करना अच्छा होगा।

— जूलियन क्राल
स्रोत

4

मुझे लगता है कि सबसे महत्वपूर्ण जानकारी है: xib में तत्व स्वचालित रूप से दृश्य के साक्षात्कार में हैं। साक्षात्कार NSArray है। NSArray इसके मालिक हैं। आदि उन पर मजबूत संकेत हैं। इसलिए ज्यादातर मामलों में आप एक और मजबूत पॉइंटर (IBOutlet) नहीं बनाना चाहते हैं

और एआरसी के साथ आपको कुछ भी करने की आवश्यकता नहीं है viewDidUnload

— kraag22
स्रोत