मैंने कस्टम सबव्यूज़ को UIViewController सबक्लास के रूप में कार्यान्वित किया है, लेकिन शायद इसे UIView सबक्लास के रूप में कार्यान्वित किया जा सकता था।कस्टम सबव्यू के लिए UIViewController को उपclass कब करें?
मुझे उप-दृश्य के लिए UIView के बजाय UIViewController उपclass कब करना चाहिए? UIViewController subclassing करने के लिए कोई कमी है?
व्यक्तिगत रूप से, जब मुझे कुछ महत्वपूर्ण तर्क की आवश्यकता होती है, तो मैं इसे UIViewController सबक्लास के साथ करता हूं। इसके अलावा, अगर मैं UIViewController से प्राप्त कुछ व्यवहार की तलाश में हूं। इसे सामान्य रूप से या नेविगेशन नियंत्रक में प्रस्तुत करना।
यदि आप कुछ साधारण या हल्के वजन कर रहे हैं, तो UIView सबक्लास आमतौर पर पर्याप्त होता है। ऐसा लगता है कि कस्टम बटन और टेबल व्यू सेल बनाते समय मैंने उन्हें अक्सर इस्तेमाल किया है।
मेरे अनुभव में मैं अपने आप को UIViewController उपवर्गों की तुलना में अधिक UIView उपवर्गों का उपयोग कर, लेकिन यह सबसे अच्छा नहीं हो सकता है मिल गया है, यह सिर्फ इतना है कि मैं सीधे-अप दृश्य के बजाय दृश्य नियंत्रकों का उपयोग कर थोड़ा अधिक सहज महसूस करते हैं।
यदि आप अपने "दृश्य" में विज्ञापनबैन व्यू का उपयोग करने जा रहे हैं तो आप UIViewController को भी उपclass करेंगे। काम करने में सक्षम होने के लिए AdBannerView को UIViewController की आवश्यकता है।
+1 उसे नहीं पता था। – hpique
क्या एप्पल कहने के लिए पर Controller Objects और the MVC design pattern
आईओएस नियंत्रक में आम तौर पर कम से कम एक निम्नलिखित भूमिकाओं को भरने के लिए उम्मीद कर रहे हैं है पर एक नज़र डालें:
समन्वय नियंत्रकों आवेदन विशिष्ट तर्क प्रदान करते हैं। वे प्रतिनिधि संदेश, नोटिफिकेशन और आईबीएक्शन का जवाब देते हैं। समन्वय नियंत्रक अन्य वस्तुओं के बीच कनेक्शन भी सेट करते हैं और अक्सर उन वस्तुओं के निर्माण और विनाश का प्रबंधन करते हैं।
नियंत्रक देखें, विशेष रूप से UIViewControllers, एक "स्क्रीन" सामग्री के प्रदर्शन का प्रदर्शन प्रबंधित करें और अगली "स्क्रीन" में संक्रमण ट्रिगर करें। वे स्मृति चेतावनियों और रोटेशन घटनाओं का जवाब देते हैं।
ओएस एक्स में मध्यस्थ नियंत्रक मौजूद हैं लेकिन उनकी भूमिका आम तौर पर आईओएस में दृश्य नियंत्रकों द्वारा भरी जाती है। वे विचारों और मॉडलों के बीच मध्यस्थ के रूप में कार्य करते हैं; जब मॉडल बदलते हैं तो विचारों को इनपुट प्राप्त करते हैं और विचारों को अपडेट करते समय मॉडल अपडेट करते हैं।
यदि आप जिस व्यवहार को कार्यान्वित कर रहे हैं, वह इन श्रेणियों में से किसी एक में फिट बैठता है तो आप शायद नियंत्रक ऑब्जेक्ट बनाना चाहते हैं। यदि आपका तर्क केवल डेटा के प्रदर्शन (और संभवतः उपयोगकर्ता इनपुट का जवाब देने) से संबंधित है तो शायद यह दृश्य परत में है। यदि आपका तर्क डेटा के बारे में है तो यह शायद मॉडल में संबंधित है। यदि आप किसी भी परत में अपने तर्क के लिए एक अच्छा फिट नहीं पा रहे हैं तो आपको अलग-अलग परतों में अलग-अलग ऑब्जेक्ट्स से संबंधित विभिन्न जिम्मेदारियों के संयोजन के रूप में इसे अलग-अलग मॉडल करना चाहिए। यानी एक दृश्य जो मध्यस्थ दृश्य नियंत्रक से डेटा प्रदर्शित करने का अनुरोध करता है।
अंगूठे का नियम मैं पालन करता हूं, यदि आप कस्टम ड्राइंग कर रहे हैं, तो सबक्लास UIView। अन्यथा, UIViewController subclass।
हो सकता है कि जब आपके पास जटिल सबव्यूज़ हों जो अन्य सबव्यू को लागू करने की आवश्यकता हो। मामले की निर्भर करता है :-) – Vinzius