एकाधिक गतिविधियां/टुकड़े और मॉडल देखें प्रेजेंटर पैटर्न

Question

सबसे पहले, मुझे पता है कि मॉडल व्यू प्रेजेंटर के साथ अलग-अलग कार्यान्वयन होते हैं, और मेरे दिमाग में जब तक आपके पास अमूर्तता की परतें स्पष्ट रूप से परिभाषित होती हैं और उनकी नियुक्त भूमिकाएं होती हैं तो आप कैसे इस पैटर्न को लागू करने के लिए खुला है। मैं इस पैटर्न को कुछ ऐप्स में कार्यान्वित कर रहा हूं जहां केवल एक Activity था। मैंने अब एक नई परियोजना शुरू की है जिसमें कई गतिविधियां हैं और Fragments संलग्न हैं, जिनमें नेस्टेड टुकड़े (ViewPager) शामिल हैं।

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

अब तक मैं ऊपर ढांचा बनाया और एक 1 करने के लिए शुरू कर दिया है: के साथ देखें & प्रस्तुतकर्ता (Activity या Fragment की परवाह किए बिना) 1 संबंध। मुझे लगता है कि यह ठीक है, हालांकि अगर उदाहरण के लिए मैंने Activity से कुछ करने का अनुरोध भेजा है तो इसके प्रेजेंटर को देखें, जो परिणाम Activity पर परिणाम देता है देखें कि मैं परिणाम को प्रचारित करने के बारे में कैसे जाऊं यानी अन्य सभी गतिविधियां/टुकड़े अपडेट करें जो वर्तमान में Paused() या Stop() स्थिति में नहीं हैं। मुझे लगता है कि इस मामले में एक केंद्रीय प्रेजेंटर होना चाहिए जो सभी आवश्यक गतिविधि और टुकड़े दृश्यों को अपडेट करता है, लेकिन मुझे यकीन नहीं है कि यह करने के बारे में कैसे जाना है।

वर्तमान में जब प्रत्येक Activity और Fragment यह एक प्रस्तुतकर्ता वर्ग का एक नया उदाहरण बनाता है, एक संदर्भ (क्रियाएँ और टुकड़े को अपने स्वयं के इंटरफेस को लागू), के रूप में अपने आप में गुजर बनाई गई है जो एक WeakReference के रूप में प्रस्तोता की दुकानों और आह्वान कर सकते हैं परिणाम लौटने पर प्रासंगिक इंटरफ़ेस विधियां।

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

क्षमा करें अगर यह थोड़ा उलझन में लगता है, उम्मीद है कि यह समझने के लिए पर्याप्त स्पष्ट है कि मैं क्या हासिल करना चाहता हूं, और यदि मैं सही रेखाओं के साथ सोच रहा हूं ... या पूरी तरह से निशान से बाहर!

Answer 1

मुझे लगता है कि गतिविधि के अंदर प्रस्तुतकर्ता होना ठीक है। असल में गतिविधि नियंत्रक की तरह है, इसे प्रस्तुतकर्ता के बारे में पता होना चाहिए।

गतिविधि या अन्य टुकड़े की आवश्यकता होने पर प्रस्तुति को एक टुकड़े के अंदर रखना गलत होगा। आप एक प्रस्तुति को केवल एक टुकड़े के अंदर रख सकते हैं यदि यह प्रस्तुतकर्ता विशेष रूप से खंड के लिए डिज़ाइन किया गया हो।

जो एक WeakReference के रूप में प्रस्तोता की दुकानों और क्यों आप एक WeakReference यहाँ की जरूरत चलेगा, कोई परिणाम

लौटने प्रासंगिक इंटरफ़ेस विधियां प्रारंभ कर सकते हैं? यदि आपके पास 1: 1 रिश्ते है तो मुझे लगता है कि आपके प्रस्तुतकर्ता के पास इसका अपना जीवन चक्र नहीं है, जिसका अर्थ है कि यह जीवन चक्र या तो गतिविधि या टुकड़े पर निर्भर करता है। मेमोरी लीक होने का कोई खतरा नहीं है क्योंकि यह सिंगलटन नहीं है, है ना? एक मजबूत संदर्भ होना सुरक्षित होना चाहिए।

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

Answer 2

नहीं, अब कोई इंटरफ़ेस नहीं है। here या किसी प्रकार के Bus (Otto -deprecated या EventBus) के रूप में वर्णित सभी दृश्यों को अपडेट करने के लिए आप या तो RxJava Observables का उपयोग करते हैं। और आप इसे पसंद करेंगे क्योंकि वे बातचीत को बहुत आसान बनाते हैं।