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

ऐप्लिकेशन का आर्किटेक्चर, अच्छी क्वालिटी वाले Android ऐप्लिकेशन का आधार होता है. अच्छी तरह से डिज़ाइन किए गए आर्किटेक्चर की मदद से, ऐसा ऐप्लिकेशन बनाया जा सकता है जिसे आसानी से बढ़ाया जा सकता है और जिसका रखरखाव किया जा सकता है. यह ऐप्लिकेशन, Android डिवाइसों के लगातार बढ़ते ईकोसिस्टम के हिसाब से काम कर सकता है. जैसे, फ़ोन, टैबलेट, फ़ोल्ड किए जा सकने वाले डिवाइस, ChromeOS डिवाइस, कार डिस्प्ले, और XR.

ऐप्लिकेशन कंपोज़िशन

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

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

अलग-अलग साइज़, डाइमेंशन या कॉन्फ़िगरेशन वाले डिवाइसों के हिसाब से ऐप्लिकेशन डिज़ाइन करना

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

संसाधन से जुड़ी पाबंदियां

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

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

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

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

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

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

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

अपने ऐप्लिकेशन के आर्किटेक्चर को इस तरह से डिज़ाइन करें कि वह कुछ खास सिद्धांतों का पालन करे.

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

अपने पूरे कोड को Activity में लिखना एक आम गलती है.

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

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

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

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

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

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

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

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

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

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

भरोसेमंद सोर्स

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

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

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

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

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

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

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

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

यूडीएफ़ के बारे में ज़्यादा जानने के लिए, Jetpack Compose में यूनिडायरेक्शनल डेटा फ़्लो लेख पढ़ें.

सुझाए गए ऐप्लिकेशन आर्किटेक्चर

आर्किटेक्चर के सामान्य सिद्धांतों को ध्यान में रखते हुए, हर ऐप्लिकेशन को कम से कम दो लेयर के साथ डिज़ाइन करें:

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

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

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

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

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

ज़्यादा जानकारी के लिए, Android के आर्किटेक्चर के लिए सुझाव देखें.

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

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

यूज़र इंटरफ़ेस लेयर में दो तरह के कंस्ट्रक्ट होते हैं:

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

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

ज़्यादा जानने के लिए, यूज़र इंटरफ़ेस (यूआई) लेयर और Compose UI आर्किटेक्चर देखें.

अडैप्टिव ऐप्लिकेशन और नेविगेशन के बारे में ज़्यादा जानने के लिए, अडैप्टिव ऐप्लिकेशन बनाना और अडैप्टिव नेविगेशन बनाना लेख पढ़ें.

डेटा लेयर

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

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

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

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

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

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

डोमेन लेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सैंपल

यहां ऐप्लिकेशन के अच्छे आर्किटेक्चर के उदाहरण दिए गए हैं: