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

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

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

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

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

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

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

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

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

लॉन्च करने की अलग-अलग शर्तें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अपने ऐप्लिकेशन को भरोसेमंद और टेस्ट करने लायक बनाने के लिए, ऐप्लिकेशन के आर्किटेक्चर को डेटा मॉडल क्लास पर आधारित करें.

एकमात्र भरोसेमंद सोर्स

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

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

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

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

एक ही दिशा में डेटा फ़्लो

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डेटा लेयर

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

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

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

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

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

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

डोमेन लेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

Android क्लास पर डिपेंडेंसी कम करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सैंपल

यहां दिए गए सैंपल, बेहतर ऐप्लिकेशन आर्किटेक्चर दिखाते हैं: