ऐप्लिकेशन के आर्किटेक्चर की गाइड

इस गाइड में, बेहतर और अच्छी क्वालिटी वाले ऐप्लिकेशन बनाने के लिए, सबसे सही तरीके और सुझाया गया आर्किटेक्चर शामिल है.

मोबाइल ऐप्लिकेशन इस्तेमाल करने वाले लोगों को मिलने वाला अनुभव

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

ध्यान रखें कि मोबाइल डिवाइसों में भी संसाधनों की कमी होती है. इसलिए, नए ऐप्लिकेशन के लिए जगह बनाने के लिए, ऑपरेटिंग सिस्टम कभी भी कुछ ऐप्लिकेशन की प्रोसेस को बंद कर सकता है.

इस एनवायरमेंट की शर्तों को देखते हुए, आपके ऐप्लिकेशन के कॉम्पोनेंट को अलग-अलग और गलत क्रम में लॉन्च किया जा सकता है. साथ ही, ऑपरेटिंग सिस्टम या उपयोगकर्ता उन्हें कभी भी मिटा सकता है. ये इवेंट आपके कंट्रोल में नहीं होते. इसलिए, आपको अपने ऐप्लिकेशन के कॉम्पोनेंट में, किसी भी ऐप्लिकेशन डेटा या स्टेटस को स्टोर या मेमोरी में नहीं रखना चाहिए. साथ ही, आपके ऐप्लिकेशन के कॉम्पोनेंट एक-दूसरे पर निर्भर नहीं होने चाहिए.

आर्किटेक्चर से जुड़े सामान्य सिद्धांत

अगर आपको ऐप्लिकेशन के डेटा और स्टेटस को सेव करने के लिए, ऐप्लिकेशन कॉम्पोनेंट का इस्तेमाल नहीं करना चाहिए, तो आपको अपने ऐप्लिकेशन को कैसे डिज़ाइन करना चाहिए?

Android ऐप्लिकेशन के साइज़ में बढ़ोतरी होने पर, यह तय करना ज़रूरी होता है कि ऐप्लिकेशन को किस तरह से स्केल किया जाए. इससे ऐप्लिकेशन को बेहतर बनाने और उसकी जांच करने में आसानी होती है.

ऐप्लिकेशन के आर्किटेक्चर से, ऐप्लिकेशन के हिस्सों के बीच की सीमाओं और हर हिस्से की ज़िम्मेदारियों के बारे में पता चलता है. ऊपर बताई गई ज़रूरतों को पूरा करने के लिए, आपको अपने ऐप्लिकेशन के आर्किटेक्चर को कुछ खास सिद्धांतों के मुताबिक डिज़ाइन करना चाहिए.

गौर करने लायक अलग-अलग बातें

सबसे ज़रूरी सिद्धांत है, अलग-अलग समस्याओं को अलग-अलग रखना. आम तौर पर, सभी कोड को Activity या Fragment में लिखा जाता है. यूज़र इंटरफ़ेस (यूआई) पर आधारित इन क्लास में, सिर्फ़ यूआई और ऑपरेटिंग सिस्टम के इंटरैक्शन को मैनेज करने वाला लॉजिक होना चाहिए. इन क्लास को जितना हो सके उतना छोटा रखकर, कॉम्पोनेंट लाइफ़साइकल से जुड़ी कई समस्याओं से बचा जा सकता है. साथ ही, इन क्लास को टेस्ट करने की सुविधा को बेहतर बनाया जा सकता है.

ध्यान रखें कि Activity और Fragment को लागू करने का अधिकार आपके पास नहीं है. ये सिर्फ़ ग्लू क्लास हैं, जो Android OS और आपके ऐप्लिकेशन के बीच के समझौते को दिखाती हैं. उपयोगकर्ता के इंटरैक्शन या कम मेमोरी जैसी सिस्टम की स्थितियों के आधार पर, OS इन्हें कभी भी मिटा सकता है. उपयोगकर्ताओं को बेहतर अनुभव देने और ऐप्लिकेशन को आसानी से मैनेज करने के लिए, इन पर कम से कम निर्भर रहें.

डेटा मॉडल से Drive का यूज़र इंटरफ़ेस (यूआई) बनाना

