मॉडल-व्यू-प्रेजेंटर और एंड्रॉइड एप्लिकेशन डिज़ाइन

Question

समस्या: वास्तव में बड़ी और गड़बड़ी गतिविधि कक्षाएं। पढ़ने/समझने और संशोधित करना मुश्किल है। परीक्षण करने के लिए मुश्किल है।

संभावित समाधान: मॉडल-व्यू-प्रेजेंटर (शायद निर्भरता इंजेक्शन के साथ)। और नकली टेस्ट ऑब्जेक्ट्स!

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

मैं इस पर कुछ सामुदायिक विचार प्राप्त करना चाहता हूं। उदाहरण के लिए: इस से क्या इंटरफेस अंतर्निहित हैं?
मॉडल और व्यू के प्रस्तुतकर्ता क्या जिम्मेदारियां प्रस्तुत करेंगे।

प्रेजेंटर के लिए मुझे लगता है कि गतिविधि प्रेजेंटर द्वारा आवश्यक इंटरफेस को कार्यान्वित करेगी?
प्रस्तुतकर्ता बनाम गतिविधि में किस तरह की चीजें चलनी चाहिए?

क्या कोई प्रस्तुति एक गतिविधि के साथ एक-एक होगी? अलग-अलग विगेट्स को अपने स्वयं के एडाप्टर के साथ प्रदर्शित करने वाले कई टुकड़ों वाले गतिविधि के बारे में क्या? क्या अब हमें कई प्रस्तुतकर्ताओं की आवश्यकता है या फिर अभी भी एक?

प्रेजेंटर बनाम एडाप्टर के बारे में क्या?

एक प्रस्तुतकर्ता को ListView और ListViewAdapter के साथ गतिविधि कहने से कैसे संबंधित होना चाहिए? प्रेजेंटर बनाम एडाप्टर में क्या जाता है?
क्या प्रस्तुतकर्ता एडाप्टर का उपयोग करने के लिए चुनना चाहिए? या गतिविधि को यह निर्णय लेना चाहिए? प्रस्तुतकर्ता मॉडल डेटा या एडाप्टर को संसाधित करना चाहिए? क्या एडाप्टर और प्रेजेंटर्स के बीच कोई संघर्ष है? एडाप्टर प्रस्तुतकर्ता हैं? या कुछ कम/अधिक। आमतौर पर एडाप्टर केवल गतिविधि के भीतर ListViews जैसे विजेट्स के लिए होते हैं। वे कॉल नहीं करते हैं जो मुझे लगता है कि डेटा खुद ही मिलता है।

तो मॉडल-व्यू-प्रेजेंटर में मुख्य बात यह है कि प्रस्तुतकर्ता बनाम अन्य वर्गों में क्या होता है और प्रस्तुतकर्ता और गतिविधियों, एडेप्टर और विचारों/खंडों सहित संचार के बीच क्या होना चाहिए।

मॉडल-व्यू-प्रेजेंटर एंड्रॉइड के लिए वास्तव में एक बहुत बुरा विचार है? या यह एंड्रॉइड फ्रेमवर्क के साथ अच्छी तरह से फिट है?

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

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

इस पर सैकड़ों घंटे खर्च करने से पहले जानना अच्छा लगता है, कृपया इस प्रश्न के किसी भी हिस्से पर टिप्पणी/उत्तर देने में संकोच न करें।

Answer 1

एंड्रॉइड किसी भी प्लेटफॉर्म से अधिक खराब एमवी (पी | सी) डिज़ाइन को अधिक दंडित करता है। गतिविधि स्टैक को ऊपर और नीचे राज्य पास करने के लिए प्रदान की जाने वाली बेकार विधियों को भूल जाएं।जितनी संभव हो सके अपनी गतिविधियों से ज्यादा राज्य और तर्क प्राप्त करें। इसे सेवाओं, सामग्री प्रदाता, और साझा संदर्भों में उचित के रूप में ले जाएं। अपनी गतिविधियों को शुद्ध दृश्य बनाने की कोशिश करें। आईएमओ, एंड्रॉइड ट्यूटोरियल में सेवाओं को कभी भी पर्याप्त ध्यान नहीं दिया गया है। यहां तक ​​कि O'Reilly प्रोग्रामिंग एंड्रॉइड पुस्तक केवल उन्हें एक चौथाई पृष्ठ देता है!

आवेदन बढ़ाने से सावधान रहें। यदि आपने कभी भी अपनी प्रक्रिया में एक सेवा शुरू की है (उदाहरण के लिए, जब कोई गतिविधि दुर्घटनाग्रस्त हो जाती है तो उसे शानदार तरीके से बंद करने की अनुमति दें) तो सेवा के आपके आवेदन की अपनी प्रतिलिपि होगी।

Answer 2

बस रुचि रखने वाले अन्य लोगों के लिए संदर्भ प्रदान करने के लिए। मैं कुछ साल पहले एक ही बात सोच रहा था। जब हम एंड्रॉइड ऐप में एमवीसी/MVVM/Presentation Model लागू करते हैं, तो हम वास्तव में एक स्पष्ट संरचित प्रोजेक्ट रखना चाहते हैं और इकाई परीक्षणों के लिए अधिक महत्वपूर्ण रूप से आसान है। फिलहाल, किसी तीसरे पक्ष के ढांचे के बिना, आपके पास आमतौर पर बहुत सारे कोड होते हैं (जैसे addXXListener(), findViewById() ...), जो कोई व्यावसायिक मूल्य नहीं जोड़ता है। और भी, आपको सामान्य जुनीट परीक्षणों के बजाय एंड्रॉइड यूनिट परीक्षण चलाने होंगे, जो उम्र बढ़ने के लिए लेते हैं और कुछ हद तक अव्यवहारिक परीक्षण करते हैं। इन कारणों से, कुछ साल पहले हमने ओपन सोर्स प्रोजेक्ट RoboBinding - एंड्रॉइड प्लेटफ़ॉर्म के लिए डेटा-बाइंडिंग प्रेजेंटेशन मॉडल फ्रेमवर्क शुरू किया था। रोबो बाइंडिंग आपको यूआई कोड लिखने में मदद करता है जो पढ़ने, परीक्षण और बनाए रखने में आसान है। RoboBinding की आवश्यकता को हटा देता है जैसे addXXListener या, और प्रस्तुति मॉडल में UI तर्क को बदलता है, जो एक pojo है और सामान्य JUnit परीक्षण के माध्यम से परीक्षण किया जा सकता है। रोबो बाइंडिंग अपनी गुणवत्ता सुनिश्चित करने के लिए 300 से अधिक जुनीट परीक्षणों के साथ आता है। अन्य विकल्प: एंड्रॉइड-बाइंडिंग, बाइंड्रॉइड और एमवीवीएमक्रॉस।