Android एप्लिकेशन आर्किटेक्चर। भाग III - आवेदन के मुख्य भाग

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

यह आलेख एंड्रॉइड एप्लिकेशन की वास्तुकला के मुख्य "वर्ण" को पेश करेगा।

सामान्य तौर पर, Android एप्लिकेशन में निम्न शामिल होते हैं:

• जावा वर्ग जो एंड्रॉइड एसडीके ( देखें , गतिविधि , कंटेंटप्रोवाइडर , सर्विस , ब्रॉडकास्टरेवर , इंटेंट ) और जावा कक्षाओं से कोर कक्षाओं के उपवर्ग हैं, जिनके एंड्रॉइड एसडीके में माता-पिता नहीं हैं।
• आवेदन प्रकट
• तार, चित्र आदि जैसे संसाधन।
• फ़ाइलें

जावा कक्षाएं

निम्नलिखित चित्र एंड्रॉइड एसडीके से मुख्य वर्गों के पदानुक्रम को दिखाता है जिसे डेवलपर को निपटना है:



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

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

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

जीवन चक्र के दौरान, एक गतिविधि तीन अवस्थाओं में से एक में हो सकती है:

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

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

ContentProvider वर्ग और उसके उप-वर्ग MVVM वास्तुकला में मॉडल का प्रतिनिधित्व करते हैं। अधिकांश व्यावहारिक मामलों में, यह SQLite डेटाबेस पर थोड़ा फैंसी URI- आधारित एक्सेस विधि के साथ एक आवरण है। सैद्धांतिक रूप से, कोई भी किसी भी चीज़ के आधार पर एक डेटाबेस पर एक ContentProvider बनाने के लिए डेवलपर को परेशान नहीं करता है। हालाँकि, मौजूदा सामग्री प्रदाता क्वेरी () विधि एक कर्सर ऑब्जेक्ट लौटाती है, जो कि JDBC ResultSet इंटरफ़ेस और यह कैसे काम करता है, के समान है। इसलिए, यह संभावना नहीं है कि किसी को भी संदेह होगा कि सामग्री प्रदाताओं का वास्तविक उद्देश्य एक डेटाबेस को एनकैप्सुलेट करना है।

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

और यही कारण है कि मुझे ऐसा लगता है। सामग्री प्रदाताओं का मूल विचार AJAX अनुप्रयोगों की वास्तुकला पर आधारित लगता है। AJAX एप्लिकेशन आम तौर पर MVVM आर्किटेक्चर का उपयोग करते हैं, जहां मॉडल को सर्वर-साइड URI के रूप में दर्शाया जाता है (हालांकि, यह HTML5 के साथ बदल गया है, जो आपको स्थानीय रूप से डेटा स्टोर करने की अनुमति देता है)। वास्तव में, तथ्य यह है कि सामग्री प्रदाताओं को URI का उपयोग करने का अनुरोध किया जाता है और MIME प्रकारों का उपयोग करके एक एक्सटेंशन बनाने से संकेत मिलता है कि AJAX कोर में है। मुझे याद दिलाएं, Google के दोस्तों ने बड़ी संख्या में AJAX एप्लिकेशन बनाए हैं, जैसे कि जीमेल, Google डॉक्स, इत्यादि, इसलिए यह काफी स्वाभाविक है कि विचारों को AJAX वास्तुकला से उधार लिया गया था।

शायद कोई और व्यक्ति एक और महान विचार के साथ आया: मोबाइल डिवाइस पर पूर्ण रिलेशनल डेटाबेस होना बहुत अच्छा होगा! (मैं ध्यान दें कि यह 2005 के आसपास था, जब मोबाइल फोन अब की तुलना में बहुत कमजोर थे)। और, परिणामस्वरूप, उन्होंने दो अच्छे विचारों को एक ContentProvider वर्ग में संयोजित किया। जैसा कि आमतौर पर सॉफ्टवेयर विकास में होता है, दो अच्छे विचारों के संयोजन से हमेशा अच्छे विचार नहीं आते हैं; Android के मामले में, हमारे पास सामग्री प्रदाताओं के लिए कुछ हतोत्साहित करने वाला डिज़ाइन है।

सेवा वर्ग और उसके उपवर्ग मुझे किसी भी तरह वर्गीकृत करना मुश्किल लगता है। मुझे लगता है कि Google के लोग समान कठिनाइयों का सामना कर रहे हैं (कृपया उनके दस्तावेज़ पढ़ें)। उनका वर्गीकरण मूल रूप से कहता है कि यह वर्ग क्या नहीं है। मुझे व्यक्तिगत रूप से लगता है कि एक सेवा मॉडल की एक भिन्नता है जो ContentProvider की तुलना में थोड़ा अलग उपयोग मामलों में कार्य करती है।

मेरी राय में, Android सेवा का वास्तुशिल्प डिजाइन OSGI सेवाओं से प्रेरित है।

मुझे लगता है कि एंड्रॉइड थ्रेडिंग मॉडल के कारण पैदा हुई तार्किक समस्या के समाधान के रूप में Google द्वारा लोगों द्वारा सेवाएं बनाई गई थीं।

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

और यहां सेवाएं बचाव के लिए आती हैं। उन्हें तब भी निष्पादित किया जा सकता है जब वे जिस प्रक्रिया में काम करते हैं वह अग्रभूमि में नहीं है। इसलिए, यदि आप एक ऐसी गतिविधि विकसित कर रहे हैं, जो समय-समय पर किए गए ऑपरेशन को पूरा करती है, जो कि पृष्ठभूमि में काम करते समय भी समाप्त होनी चाहिए, तो आपको एक ऐसी सेवा बनानी होगी जो इस ऑपरेशन को लागू करती है और इसे गतिविधि से शुरू करती है।

