2014-07-11 3 views
8

मॉडल-व्यू-प्रेजेंटर (एमवीपी) जीयूआई अनुप्रयोगों के लिए एक प्रसिद्ध डिजाइन पैटर्न है। एंड्रॉइड के लिए, एक सादा जावा मॉड्यूल में व्यावसायिक तर्क को लागू करने से एंड्रॉइड एमुलेटर की आवश्यकता के बिना परीक्षण की सुविधा मिलती है।एंड्रॉइड में मॉडल-व्यू-प्रेजेंटर को लागू करने में कठिनाइयों

हालांकि, मैं कर रहा हूँ कठिनाइयों एंड्रॉयड आवेदनों की जीयूआई के लिए विशेष आवश्यकताओं की वजह से Android पर पैटर्न को लागू करने:

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

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

मैं ब्लॉग पोस्ट MVP for Android पढ़ सकते हैं और example source code पर ध्यान दिया है। एमवीपी पैटर्न का उपयोग करके मैं प्राप्त करने का प्रयास कर रहा हूं, ट्रांस्सेलर j2objc का उपयोग करके ऑब्जेक्टिव-सी में सभी व्यावसायिक तर्कों का अनुवाद करने में सक्षम होना चाहिए, जैसे कि आईओएस पर एक ही ऐप को लागू करते समय व्यवसाय तर्क का पुन: उपयोग किया जा सकता है।

क्या कोई ऐसा व्यक्ति है जिसने एंड्रॉइड के लिए सफलतापूर्वक एमवीपी पैटर्न लागू किया है, और उस स्थिति में, मुझे क्या याद आ रही है?

+0

मैं क्या सोच रहा हूं: यदि आप व्यवसाय-तर्क मॉड्यूल 'संदर्भ' की आवश्यकता के बिना सादा जावा है, तो आपकी 'गतिविधि'-जीवन चक्र क्यों मायने रखती है? दूसरे शब्दों में, उन विशेष जीयूआई आवश्यकताओं को एक समस्या क्यों है? – Blacklight

+0

यदि एमवीपी का 'व्यू' हिस्सा कुछ बिंदुओं पर अपडेट नहीं किया जा सकता है (जब इसे रोक दिया जाता है), तो 'प्रस्तुतकर्ता' या 'मॉडल' को पता नहीं होना चाहिए? और क्या 'मॉडल' नहीं बनाया जाना चाहिए ताकि इसे बाद में बहाल किया जा सके? – foens

+1

कोई तर्क दे सकता है कि गतिविधि जीवन चक्र के प्रबंधन के लिए ज़िम्मेदार है और प्रस्तुतकर्ता को आवश्यकतानुसार सेट/रोकना/फाड़ना। प्रस्तुतकर्ता आपके सिस्टम पर निर्भर यूआई फ्रेमवर्क quirks के लिए कोई भी बुद्धिमान नहीं है। – dcow

उत्तर

4

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

आपके द्वारा वर्णित गतिविधि आवश्यकताओं को प्लेटफ़ॉर्म-स्वतंत्र होने के लिए सामान्यीकृत किया जा सकता है: घटक क्रमिक (छोटे ', विशेष रूप से जावा क्रमबद्धता नहीं होना चाहिए), और जीवन चक्र राज्य घटनाओं को स्वीकार करने की आवश्यकता है। उन लोगों को भी सिस्टम सुविधाओं के लिए mocks का उपयोग करके पूरी तरह से परीक्षण किया जा सकता है। जैसे ही आप इस चरण से गुजरते हैं, आप शायद ध्यान दें कि गतिविधि की कुछ आवश्यकताएं आवश्यक रूप से एंड्रॉइड-विशिष्ट हैं, और अन्य प्लेटफार्मों पर उपयोगी हो सकती हैं। विशाल सेवा एपीआई बनाने से बचें; क्रमबद्धता का समर्थन करने के लिए, उदाहरण के लिए, आवश्यक सभी स्टोर/लोड विधियां हैं, Parcel API जैसी कुछ नहीं। मुझे अनावश्यक फ्लफ खोजने का एक शानदार तरीका होने के लिए एक व्हाइटबोर्ड पर किसी अन्य डेवलपर को ऐसी सेवा API का वर्णन करना पाया गया है।

अगला, एंड्रॉइड के लिए घटक पोर्ट करें, शायद एक गतिविधि बनाकर जो घटक को प्रतिनिधि करता है और मॉक किए गए इंटरफेस के लिए एंड्रॉइड-विशिष्ट कार्यान्वयन कक्षाएं प्रदान करता है। इसे सभी को पहली बार "बस काम करना चाहिए", लेकिन हकीकत में, कुछ आवश्यकताओं को याद किया जा सकता है, इसलिए उन्हें मंच-स्वतंत्र भाग में जोड़ें और दोहराएं।

जब आप आईओएस के लिए बंदरगाह के लिए तैयार हों, तो पहले उन मॉक किए गए इंटरफेस को दोबारा लागू करें। यदि ये इंटरफेस कमजोर हैं, तो संभवतः उन्हें उद्देश्य-सी में सीधे बनाना आसान होगा, जे 2objc द्वारा उत्पन्न प्रोटोकॉल हेडर आयात करना। उदाहरण के लिए, j2objc की NSDictionaryMap कक्षा एक NSDictionary कार्यान्वयन के साथ java.util.Map लागू करती है - आईओएस एपीआई का उपयोग करने के बाद से जावा संस्करण लिखने और अनुवाद करने की आवश्यकता नहीं है।

+0

हाय और विचारों के लिए धन्यवाद। मुझे पूरी तरह से यकीन नहीं है कि 'घटक' क्या है। क्या आप प्रस्तुतकर्ता के बारे में बात कर रहे हैं? आपकी पोस्ट में मुझे लगता है कि आप वास्तव में [प्रेजेंटर-फर्स्ट] (http://atomicobject.com/files/PresenterFirstAgile2006.pdf) नामक कार्यान्वयन प्रक्रिया का वर्णन कर रहे हैं, क्या मैं इसमें सही हूं? दृश्य इंटरफ़ेस (प्लेटफॉर्म विनिर्देशों के बिना) होना चाहिए और इन्हें एंड्रॉइड पर एक गतिविधि द्वारा कार्यान्वित किया जाना चाहिए। मुझे लगता है कि यह बचत/लोड प्रक्रियाओं को लागू करने के लिए काफी प्रयास करेगा, जो एंड्रॉइड मनोरंजन प्रक्रिया का प्रभावी ढंग से पुन: कार्यान्वयन भी कर रहा है। – foens

+0

मैं संयुक्त एमवीपी "यूनिट" को एक घटक कह रहा था, क्या कोई बेहतर नाम है? सभी उपलब्ध शर्तें अधिभारित लगती हैं। आप प्रेजेंटर-फर्स्ट के बारे में सही हैं, लिंक के लिए धन्यवाद क्योंकि मैंने उस पेपर को नहीं पढ़ा था। सहेजने/लोड को प्लेटफ़ॉर्म-विशिष्ट संग्रह सेवा जैसे पार्सल या जावा के क्रमिकरण से बाहर कहा जाना चाहिए - सभी घटक को अपना स्वयं का स्टोर/पुनर्स्थापित करना चाहिए। इसे एक सेवा बनाकर, एंड्रॉइड-विशिष्ट कोड उसी कोड का उपयोग करेगा जो एंड्रॉइड ऐप सामान्य रूप से होगा। – tball

1

मुझे लगता है कि एमवीपी संस्करण एंड्रॉइड चारों ओर बनाया गया है, एक ऐप में व्यवसाय तर्क को अलग करने के लिए सही दिशा में एक कदम है।हालांकि, यदि आप चिंताओं का बेहतर अलगाव प्राप्त करना चाहते हैं, और नतीजतन अधिक पुन: प्रयोज्य डोमेन/व्यवसाय तर्क, मैं Presenter First pattern (जिसे आप संक्षेप में टिप्पणी में स्वयं का उल्लेख करते हैं) का उपयोग करने की सलाह देते हैं। युग्मन घटाने के अलावा यह टीडीडी के लिए खुद को अच्छी तरह से उधार देता है और आपको अपने सभी व्यावसायिक तर्कों का परीक्षण करने की अनुमति देता है।

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

http://github.com/olerass/presenter-first-android

शायद तुम वहाँ से कुछ विचारों का उपयोग कर सकते हैं? या यहां तक ​​कि अपने कुछ योगदान बेहतर है।

संबंधित मुद्दे