Android विकास में डिज़ाइन पैटर्न सिद्धांत क्या है?

Question

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

Answer 1

एंड्रॉइड की वास्तुकला ने मुझे पहले परेशान किया, लेकिन मैं अपनी पागलपन के लिए एक विधि देखना शुरू कर दिया। यह एंड्रॉइड दस्तावेज द्वारा खराब समझाया गया है। मेरी सबसे बड़ी पकड़ हमेशा यह रही है कि ऑब्जेक्ट्स के साथ एक केंद्रीकृत डेटा मॉडल होना मुश्किल है कि आपकी गतिविधियां सामान्य एप्लिकेशन की तरह साझा होती हैं। एंड्रॉइड मुझे एक मनोदशा बनना चाहता था क्योंकि मैं केवल अपनी गतिविधियों के बीच प्राइमेटिव साझा कर सकता था। और डेटाबेस में जंक छोड़ना एक मॉडल नहीं है क्योंकि इसमें कोई व्यवहार नहीं है। इसलिए अधिकांश लोगों के रूप में मेरा व्यवसाय तर्क मेरी गतिविधि में समाप्त होता है जिससे अन्य गतिविधियों में व्यावसायिक तर्क साझा करना मुश्किल हो जाता है।

मुझे पता चला है कि मुझे कुछ महत्वपूर्ण पहेली टुकड़े याद आ रहे हैं। एंड्रॉइड एमवीसी है। हालांकि, यह काफी हद तक दृश्य के साथ मिलकर है।

1. गतिविधि == नियंत्रक
2. मॉडल == आवेदन के उपवर्ग
3. कोई भी चीज जो देखें == देखें उपवर्गों

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

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

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

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

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

Answer 2

एंड्रॉइड में कार्यों, विचारों और सक्रियताओं को एंड्रॉइड यूआई के साथ काम करने के तरीके में बेक किया गया है और मॉडल-व्यू-व्यूमोडेल पैटर्न का कार्यान्वयन है, जो संरचनात्मक रूप से समान है (उसी परिवार में) मॉडल व्यू कंट्रोलर ।

मेरे सबसे अच्छे ज्ञान के लिए, इस मॉडल को तोड़ने का कोई तरीका नहीं है। यह संभवतः किया जा सकता है, लेकिन संभवतः आप मौजूदा मॉडल के सभी लाभों को खो देंगे, और इसे काम करने के लिए अपनी यूआई परत को फिर से लिखना होगा।

आप निम्नलिखित में MVC पा सकते हैं:

• आप को परिभाषित अपने user interface संकल्प/हार्डवेयर आदि द्वारा विभिन्न एक्सएमएल फाइल में
• आप अपने resources विभिन्न एक्सएमएल फाइल में स्थान आदि
द्वारा परिभाषित
• आप SQLite या अपने कस्टम डेटा/संपत्ति/फ़ोल्डर में डेटा स्टोर करते हैं, resources and assets
• के बारे में अधिक पढ़ें आपजैसे क्लिक्स का विस्तार करते हैं, TabActivity और inflaters
• द्वारा एक्सएमएल फ़ाइल का उपयोग कर के रूप में आप अपने मॉडल के लिए चाहते हैं तो आप के रूप में कई वर्गों बना सकते हैं, और अपने खुद के संकुल है, कि एक संरचना
• Utils का एक बहुत पहले से ही किया गया है के रूप में कार्य आपके लिए लिखा गया डेटाबेस उपयोग, एचटीएमएल,

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

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

यदि आप एक्सएमएल फाइलों में अपने विचारों और लेआउट को परिभाषित करते हैं, तो अपने संसाधनों को res फ़ोल्डर से लोड करें, और यदि आप अपने कोड में इन चीजों को जोड़ने के लिए कम या ज्यादा से बचते हैं, तो आप एमवीसी पैटर्न के बाद भी वैसे भी हैं।

Answer 3

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

की जांच:

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

छोटे परियोजना है कि पहले से ही इसी तरह की बात की कोशिश कर रहा है:

http://code.google.com/p/android-binding/

चियर्स

Answer 4

Android विकास मुख्य रूप से जीयूआई विकास है, जो जावा में स्विंग/एडब्ल्यूटी की तरह है, इसमें कई गुमनाम आंतरिक कक्षाएं प्रतिक्रिया होती हैं जीयूआई घटनाओं के लिए जी। यह उन चीजों में से एक है जिसने मुझे स्विंग के साथ बहुत कुछ करने से दूर रखा है .... लेकिन मेरे पास एक एंड्रॉइड फोन है, इसलिए मैं अपने दांतों को तोड़ने जा रहा हूं और बस इसे खत्म कर दूंगा, जितना ऐप्पल फैनबॉय ने कहा है एंटीना की समस्याओं के बारे में। ;)

Answer 5

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

मैं सिम्युलेटर चलाने के बिना एंड्रॉइड ऐप के विशाल बहुमत का परीक्षण कर सकता हूं। बड़ी जीत।

Answer 6

मेरी अंग्रेजी के लिए खेद है।

एंड्रॉइड में बहुत अच्छी मॉड्यूलरिटी (गतिविधियां, टुकड़े, दृश्य, सेवाएं इत्यादि) हैं। तो एमवीसी में कोई जरूरत नहीं है।

बेशक इनपुट (क्रियाएँ, टुकड़े), तर्क, दृश्य (एक्सएमएल या जावा) और डेटा (डेटाबेस, फाइलें, प्राथमिकताएं) लेने का अलगाव होता है। लेकिन यह एमवीसी नहीं है। आपको एमवीसी का उपयोग करने की कोशिश नहीं करनी चाहिए, यह केवल आपके आर्किटेक्चर को जटिल करेगी।

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

प्रणाली अपनी गतिविधि को नष्ट कर सकते अगर अग्रभूमि गतिविधि अधिक संसाधनों की आवश्यकता है तो सिस्टम स्मृति ठीक करने के लिए प्रक्रियाओं पृष्ठभूमि शट डाउन करना होगा।

तो वैश्विक (स्थैतिक) वस्तुओं के रूप में निरंतर (परिवर्तनीय) वस्तुओं को स्टोर करना सुरक्षित नहीं है। आमतौर पर आप अपरिवर्तनीय स्थिरांक के लिए static का उपयोग करते हैं।

सरल शब्दों में, आप अपने आवेदन को स्क्रीन (क्रियाकलाप) में अलग करते हैं। फिर प्रत्येक स्क्रीन - टुकड़ों (टुकड़े) में। स्क्रीन पर कार्रवाइयों का अनुक्रम करने के लिए आप उन्हें Fragments (example) का उपयोग करके अलग भी कर सकते हैं।

तो आपके आवेदन में बहुत छोटे ब्लॉक हैं, जिनमें से प्रत्येक आप आसानी से परीक्षण और पुन: उपयोग कर सकते हैं।