एक एप्लिकेशन फ्रेमवर्क के लिए डिज़ाइन जो प्रत्येक कार्यान्वयन को UI के कुछ हिस्सों को अनुकूलित करने की अनुमति देगा


9

मुझे एक एप्लिकेशन फ्रेमवर्क डिज़ाइन करने का काम सौंपा गया है जो प्रत्येक कार्यान्वयन को उपयोगकर्ता इंटरफ़ेस के कुछ हिस्सों को अनुकूलित करने की अनुमति देगा। ऐसा एक उदाहरण यह होगा कि कार्यान्वयन (अब से इसे ग्राहक कहते हैं) एक विशेष स्क्रीन पर लौटने के लिए संग्रह दृश्य कोशिकाओं को परिभाषित कर सकता है। फ्रेमवर्क उचित रूप से उचित वस्तुओं को वेंडिंग करने के लिए जिम्मेदार है ताकि हम एक जैसे दिखने वाले कई उदाहरणों का निर्माण कर सकें।

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

समस्या यह है कि मुझे इस रूपरेखा को कैसे डिज़ाइन करना चाहिए ताकि एक ग्राहक अपने स्वयं के कस्टम UI को ऐप में जोड़ सके।

दृष्टिकोण एक

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

दृष्टिकोण दो

प्रत्येक दृश्य नियंत्रक उपक्लासिंग हुक या सेटअप एपीआई को निर्दिष्ट करता है जो इन कस्टम यूआई कक्षाओं को चलाने के समय पर परिभाषित करने की अनुमति देगा (इसी तरह कैसे UISplitViewController कॉल करने वालों को व्यूकंट्रोलर संपत्ति का उपयोग करके नियंत्रकों को सेटअप करने की अनुमति देता है)। ऐसा करने के लिए प्रत्येक ग्राहक बस समन्वय नियंत्रक और प्रत्येक नियंत्रक प्रस्तुति में उपवर्ग करेगा; नियंत्रक पर उचित मान सेट करें ताकि यह वांछित UI प्राप्त कर सके। कुछ इस तरह

viewController.registerReusableCellsBlock = ^(UICollectionView *collectionView){
   //perform custom registration
}

viewController.cellDequeueBlock = ^UICollectionViewCell<SomeProtocol> *(UICollectionView *collectionView,NSIndexPath *indexPath){
   //dequeue custom cells
}

वर्तमान में, मैं पुन: प्रयोज्य को बढ़ावा देने और ViewController ब्लोट को रोकने के लिए एक अलग वस्तु में देखने के लिए डेटा स्रोत को अलग करता हूं। यह कोशिकाओं के इंटरफेस को थोड़ा कठिन नहीं बल्कि असंभव बनाने के लिए व्यू कंट्रोलर को उपवर्गित करता है।

दृष्टिकोण ३

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

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

टी एल; डॉ

इंटरफ़ेस का सबसे जटिल हिस्सा कलेक्शन व्यू सेल के अंदर नेस्टेड व्यू के साथ डील करता है। यह क्षैतिज पेजिंग और कोशिकाओं के ऊर्ध्वाधर स्क्रॉलिंग के लिए अनुमति देता है। यह एक डेटा स्रोत होने से प्राप्त होता है जो क्षैतिज कोशिकाओं का प्रबंधन करता है और प्रत्येक सेल के संग्रह दृश्य को नए डेटा स्रोत के साथ कॉन्फ़िगर करता है।

कोई ऐसा इंटरफ़ेस कैसे डिज़ाइन करेगा जो इन सभी कोशिकाओं को अनुकूलन योग्य बनाता है?


दृष्टिकोण 1 सबसे अधिक लचीलापन देता है, अपने उपयोगकर्ताओं से कम से कम 2 प्रयास करने की आवश्यकता है लेकिन कम से कम प्रयास करें। तो तुम क्या चाहते हो?
त्रिकाल

@ ईमानदारी से मैं वरिष्ठ अनुभव की उम्मीद कर रहा हूं। मेरी सबसे बड़ी चिंता यह अनुमान लगाने में सक्षम नहीं है कि अनुकूलन के संबंध में मुझे कितना नियंत्रण प्रदान करने की आवश्यकता है
डैनियल जी

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

जवाबों:


1

यह पुराना लेकिन योग्य प्रश्न है जिसके जवाब में कभी योग्य जवाब नहीं मिला, जो मेरे अनुभव में है

How would one design an interface that allows all these cells to be customizable?

है- ऐसा मत करो।

ग्राहकों को कस्टमाइज़ेशन में बाधा डालना- चाहे वह UI में हो या किसी और चीज़ में- वेंडर के लिए लगभग हमेशा बेहतर होता है- क्योंकि यह समाधान को आसान बनाता है और सपोर्ट के बोझ को कम करता है- और क्लाइंट के लिए भी- क्योंकि तब वे सबसे अधिक सक्षम होते हैं वेंडर को अपना समय बर्बाद करने के बिना, समाधान स्थान के मीठे स्थान पर लाने के लिए विक्रेता की विशेषज्ञता का लाभ उठाएं।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.