सेवा का एक जीवन चक्र भी होता है। इसका मतलब यह है कि इसे एंड्रॉइड एप्लिकेशन द्वारा कुछ स्थिति के तहत त्वरित और लॉन्च किया जा सकता है (हम बाद में इस पर चर्चा करेंगे)।

जैसा कि मैंने उल्लेख किया है, सेवा, मॉडल की तरह, ContentProvier की तुलना में अधिक सामान्य लक्ष्य हैं। यह डेटाबेस का उपयोग कर सकता है, लेकिन इसका API डेटाबेस से संबंधित नहीं है, जैसा कि ContentProvider के मामले में है। ज्यादातर मामलों में, बाहरी सर्वर के साथ संचार करने के लिए सेवाओं का उपयोग किया जाता है।

ब्रॉडकास्टसीवर वर्ग और उसके उपवर्ग एंड्रॉइड आर्किटेक्चर में कार्यान्वित प्रकाशक / ग्राहक इंटरैक्शन तंत्र में "ग्राहक" का प्रतिनिधित्व करते हैं।

हम पिछले लेख में बातचीत के तंत्र के बारे में बात कर चुके हैं।

बेशक, एक एंड्रॉइड डेवलपर एंड्रॉइड एसडीके से केवल विस्तारित कक्षाओं तक सीमित नहीं है। वह अपनी इच्छानुसार अपनी कक्षाएं लिख सकता है। लेकिन वे सभी एंडोर्ड एसडीके से कक्षाओं के लिए केवल "सहायक वर्ग" होंगे।

Android प्रकट

एंड्रॉइड मैनिफ़ेस्ट एंड्रॉइड ऐप का एक और महत्वपूर्ण हिस्सा है। विचार ग्रहण के लिए प्लगइन मैनिफेस्टों से प्रेरित था।

Android मेनिफ़ेस्ट एक XML फ़ाइल है और कई फ़ंक्शन करता है। यहां बताया गया है कि Google उनका वर्णन कैसे करता है:

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

दूसरे बिंदु पर ध्यान दें। इसका मतलब यह है कि यदि आपके आवेदन में किसी निश्चित वर्ग की गतिविधि, ContentProvider, BroadcastReceiver या सेवा का विस्तार होता है, तो इस वर्ग का उपयोग तब तक नहीं किया जा सकता है जब तक कि इसे प्रकट में वर्णित नहीं किया जाता है।

साधन

एक या दूसरे रूप में प्रत्येक आधुनिक जीयूआई आवेदन संसाधनों का उपयोग करता है। Android ऐप्स कोई अपवाद नहीं हैं। वे निम्नलिखित प्रकार के संसाधनों का उपयोग करते हैं:

• छवि
• GUI परतें (XML फ़ाइलें)
• मेनू घोषणाएँ (XML फ़ाइलें)
• पाठ तार

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

आइए निम्नलिखित उदाहरण देखें। Mybutton.png नामक फ़ाइल में बटन के लिए एक चित्र है। डेवलपर एक गलती करता है और कोड से संसाधन का जिक्र करते हुए mybuton.png डायल करता है। नतीजतन, कोड एक गैर-मौजूद संसाधन का उपयोग करने की कोशिश करता है, लेकिन संकलन सफल होगा। परीक्षण के दौरान केवल एक त्रुटि का पता लगाया जा सकता है (या इसका पता नहीं लगाया जा सकता है)।

Google के लोगों ने इस समस्या का एक सुंदर समाधान खोजा है। Android एप्लिकेशन का निर्माण करते समय, R (सिर्फ एक अक्षर) नाम के साथ एक विशेष जावा वर्ग उत्पन्न होता है। इस वर्ग में कई स्थिर अंतिम डेटासेट शामिल हैं। ऐसा प्रत्येक डेटा सेट एक अलग संसाधन की एक कड़ी है। इन लिंक का उपयोग एप्लिकेशन कोड में संसाधनों के साथ संचार करने के लिए किया जाता है। अब, संसाधनों के लिंक में प्रत्येक त्रुटि संकलन प्रक्रिया में स्वयं प्रकट होती है।

फ़ाइलें

Android एप्लिकेशन कई अलग-अलग फ़ाइल प्रकारों का उपयोग करता है:

• सामान्य प्रयोजन फाइलें
• डीबी फाइलें
• अपारदर्शी बाइनरी ब्लॉब ( OBB ) फाइलें (वे एक एन्क्रिप्टेड फाइल सिस्टम हैं जो एप्लिकेशन के लिए माउंट की जा सकती हैं)
• कैश्ड फाइलें

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

फ़ाइलों के साथ काम करने के लिए एपीआई को कॉनटेक्स्ट क्लास द्वारा कार्यान्वित किया जाता है, जहां से गतिविधि और सेवा कक्षाएं ली जाती हैं। हमारे द्वारा इस वर्ग की चर्चा पहले ही की जा चुकी है ।

आज के लिए बस इतना ही। अगले लेख में, हम इस बारे में बात करेंगे कि एंड्रॉइड एप्लिकेशन के विभिन्न भाग एक-दूसरे के साथ कैसे बातचीत करते हैं।

पिछले लेख:

• Android एप्लिकेशन आर्किटेक्चर। भाग I - मूल
• Android एप्लिकेशन आर्किटेक्चर। भाग II - वास्तुकला शैलियाँ और पैटर्न

अगला लेख: Android एप्लिकेशन आर्किटेक्चर। भाग IV - एकीकरण स्तर