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

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

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

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

अलग-अलग नाप या आकार वाले डिवाइस

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

संसाधनों की कमी

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

वैरिएबल लॉन्च करने की शर्तें

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

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

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

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

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

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

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

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

अडैप्टिव लेआउट

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

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

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

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

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

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

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

सिंगल सोर्स ऑफ़ ट्रुथ

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

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

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

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

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

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

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

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

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

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

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

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

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

मॉडर्न ऐप्लिकेशन आर्किटेक्चर

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

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

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

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

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

यूज़र इंटरफ़ेस (यूआई) लेयर में दो चीज़ें होती हैं:

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

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

डेटा लेयर

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

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

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

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

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

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

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

डोमेन लेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अपने ऐप्लिकेशन की खास सुविधाओं पर ध्यान दें, ताकि यह अन्य ऐप्लिकेशन से अलग दिखे.

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

कैननिकल लेआउट और ऐप्लिकेशन डिज़ाइन पैटर्न का इस्तेमाल करें.

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

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

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

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

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

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

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

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

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

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

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

सैंपल

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