इस लेख में, हम एंड्रॉइड एप्लिकेशन में उपयोग किए जाने वाले वास्तुशिल्प पैटर्न के बारे में बात करेंगे।
एक निश्चित वास्तुकला के भीतर लागू पैटर्न को समझना महत्वपूर्ण क्यों है? क्योंकि इस तरह से हम जिस नए आर्किटेक्चर का अध्ययन कर रहे हैं, वह हमारे पिछले अनुभव के संदर्भ में फिट बैठता है और हमें अपने संचित ज्ञान और कौशल का अधिक प्रभावी ढंग से उपयोग करने की अनुमति देता है।
मैंने खराब तरीके से खोजा हो सकता है, लेकिन एंड्रॉइड प्रलेखन में किसी भी टेम्पलेट का कोई उल्लेख नहीं है। इसके बावजूद, एंड्रॉइड ने कुछ टेम्प्लेट और वास्तुशिल्प शैलियों को लागू किया है, जिनके बारे में हम अभी बात करेंगे।
एंड्रॉइड आर्किटेक्चर एक फ्रेमवर्क-आधारित आर्किटेक्चर है, जैसा कि एक फ्री-स्टाइल आर्किटेक्चर के विपरीत है।
अंतर क्या है? जावा में लिखे गए नि: शुल्क एप्लिकेशन एक ऐसे वर्ग के साथ शुरू होते हैं जिसमें एक
मुख्य () विधि होती है और डेवलपर के मूड के अनुसार पूर्ण रूप से विकसित होती है।
इसके विपरीत, रूपरेखा-उन्मुख अनुप्रयोग मौजूदा ढांचे पर निर्भर करते हैं। उनका विकास कुछ वर्गों के विस्तार या ढांचे द्वारा प्रदान किए गए इंटरफेस के कार्यान्वयन के लिए नीचे आता है। इस तरह के एप्लिकेशन को फ्रेमवर्क के बाहर या इसके बिना लॉन्च नहीं किया जा सकता है। एक उदाहरण जावा वेब अनुप्रयोग होगा, जिसमें डेवलपर्स
सर्वलेट इंटरफ़ेस को लागू करते हैं या इसके कार्यान्वयन में से एक का विस्तार करते हैं, या एक
ग्रहण आरसीपी अनुप्रयोग जिसमें एक डेवलपर
संपादक या
दृश्य वर्गों में से एक का विस्तार करता है।
एक फ्रेमवर्क-ओरिएंटेड आर्किटेक्चर डेवलपर्स की स्वतंत्रता को यह निर्देश देता है कि उन्हें क्या और कैसे करना है। लेकिन, अंत में, कोड के दोहराए गए खंड (बॉयलरप्लेट कोड) गायब हो जाते हैं, और डेवलपर्स को डिजाइन पैटर्न का पालन करना होगा (मैं इस पर विश्वास करना चाहता हूं)।
जावा के लिए कई रूपरेखाएं हैं। हालाँकि, Android टीम ने अपना खुद का बनाने का फैसला किया। शायद इसका एक कारण यह था कि एक अद्वितीय स्मृति प्रबंधन प्रणाली को बनाए रखने की आवश्यकता थी।
"सामान्य" जावा में, ऑब्जेक्ट तब तक मेमोरी में होते हैं जब तक कचरा कलेक्टर उन तक नहीं पहुंच जाता है। यह केवल तब होता है जब "लाइव" ऑब्जेक्ट्स से ऑब्जेक्ट का एक भी लिंक नहीं होता है (अधिक विवरण
यहां पढ़ा जा सकता
है )। Android में, यह मामला नहीं है। यदि एक निश्चित उपयोगकर्ता इंटरफ़ेस छिपा हुआ है (अर्थात, यह अब स्क्रीन पर दिखाई नहीं देता है), तो इसकी कोई गारंटी नहीं है कि यह मेमोरी में है, यहां तक कि भविष्य में इसका उपयोग करने वाला एक एप्लिकेशन भी है। यदि एंड्रॉइड ओएस में पर्याप्त मुक्त मेमोरी है, तो इन ऑब्जेक्ट्स को इसमें संग्रहीत किया जा सकता है, लेकिन कचरा कलेक्टर किसी भी समय उन्हें नष्ट कर सकता है जब ओएस तय करता है कि बहुत कम मेमोरी बची है। प्रक्रियाओं के लिए भी यही सच है। एक प्रक्रिया जो वर्तमान में उपयोगकर्ता को नहीं दिखाती है किसी भी ग्राफिकल इंटरफ़ेस को एंड्रॉइड ओएस द्वारा पूरी तरह से नष्ट किया जा सकता है (इस नियम -
सेवाओं का एक अपवाद है; हम इस बारे में बाद में बात करेंगे)।
एक उदाहरण पर विचार करें। हमारे एप्लिकेशन में स्क्रीन ए और बी हैं। उपयोगकर्ता पहले स्क्रीन ए, और फिर स्क्रीन बी खोलता है; उस क्षण से, स्क्रीन ए अदृश्य हो गई। इसका मतलब यह है कि स्क्रीन ए और इसमें निहित सभी तर्क स्मृति में हो सकते हैं या नहीं भी हो सकते हैं। इसलिए, इस बात की कोई गारंटी नहीं है कि स्क्रीन A से जुड़ी वस्तुएं स्क्रीन B के दृश्य में हैं, जबकि स्क्रीन B का तर्क स्मृति में स्क्रीन A की वस्तुओं को खोजने के लिए बंधा नहीं होना चाहिए। एक पक्ष प्रभाव यह है कि एंड्रॉइड आर्किटेक्चर
"साझा कुछ भी नहीं" शैली की वास्तुकला शैली का उपयोग करने के लिए मजबूर करता है। इसका मतलब है कि एंड्रॉइड एप्लिकेशन के विभिन्न भाग एक-दूसरे को कॉल कर सकते हैं और केवल औपचारिक रूप से बातचीत कर सकते हैं; उनमें से कोई भी दूसरे को सीधे संबोधित नहीं कर सकता है।
ठीक है, अगर उपयोगकर्ता स्क्रीन ए पर लौटने का फैसला करता है तो क्या होगा? वह शायद उसे उसी अवस्था में देखना चाहता है जिसमें उसने उसे छोड़ा था, है ना? यहां बताया गया है कि एंड्रॉइड फ्रेमवर्क इस समस्या को कैसे हल करता है: जीवन चक्र के प्रत्येक राज्य के लिए, विधियां हैं, जिनमें से प्रत्येक को डेवलपर द्वारा ओवरराइड किया जा सकता है। इन विधियों को पूर्व निर्धारित प्रमुख बिंदुओं पर रूपरेखा द्वारा बुलाया जाता है, उदाहरण के लिए, जब उपयोगकर्ता इंटरफ़ेस स्क्रीन पर प्रदर्शित होता है, छिपा हुआ आदि। इन विधियों में, डेवलपर ऑब्जेक्ट्स की स्थिति को संग्रहीत करने और पुनर्स्थापित करने के लिए तर्क को लागू कर सकता है।
उपयोगकर्ता इंटरफेस को छिपाने के लिए इसी तरह की प्रक्रिया और एंड्रॉइड डिवाइस पर एक बैक बटन के अस्तित्व के लिए उपयोगकर्ता इंटरफ़ेस
का एक
स्टैक होना आवश्यक है, जिसमें वर्तमान दृश्यमान इंटरफ़ेस शीर्ष पर रखा गया है, और अन्य सभी को नीचे धकेल दिया गया है (स्टैक किए गए पुश ऑपरेशन)। "पीछे" दबाने से स्टैक के ऊपर से इंटरफ़ेस हटा दिया जाता है और इसके पीछे का तत्व दिखाता है (स्टैक ऑपरेशन "पॉप")। एंड्रॉइड में एक समान स्टैक मौजूद है। प्रलेखन में, इसे "गतिविधि स्टैक" या कभी-कभी
"बैक स्टैक" कहा जाता है ।
उपयोगकर्ता इंटरफ़ेस और इसके तर्क के बीच बातचीत को संभालने के मामले में, एंड्रॉइड आर्किटेक्चरल
मॉडल-व्यू-व्यूमॉडल (एमवीवीएम) पैटर्न का अनुसरण करता है। डेवलपर्स के लिए यह अच्छी खबर है, क्योंकि एमवीवीएम इस समय सबसे अच्छा जीयूआई एप्लीकेशन आर्किटेक्चर है।
MVVM आर्किटेक्चर डिज़ाइनर और प्रोग्रामर के काम को अलग करने के लिए बनाया गया था, जो तब संभव नहीं है जब कोई जावा डेवलपर स्विंग में GUI बनाने की कोशिश करता है या कोई Visual C ++ डेवलपर MFC में यूजर इंटरफेस बनाने की कोशिश करता है। डेवलपर्स स्मार्ट लोग हैं और उनमें बहुत सारे कौशल हैं, लेकिन उपयोगकर्ता के अनुकूल और आकर्षक इंटरफेस बनाने के लिए उनके पास पूरी तरह से अलग प्रतिभाओं की आवश्यकता होती है जो उनके पास हैं। यह काम इंटरफ़ेस डिजाइनरों के लिए अधिक उपयुक्त है। अच्छे इंटरफ़ेस डिज़ाइनर बेहतर जानते हैं कि उपयोगकर्ताओं को डिज़ाइनिंग और कोड लिखने में विशेषज्ञों की तुलना में क्या पसंद है। यह स्पष्ट है कि यदि इंटरफ़ेस डिज़ाइनर इंटरफ़ेस बनाता है तो बेहतर होगा, और डेवलपर कोड लिखता है जो इस इंटरफ़ेस के तर्क को लागू करता है, लेकिन स्विंग या MFC जैसी प्रौद्योगिकियाँ बस इसकी अनुमति नहीं देती हैं।
MVVM आर्किटेक्चर स्पष्ट रूप से जिम्मेदारियों को साझा करके इस समस्या को हल करता है:
- यूजर इंटरफेस का विकास इंटरफेस डिज़ाइनर द्वारा इस तरह के काम के लिए कम या ज्यादा प्राकृतिक तकनीक का उपयोग करके किया जाता है (XML)
- उपयोगकर्ता इंटरफ़ेस तर्क डेवलपर द्वारा ViewModel के एक घटक के रूप में कार्यान्वित किया जाता है
- उपयोगकर्ता इंटरफ़ेस और ViewModel के बीच कार्यात्मक कनेक्शन बाइंडिंग के माध्यम से कार्यान्वित किए जाते हैं, जो, संक्षेप में, "बटन ए दबाया गया था जैसे नियम हैं, तो ViewModel से onButtonAClick () विधि को बुलाया जाना चाहिए"। बाइंडिंग को कोड में लिखा जा सकता है या घोषित रूप से परिभाषित किया जा सकता है (एंड्रॉइड दोनों प्रकार का उपयोग करता है)।
MVVM आर्किटेक्चर का उपयोग सभी आधुनिक तकनीकों द्वारा एक फॉर्म या किसी अन्य में किया जाता है, उदाहरण के लिए Microsoft WPF और सिल्वरलाइट, Oracle JavaFX, Adobe Flex, AJAX।
हमने उल्लेख किया है कि एंड्रॉइड एप्लिकेशन के विभिन्न भाग एक दूसरे को कॉल कर सकते हैं और केवल औपचारिक रूप से बातचीत कर सकते हैं। यह कैसे प्राप्त किया जाता है? एंड्रॉइड फ्रेमवर्क कई इंटरैक्शन पैटर्न का उपयोग करता है:
अगर इसमें से कोई भी अजीब लगे तो चिंता न करें। विस्तृत विवरण निम्नलिखित लेखों में होगा।
आज के लिए बस इतना ही।
पिछला लेख:
Android एप्लिकेशन आर्किटेक्चर। भाग I - मूलनिम्नलिखित लेख: