क्या आप विशेष कारणों के बारे में सोच सकते हैं कि ऐप्पल ने यूआईपीओवर कंट्रोलर को सादा एनएसओब्जेक्ट सबक्लास के रूप में लागू करने का विकल्प क्यों चुना? मेरे लिए, एक UIViewController उपclass उचित UIViewController रोकथाम को लागू करने के लिए, और अधिक समझ में आता है।UIPopoverController क्यों UIViewController subclass नहीं है?
लेकिन शायद ऐसे कारण हैं जिनके बारे में मैंने नहीं सोचा था, क्यों ऐप्पल के उज्ज्वल इंजीनियरों ने अपनी पसंद बनाई?
मुझे लगता है कि ऐसा लगता है, जैसे UIAlertView, इसे एक नए UIWindow में प्रस्तुत किया गया है ताकि खिड़की लेवल संपत्ति गारंटी दे कि यह सभी सामग्री पर प्रस्तुत की गई है।
चाहे यह एक नए UIWindow में है, जहां तक नियंत्रक रोकथाम का संबंध है, आपको यूआईपीओवर कंट्रोलर में मौजूद दृश्य नियंत्रकों में जटिल अभिभावक-बाल दृश्य नियंत्रक कंटेनर पदानुक्रमों का उपयोग करने में कोई समस्या नहीं होनी चाहिए। मेरे पास कुछ पॉपओवर के लिए
Pillboxie में घोंसले के कम से कम तीन स्तरों के साथ नियंत्रण नियंत्रक हैं, बिना किसी समस्या के।
अपडेट: मैंने नमूना प्रोजेक्ट में दृश्य पदानुक्रम के पहले तीन स्तरों के वर्गों को लॉग करके पदानुक्रम की जांच की है, और यह तब होता है जब एक पॉपओवर दिखाई देता है (मेरे मूल दृश्य नियंत्रक के पास दो UIButtons थे) :
एक खिड़की:
_SUBVIEW वर्ग: UIView
___SUBSUBVIEW वर्ग: UIRoundedRectButton
_ _SUB SUBSUBVIEW वर्ग: UIButtonLabel
___SUBSUBVIEW वर्ग: UIRoundedRectButton
_ _SUBSUBSUBVIEW वर्ग: UIButtonLabel
_SUBVIEW वर्ग: UIDimmingView
___SUBSUBVIEW वर्ग: _UIPopoverView
_ _SUBSUBSUBVIEW वर्ग: _UIPopoverStandardChromeView
_ _SUBSUBSUBVIEW वर्ग: UIView
एप्पल के प्रलेखन कहा गया है कि एक UIWindow में जड़ दृश्य नियंत्रक के दृश्य, कोई भाई अन्य दृश्य नियंत्रक द्वारा प्रबंधित दृश्य पेश करते हैं चाहिए, क्योंकि उन भाई दृश्य नियंत्रकों रोटेशन घटनाओं प्राप्त नहीं होगी (here देखना , दूसरी गोली)।
तो, अगर ऐप्पल ने UIPopoverController को UIViewController subclass बनाया था, तो इसे रूटव्यू कंट्रोलर के पदानुक्रम के बच्चे/सबव्यूव के रूप में जोड़ना होगा। लेकिन क्या होगा यदि रूट व्यू कंट्रोलर (जो है कोड, वैसे भी) एक ऐसा दृश्य पेश करने का निर्णय लेता है जो UIPopoverController के दृश्य के पदानुक्रम में हस्तक्षेप करता है? हमें इसे उछालने की बजाय, ऐसा लगता है कि ऐप्पल ने यूआईपीओवर कंट्रोलर की प्रस्तुति को पूरी तरह से प्रबंधित करने का फैसला किया, लेकिन इस तरह से उन्हें यूआईविंडो की नो-सिब्लिंग-व्यू-कंट्रोलर्स पॉलिसी के लिए अपवाद नहीं देना पड़ा।
क्योंकि UIPopoverController वस्तुओं उपयोगकर्ता के साथ बातचीत नहीं करते हैं, यही कारण है कि यह देखें परत का हिस्सा नहीं है, अपने UIViewController उपयोगकर्ता के साथ संवाद करने में सक्षम है, UIPopoverController ही अंदर किसी भी इसी तरह काम करने नहीं देता है।
एक त्वरित नियंत्रक के जेनेरिक definition नज़र डालें:
एक नियंत्रक उसके संबंधित देखने के लिए आदेश भेजने, (उदाहरण के लिए मॉडल की दृश्य की प्रस्तुति बदलने के लिए एक स्क्रॉल करके कर सकते हैं दस्तावेज़)। यह मॉडल के स्थिति (जैसे दस्तावेज़ को संपादित करना) को अद्यतन करने के लिए मॉडल को आदेश भेज सकता है।
यह बताता है कि क्यों यह देखें परत, मुझे आशा है कि यह मदद करता है का हिस्सा नहीं है।
यह मुझे विश्वास नहीं करता है। जब उपयोगकर्ता सामग्री के बाहर टैप करता है तो पॉपओवर को खारिज करते समय यह निश्चित रूप से उपयोगकर्ता के साथ इंटरैक्ट करता है। या कीबोर्ड आदि को समायोजित करने के लिए दृश्य को कम करते समय –
उपयोगकर्ता ** ** पॉपओवर को खारिज नहीं कर सकता है, प्रोग्रामर (आप) इसे केवल कर सकते हैं। – holex
बेशक उपयोगकर्ता पॉपवर के बाहर स्क्रीन में टैप करके इसे खारिज कर सकता है। –
पॉपओवर उसी विंडो में प्रस्तुत किया जाता है जिसे 'पासथ्रू व्यू' काम करने के लिए आवश्यक है। दृश्य नियंत्रक रोकथाम के साथ, मेरा मतलब था कि पॉपअप के मूल दृश्य नियंत्रक के लिए, 'parentViewController' (शायद, कोशिश नहीं की गई है) परिभाषित नहीं है। कोर्स के कंटेंट व्यू कंट्रोलर के विभिन्न स्तरों के भीतर नियंत्रण, लेकिन यह मेरा मुद्दा नहीं था। –
आपका अद्यतन उत्तर समझ में आता है। क्लिप किए गए दृश्यों से बचने के लिए इसे रूट व्यू कंट्रोलर के दृश्य पदानुक्रम के बाहर होना चाहिए। इसलिए यह UIViewController रोकथाम पदानुक्रम का हिस्सा नहीं हो सकता है। –