एक और अहम सिद्धांत यह है कि आपको अपने यूज़र इंटरफ़ेस (यूआई) को डेटा मॉडल से चलाना चाहिए. इसके लिए, बेहतर होगा कि आप हमेशा काम करने वाले मॉडल का इस्तेमाल करें. डेटा मॉडल, किसी ऐप्लिकेशन के डेटा को दिखाते हैं. ये आपके ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) एलिमेंट और अन्य कॉम्पोनेंट से अलग होते हैं. इसका मतलब है कि ये यूआई और ऐप्लिकेशन कॉम्पोनेंट के लाइफ़साइकल से जुड़े नहीं होते. हालांकि, जब ओएस ऐप्लिकेशन की प्रोसेस को मेमोरी से हटाने का फ़ैसला लेता है, तब भी इन्हें मिटा दिया जाएगा.

पर्सिस्टेंट मॉडल इन वजहों से सबसे सही होते हैं:

  • अगर Android OS, संसाधनों को खाली करने के लिए आपके ऐप्लिकेशन को मिटा देता है, तो आपके उपयोगकर्ताओं का डेटा नहीं मिटता.

  • आपका ऐप्लिकेशन ऐसे मामलों में भी काम करता रहेगा, जब नेटवर्क कनेक्शन ठीक से काम न कर रहा हो या उपलब्ध न हो.

अगर आपने अपने ऐप्लिकेशन के आर्किटेक्चर को डेटा मॉडल क्लास पर आधारित किया है, तो आपके ऐप्लिकेशन को ज़्यादा जांचा जा सकता है और उसे बेहतर बनाया जा सकता है.

एक ही सोर्स से जानकारी पाना

जब आपके ऐप्लिकेशन में कोई नया डेटा टाइप तय किया जाता है, तो आपको उसमें एक सिंगल सोर्स ऑफ़ ट्रूथ (एसएसओटी) असाइन करना चाहिए. एसएसओटी उस डेटा का मालिक होता है और सिर्फ़ एसएसओटी ही उसमें बदलाव कर सकता है. ऐसा करने के लिए, एसएसओटी, डेटा को अपरिवर्तनीय टाइप का इस्तेमाल करके दिखाता है. साथ ही, डेटा में बदलाव करने के लिए, एसएसओटी ऐसे फ़ंक्शन दिखाता है या ऐसे इवेंट पाता है जिन्हें दूसरे टाइप कॉल कर सकते हैं.

इस पैटर्न से कई फ़ायदे मिलते हैं:

  • यह किसी खास तरह के डेटा में किए गए सभी बदलावों को एक ही जगह पर सेंट्रलाइज़ करता है.
  • यह डेटा को सुरक्षित रखता है, ताकि दूसरे लोग उसमें बदलाव न कर सकें.
  • इससे डेटा में किए गए बदलावों को आसानी से ट्रैक किया जा सकता है. इसलिए, गड़बड़ियों का पता लगाना आसान हो जाता है.

ऑफ़लाइन-फ़र्स्ट ऐप्लिकेशन में, ऐप्लिकेशन डेटा का सोर्स आम तौर पर डेटाबेस होता है. कुछ अन्य मामलों में, सच्चाई का सोर्स, ViewModel या यूज़र इंटरफ़ेस (यूआई) भी हो सकता है.

एकतरफ़ा डेटा फ़्लो

सही जानकारी का एक ही सोर्स का सिद्धांत, अक्सर हमारी गाइड में यूनीडायरेक्शनल डेटा फ़्लो (यूडीएफ़) पैटर्न के साथ इस्तेमाल किया जाता है. यूडीएफ़ में, स्टेट सिर्फ़ एक दिशा में फ़्लो करता है. ऐसे इवेंट जो डेटा फ़्लो को उल्टी दिशा में बदलते हैं.

Android में, स्टेटस या डेटा आम तौर पर हैरारकी के बड़े स्कोप वाले टाइप से छोटे स्कोप वाले टाइप में फ़्लो होता है. इवेंट आम तौर पर, कम स्कोप वाले टाइप से तब तक ट्रिगर होते हैं, जब तक वे उस डेटा टाइप के एसएसओटी तक नहीं पहुंच जाते. उदाहरण के लिए, ऐप्लिकेशन डेटा आम तौर पर डेटा सोर्स से यूज़र इंटरफ़ेस (यूआई) में फ़्लो करता है. बटन दबाने जैसे उपयोगकर्ता इवेंट, यूज़र इंटरफ़ेस (यूआई) से एसएसओटी में फ़्लो होते हैं. यहां ऐप्लिकेशन डेटा में बदलाव किया जाता है और उसे ऐसा डेटा टाइप में दिखाया जाता है जिसे बदला नहीं जा सकता.

इस पैटर्न से, डेटा के एक जैसा रहने की गारंटी मिलती है. साथ ही, इसमें गड़बड़ियों की संभावना कम होती है और इसे डीबग करना आसान होता है. साथ ही, इसमें एसएसओटी पैटर्न के सभी फ़ायदे मिलते हैं.

इस सेक्शन में, सुझाए गए सबसे सही तरीकों का पालन करके, अपने ऐप्लिकेशन को स्ट्रक्चर करने का तरीका बताया गया है.

पिछले सेक्शन में बताए गए, आर्किटेक्चर के सामान्य सिद्धांतों को ध्यान में रखते हुए, हर ऐप्लिकेशन में कम से कम दो लेयर होनी चाहिए:

  • यूज़र इंटरफ़ेस (यूआई) लेयर, जो स्क्रीन पर ऐप्लिकेशन का डेटा दिखाती है.
  • डेटा लेयर, जिसमें आपके ऐप्लिकेशन का कारोबारी लॉजिक होता है और ऐप्लिकेशन का डेटा दिखाया जाता है.

यूज़र इंटरफ़ेस (यूआई) और डेटा लेयर के बीच इंटरैक्शन को आसान बनाने और फिर से इस्तेमाल करने के लिए, डोमेन लेयर नाम की एक और लेयर जोड़ी जा सकती है.

आम तौर पर, ऐप्लिकेशन के आर्किटेक्चर में यूज़र इंटरफ़ेस लेयर को ऐप्लिकेशन का डेटा, डेटा लेयर या वैकल्पिक डोमेन लेयर से मिलता है. यह लेयर, यूज़र इंटरफ़ेस लेयर और डेटा लेयर के बीच होती है.
पहली इमेज. किसी सामान्य ऐप्लिकेशन के आर्किटेक्चर का डायग्राम.

आधुनिक ऐप्लिकेशन आर्किटेक्चर

आधुनिक ऐप्लिकेशन आर्किटेक्चर में, इनके अलावा और भी तकनीकों का इस्तेमाल करने का सुझाव दिया जाता है:

  • रिएक्टिव और लेयर वाला आर्किटेक्चर.
  • ऐप्लिकेशन की सभी लेयर में एकतरफ़ा डेटा फ़्लो (यूडीएफ़).
  • यूज़र इंटरफ़ेस (यूआई) की जटिलता को मैनेज करने के लिए, स्टेट होल्डर वाली यूआई लेयर.
  • कोरूटीन और फ़्लो.
  • डिपेंडेंसी इंजेक्शन के सबसे सही तरीके.

ज़्यादा जानकारी के लिए, यहां दिए गए सेक्शन देखें. साथ ही, विषय सूची में मौजूद, आर्किटेक्चर के दूसरे पेजों और सुझावों वाले पेज पर जाएं. इस पेज पर, सबसे सही तरीकों की खास जानकारी दी गई है.

यूज़र इंटरफ़ेस (यूआई) लेयर

यूज़र इंटरफ़ेस (यूआई) लेयर या प्रज़ेंटेशन लेयर की भूमिका, स्क्रीन पर ऐप्लिकेशन का डेटा दिखाना है. जब भी डेटा में बदलाव होता है, तो उपयोगकर्ता के इंटरैक्शन (जैसे, बटन दबाना) या बाहरी इनपुट (जैसे, नेटवर्क रिस्पॉन्स) की वजह से, यूज़र इंटरफ़ेस (यूआई) को अपडेट करना चाहिए, ताकि बदलावों को दिखाया जा सके.

यूज़र इंटरफ़ेस लेयर दो चीज़ों से बनी होती है:

  • यूज़र इंटरफ़ेस (यूआई) एलिमेंट, जो स्क्रीन पर डेटा रेंडर करते हैं. इन एलिमेंट को बनाने के लिए, व्यू या Jetpack Compose फ़ंक्शन का इस्तेमाल किया जाता है.
  • स्टेटस होल्डर (जैसे, ViewModel क्लास), जो डेटा को सेव करते हैं, उसे यूज़र इंटरफ़ेस (यूआई) पर दिखाते हैं, और लॉजिक को मैनेज करते हैं.
आम तौर पर, यूआई लेयर के यूआई एलिमेंट, स्टेटस होल्डर पर निर्भर करते हैं. ये स्टेटस होल्डर, डेटा लेयर या वैकल्पिक डोमेन लेयर की क्लास पर निर्भर करते हैं.
दूसरी इमेज. ऐप्लिकेशन के आर्किटेक्चर में यूज़र इंटरफ़ेस लेयर की भूमिका.

इस लेयर के बारे में ज़्यादा जानने के लिए, यूज़र इंटरफ़ेस (यूआई) लेयर वाला पेज देखें.

डेटा लेयर

किसी ऐप्लिकेशन की डेटा लेयर में कारोबारी लॉजिक होता है. आपके ऐप्लिकेशन को अहमियत देने वाला मुख्य लॉजिक, कारोबार का लॉजिक होता है. यह नियमों से बना होता है. इन नियमों से यह तय होता है कि आपका ऐप्लिकेशन, डेटा को कैसे बनाता है, सेव करता है, और उसमें बदलाव करता है.

डेटा लेयर, रिपॉज़िटरी से बनी होती है. हर रिपॉज़िटरी में शून्य से लेकर कई डेटा सोर्स हो सकते हैं. आपको अपने ऐप्लिकेशन में मैनेज किए जाने वाले हर तरह के डेटा के लिए, एक रिपॉज़िटरी क्लास बनानी चाहिए. उदाहरण के लिए, मूवी से जुड़े डेटा के लिए MoviesRepository क्लास या पेमेंट से जुड़े डेटा के लिए PaymentsRepository क्लास बनाई जा सकती है.

आम तौर पर, डेटा लेयर की रिपॉज़िटरी, बाकी ऐप्लिकेशन को डेटा उपलब्ध कराती हैं और डेटा सोर्स पर निर्भर करती हैं.
तीसरी इमेज. ऐप्लिकेशन के आर्किटेक्चर में डेटा लेयर की भूमिका.

रिपॉज़िटरी क्लास इन टास्क के लिए ज़िम्मेदार होती हैं:

  • बाकी ऐप्लिकेशन के साथ डेटा शेयर करना.
  • डेटा में बदलावों को एक ही जगह पर सेव करना.
  • एक से ज़्यादा डेटा सोर्स के बीच होने वाले अंतर को हल करना.
  • बाकी ऐप्लिकेशन से डेटा के सोर्स को अलग करना.
  • जिसमें कारोबारी नियम शामिल हों.

हर डेटा सोर्स क्लास को सिर्फ़ एक डेटा सोर्स के साथ काम करना चाहिए. यह डेटा सोर्स, कोई फ़ाइल, नेटवर्क सोर्स या स्थानीय डेटाबेस हो सकता है. डेटा सोर्स क्लास, डेटा ऑपरेशन के लिए ऐप्लिकेशन और सिस्टम के बीच का ब्रिज होती हैं.

इस लेयर के बारे में ज़्यादा जानने के लिए, डेटा लेयर वाला पेज देखें.

डोमेन लेयर

डोमेन लेयर एक वैकल्पिक लेयर है, जो यूज़र इंटरफ़ेस (यूआई) और डेटा लेयर के बीच होती है.

डोमेन लेयर, जटिल कारोबारी लॉजिक या ऐसे आसान कारोबारी लॉजिक को एन्कैप्सुलेट करने के लिए ज़िम्मेदार होती है जिसका इस्तेमाल कई व्यू मॉडल करते हैं. यह लेयर ज़रूरी नहीं है, क्योंकि सभी ऐप्लिकेशन में ये ज़रूरी शर्तें नहीं होंगी. इसका इस्तेमाल सिर्फ़ तब करना चाहिए, जब ज़रूरी हो. उदाहरण के लिए, जटिल समस्याओं को हल करने या फिर से इस्तेमाल करने के लिए.

शामिल होने पर, वैकल्पिक डोमेन लेयर, यूज़र इंटरफ़ेस (यूआई) लेयर को डिपेंडेंसी उपलब्ध कराती है और डेटा लेयर पर निर्भर करती है.
चौथी इमेज. ऐप्लिकेशन के आर्किटेक्चर में डोमेन लेयर की भूमिका.

इस लेयर में मौजूद क्लास को आम तौर पर इस्तेमाल के उदाहरण या इंटरैक्टर कहा जाता है. हर इस्तेमाल के उदाहरण में, सिर्फ़ एक फ़ंक्शन की ज़िम्मेदारी होनी चाहिए. उदाहरण के लिए, अगर स्क्रीन पर सही मैसेज दिखाने के लिए, एक से ज़्यादा ViewModel, टाइमज़ोन पर निर्भर करते हैं, तो आपके ऐप्लिकेशन में GetTimeZoneUseCase क्लास हो सकती है.

इस लेयर के बारे में ज़्यादा जानने के लिए, डोमेन लेयर वाला पेज देखें.

कॉम्पोनेंट के बीच डिपेंडेंसी मैनेज करना

आपके ऐप्लिकेशन में मौजूद क्लास, सही तरीके से काम करने के लिए अन्य क्लास पर निर्भर करती हैं. किसी खास क्लास की डिपेंडेंसी इकट्ठा करने के लिए, इनमें से किसी भी डिज़ाइन पैटर्न का इस्तेमाल किया जा सकता है:

  • डिपेंडेंसी इंजेक्शन (डीआई): डिपेंडेंसी इंजेक्शन की मदद से, क्लास को अपनी डिपेंडेंसी तय करने के लिए, उन्हें कॉन्स्ट्रक्ट करने की ज़रूरत नहीं होती. रनटाइम के दौरान, इन डिपेंडेंसी को उपलब्ध कराने की ज़िम्मेदारी किसी दूसरी क्लास की होती है.
  • सर्विस लोकेटर: सर्विस लोकेटर पैटर्न, एक रजिस्ट्री उपलब्ध कराता है. यहां क्लास, अपनी डिपेंडेंसी खुद बनाने के बजाय, उन्हें हासिल कर सकती हैं.

इन पैटर्न की मदद से, अपने कोड को स्केल किया जा सकता है. ऐसा इसलिए, क्योंकि ये कोड को डुप्लीकेट किए बिना या उसमें जटिलता जोड़े बिना, डिपेंडेंसी मैनेज करने के लिए साफ़ तौर पर पैटर्न उपलब्ध कराते हैं. इसके अलावा, इन पैटर्न की मदद से, टेस्ट और प्रोडक्शन के बीच तुरंत स्विच किया जा सकता है.

हमारा सुझाव है कि आप Android ऐप्लिकेशन में, डिपेंडेंसी इंजेक्शन पैटर्न का पालन करें और Hilt लाइब्रेरी का इस्तेमाल करें. Hilt, डिपेंडेंसी ट्री को वॉक करके ऑब्जेक्ट को अपने-आप बनाता है. साथ ही, डिपेंडेंसी पर कंपाइल के समय गारंटी देता है और Android फ़्रेमवर्क क्लास के लिए डिपेंडेंसी कंटेनर बनाता है.

सबसे सही तरीके

प्रोग्रामिंग एक क्रिएटिव फ़ील्ड है. Android ऐप्लिकेशन बनाना भी इसमें शामिल है. किसी समस्या को हल करने के कई तरीके हैं. जैसे, कई गतिविधियों या फ़्रैगमेंट के बीच डेटा शेयर करना, रिमोट डेटा को वापस लाना, और उसे ऑफ़लाइन मोड के लिए स्थानीय तौर पर सेव करना. इसके अलावा, ऐसी कई सामान्य स्थितियां हैं जिन्हें सामान्य ऐप्लिकेशन के मुकाबले, बेहतर ऐप्लिकेशन को मैनेज करना पड़ता है.

यहां दिए गए सुझावों को अपनाना ज़रूरी नहीं है. हालांकि, ज़्यादातर मामलों में इनका पालन करने से, आपका कोड बेस ज़्यादा मज़बूत बनता है. साथ ही, लंबे समय तक इसकी जांच की जा सकती है और इसे मैनेज किया जा सकता है:

ऐप्लिकेशन के कॉम्पोनेंट में डेटा सेव न करें.

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

Android क्लास पर निर्भरता कम करें.

आपके ऐप्लिकेशन के कॉम्पोनेंट ही ऐसी क्लास होने चाहिए जो Android फ़्रेमवर्क के SDK टूल के एपीआई पर निर्भर हों. जैसे, Context या Toast. अपने ऐप्लिकेशन में मौजूद अन्य क्लास को उनसे अलग करने से, जांच करने में मदद मिलती है. साथ ही, आपके ऐप्लिकेशन में कपलिंग कम हो जाती है.

अपने ऐप्लिकेशन के अलग-अलग मॉड्यूल के बीच, ज़िम्मेदारी की सीमाएं तय करें.

उदाहरण के लिए, नेटवर्क से डेटा लोड करने वाले कोड को अपने कोड बेस में मौजूद कई क्लास या पैकेज में न डालें. इसी तरह, एक ही क्लास में एक-दूसरे से अलग कई ज़िम्मेदारियां तय न करें. जैसे, डेटा कैश मेमोरी में सेव करना और डेटा को बांधना. सुझाए गए ऐप्लिकेशन आर्किटेक्चर का पालन करने से, आपको इसमें मदद मिलेगी.

हर मॉड्यूल से कम से कम जानकारी दिखाएं.

उदाहरण के लिए, ऐसा शॉर्टकट न बनाएं जो किसी मॉड्यूल के लागू होने की अंदरूनी जानकारी दिखाता हो. ऐसा करने से, आपको कम समय में काम पूरा करने में मदद मिल सकती है. हालांकि, कोडबेस के अपडेट होने पर, आपको कई बार तकनीकी बकाया चुकाना पड़ सकता है.

अपने ऐप्लिकेशन की खास बातों पर फ़ोकस करें, ताकि वह अन्य ऐप्लिकेशन से अलग दिखे.

एक ही बोइलरप्लेट कोड को बार-बार लिखकर, नया कोड न बनाएं. इसके बजाय, अपना समय और ऊर्जा इस बात पर लगाएं कि आपका ऐप्लिकेशन दूसरों से अलग कैसे हो. साथ ही, बार-बार इस्तेमाल होने वाले कोड को, Jetpack लाइब्रेरी और सुझाई गई अन्य लाइब्रेरी को मैनेज करने दें.

इस बात पर विचार करें कि अपने ऐप्लिकेशन के हर हिस्से को अलग-अलग टेस्ट कैसे किया जा सकता है.

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

टाइप, एक साथ कई क्वेरी चलाने की नीति के लिए ज़िम्मेदार होते हैं.

अगर कोई टाइप लंबे समय तक ब्लॉक करने वाला काम कर रहा है, तो उस हिसाब लगाने की प्रोसेस को सही थ्रेड पर ले जाने की ज़िम्मेदारी उस टाइप की होनी चाहिए. उस खास टाइप को पता होता है कि वह किस तरह का कैलकुलेशन कर रहा है और उसे किस थ्रेड में लागू किया जाना चाहिए. टाइप मुख्य-सुरक्षित होने चाहिए. इसका मतलब है कि उन्हें मुख्य थ्रेड से कॉल करने पर, उसे ब्लॉक नहीं किया जाता.

ज़्यादा से ज़्यादा काम का और नया डेटा सेव करें.

इससे, उपयोगकर्ता अपने डिवाइस के ऑफ़लाइन मोड में भी आपके ऐप्लिकेशन के फ़ंक्शन का आनंद ले सकते हैं. ध्यान रखें कि आपके सभी उपयोगकर्ताओं को लगातार, तेज़ इंटरनेट कनेक्शन नहीं मिलता. भले ही, उन्हें इंटरनेट कनेक्शन मिलता हो, लेकिन भीड़-भाड़ वाली जगहों पर उन्हें इंटरनेट कनेक्शन की समस्या आ सकती है.

आर्किटेक्चर के फ़ायदे

अपने ऐप्लिकेशन में अच्छा आर्किटेक्चर लागू करने से, प्रोजेक्ट और इंजीनियरिंग टीम को कई फ़ायदे मिलते हैं:

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

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

सैंपल

Google के इन सैंपल में, ऐप्लिकेशन के अच्छे आर्किटेक्चर के बारे में बताया गया है. इन दिशा-निर्देशों को असल ज़िंदगी में लागू करने के लिए, इन्हें देखें: