अपने यूज़र इंटरफ़ेस (यूआई) को रिस्पॉन्सिव लेआउट पर माइग्रेट करना

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

रिस्पॉन्सिव यूज़र इंटरफ़ेस (यूआई), सुविधाओं में बदलाव करने और उन्हें लगातार उपलब्ध कराने के सिद्धांतों पर आधारित होता है.

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

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

ऐसा करने से बचें

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

मल्टी-विंडो मोड, 'पिक्चर में पिक्चर' या ChromeOS जैसी फ़्रीफ़ॉर्म विंडो में काम करते समय, ऐप्लिकेशन की विंडो का साइज़ बदल सकता है. इसमें एक से ज़्यादा फ़िज़िकल स्क्रीन भी हो सकती हैं. जैसे, फ़ोल्ड किए जा सकने वाले डिवाइस या ऐसे डिवाइस जिसमें एक से ज़्यादा डिसप्ले हों. इन सभी मामलों में, कॉन्टेंट दिखाने के तरीके का फ़ैसला लेने के लिए, स्क्रीन का साइज़ मायने नहीं रखता.

अलग-अलग साइज़ की ऐप्लिकेशन विंडो दिखाने वाले कई डिवाइस.
पहला डायग्राम. विंडो के साइज़, डिवाइस या डिसप्ले के साइज़ से अलग हो सकते हैं.

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

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

ऊपर बताई गई किसी भी रणनीति को आज़माने के बजाय, ब्रेकपॉइंट और विंडो साइज़ क्लास का इस्तेमाल करें.

ब्रेकपॉइंट और विंडो साइज़ क्लास

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

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

हमेशा दिखने वाले यूज़र इंटरफ़ेस (यूआई) एलिमेंट

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

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

<!-- res/layout/main_activity.xml -->

<androidx.constraintlayout.widget.ConstraintLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <!-- content view(s) -->

    <com.google.android.material.bottomappbar.BottomAppBar
        android:layout_width="wrap_content"
        android:layout_height="0dp"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        ... />
</androidx.constraintlayout.widget.ConstraintLayout>


<!-- res/layout-w600dp/main_activity.xml -->
<androidx.constraintlayout.widget.ConstraintLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <com.google.android.material.appbar.AppBarLayout
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        ... />

    <!-- content view(s) -->
</androidx.constraintlayout.widget.ConstraintLayout>

कॉन्टेंट

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

पक्का करें कि अलग-अलग साइज़ के लिए सारा डेटा उपलब्ध हो

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

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

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

कॉन्टेंट को बड़ा करना

कैननिकल लेआउट: फ़ीड

ज़्यादा जगह मिलने पर, कॉन्टेंट को बड़ा किया जा सकता है और उसे फिर से फ़ॉर्मैट किया जा सकता है, ताकि उसे पढ़ना और समझना आसान हो.

कलेक्शन को बड़ा करना. कई ऐप्लिकेशन, आइटम का कलेक्शन, स्क्रोल किए जा सकने वाले कंटेनर में दिखाते हैं. जैसे, RecyclerView या ScrollView. कंटेनर को अपने-आप बड़ा होने की सुविधा चालू करने का मतलब है कि ज़्यादा कॉन्टेंट दिखाया जा सकता है. हालांकि, ध्यान रखें कि कंटेनर में मौजूद कॉन्टेंट, ज़्यादा स्ट्रेच या खराब न हो जाए. उदाहरण के लिए, RecyclerView के साथ, GridLayoutManager, StaggeredGridLayoutManager या FlexboxLayout जैसे किसी दूसरे लेआउट मैनेजर का इस्तेमाल करें. ऐसा तब करें, जब चौड़ाई कॉम्पैक्ट न हो.

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

अलग-अलग आइटम के लिए, अलग-अलग साइज़ या आकार का इस्तेमाल किया जा सकता है, ताकि ज़्यादा कॉन्टेंट दिखाया जा सके और आइटम की सीमाओं को आसानी से पहचाना जा सके.

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

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

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

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

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

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

कॉन्टेंट जोड़ें

कैननिकल लेआउट: सहायक पैनल, सूची की ज़्यादा जानकारी वाला व्यू

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

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

  • DrawerLayout का इस्तेमाल करके, ट्रेलिंग एज पर साइड ड्रॉर
  • BottomSheetBehavior का इस्तेमाल करके, सबसे नीचे मौजूद ड्रॉर
  • मेन्यू आइकॉन पर टैप करके ऐक्सेस किया जा सकने वाला मेन्यू या पॉप-अप विंडो
चौथी इमेज. सहायक पैनल में ज़्यादा कॉन्टेंट दिखाने के अन्य तरीके.

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

सूची की ज़्यादा जानकारी वाले व्यू को लागू करने के लिए, SlidingPaneLayout के लिए बने विजेट का इस्तेमाल करें. यह विजेट, दोनों पैनल के लिए तय की गई layout_width वैल्यू के आधार पर, यह अपने-आप कैलकुलेट करता है कि दोनों पैनल को एक साथ दिखाने के लिए ज़रूरत के मुताबिक जगह है या नहीं. साथ ही, बचे हुए स्पेस को layout_weight का इस्तेमाल करके बांटा जा सकता है. जब स्क्रीन पर जगह कम होती है, तो हर पैनल लेआउट की पूरी चौड़ाई का इस्तेमाल करता है. साथ ही, ज़्यादा जानकारी वाला पैनल, स्क्रीन से बाहर या सूची वाले पैनल के ऊपर स्लाइड हो जाता है.

SlidingPaneLayout, जो वाइड डिसप्ले वाले डिवाइस पर, सूची-ज़्यादा जानकारी वाले लेआउट के दोनों पैनल दिखा रहा है.
पांचवीं इमेज. SlidingPaneLayout, जिसमें दो पैनल बड़ी चौड़ाई में और एक पैनल छोटी चौड़ाई में दिख रहा है.

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

अन्य संसाधन