अलग-अलग स्क्रीन साइज़ के साथ काम करें

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

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

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

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

स्क्रीन-लेवल पर कंपोज़ेबल के लिए बड़े लेआउट में बदलाव करें

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

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

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

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

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

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

@OptIn(ExperimentalMaterial3AdaptiveApi::class)
@Composable
fun MyApp(
    windowSizeClass: WindowSizeClass = currentWindowAdaptiveInfo().windowSizeClass
) {
    // Perform logic on the size class to decide whether to show the top app bar.
    val showTopAppBar = windowSizeClass.windowHeightSizeClass != WindowHeightSizeClass.COMPACT

    // MyScreen knows nothing about window sizes, and performs logic based on a Boolean flag.
    MyScreen(
        showTopAppBar = showTopAppBar,
        /* ... */
    )
}
AdaptiveLayoutSnippets.kt

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

फ़्लेक्सिबल नेस्ट किए गए कंपोज़ेबल का फिर से इस्तेमाल किया जा सकता है

कंपोज़ेबल को फिर से इस्तेमाल किया जा सकता है, जब उन्हें कई तरह के जगहें. अगर कोई कंपोज़ेबल मान लेता है कि उसे हमेशा रहे हैं, तो इसे किसी अन्य स्थान में उसका पुनः उपयोग करना कठिन होगा या आपके पास कोई और जगह हो. यह भी इसका मतलब है कि अलग-अलग, फिर से इस्तेमाल किए जा सकने वाले कंपोज़ेबल को "global" पर साइज़ की जानकारी.

नीचे दिए गए उदाहरण पर विचार करें: एक नेस्ट किए गए कंपोज़ेबल की कल्पना करें, जो सूची की जानकारी लेआउट, जो एक पैनल या दो पैनल साथ-साथ दिखा सकते हैं.

हम चाहते हैं कि यह फ़ैसला ऐप्लिकेशन के लेआउट में शामिल हो, इसलिए हम हमने इस फ़ैसले को स्क्रीन-लेवल कंपोज़ेबल में देखा था, जैसा कि हमने ऊपर देखा:

@Composable
fun AdaptivePane(
    showOnePane: Boolean,
    /* ... */
) {
    if (showOnePane) {
        OnePane(/* ... */)
    } else {
        TwoPane(/* ... */)
    }
}
AdaptiveLayoutSnippets.kt

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

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

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

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

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

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

@Composable
fun Card(/* ... */) {
    BoxWithConstraints {
        if (maxWidth < 400.dp) {
            Column {
                Image(/* ... */)
                Title(/* ... */)
            }
        } else {
            Row {
                Column {
                    Title(/* ... */)
                    Description(/* ... */)
                }
                Image(/* ... */)
            }
        }
    }
}
AdaptiveLayoutSnippets.kt

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

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

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

@Composable
fun Card(
    imageUrl: String,
    title: String,
    description: String
) {
    BoxWithConstraints {
        if (maxWidth < 400.dp) {
            Column {
                Image(imageUrl)
                Title(title)
            }
        } else {
            Row {
                Column {
                    Title(title)
                    Description(description)
                }
                Image(imageUrl)
            }
        }
    }
}
AdaptiveLayoutSnippets.kt

Card उदाहरण के आधार पर, ध्यान दें कि हम description हमेशा Card. हालांकि, description का इस्तेमाल सिर्फ़ तब किया जाता है, जब चौड़ाई की अनुमति होती है इसे दिखाने के लिए, Card को हमेशा इसकी ज़रूरत होती है. भले ही, इसकी चौड़ाई उपलब्ध हो.

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

इस सिद्धांत से, लेआउट में होने वाले बदलावों में भी स्थिति को बरकरार रखा जा सकता है. उछालकर हो सकता है कि इस जानकारी का इस्तेमाल किसी भी साइज़ में न किया जा सके. साथ ही, हम उपयोगकर्ता की स्थिति को सुरक्षित रख सकते हैं लेआउट का साइज़ बदलता है. उदाहरण के लिए, हम showMore बूलियन फ़्लैग उठा सकते हैं ताकि साइज़ बदलने पर उपयोगकर्ता की स्थिति सुरक्षित रहे, ताकि लेआउट स्विच हो सके ब्यौरे को छिपाने और दिखाने के बीच:

@Composable
fun Card(
    imageUrl: String,
    title: String,
    description: String
) {
    var showMore by remember { mutableStateOf(false) }

    BoxWithConstraints {
        if (maxWidth < 400.dp) {
            Column {
                Image(imageUrl)
                Title(title)
            }
        } else {
            Row {
                Column {
                    Title(title)
                    Description(
                        description = description,
                        showMore = showMore,
                        onShowMoreToggled = { newValue ->
                            showMore = newValue
                        }
                    )
                }
                Image(imageUrl)
            }
        }
    }
}
AdaptiveLayoutSnippets.kt

ज़्यादा जानें

Compose में कस्टम लेआउट के बारे में ज़्यादा जानने के लिए, यहां दी गई अतिरिक्त जानकारी देखें संसाधन.

सैंपल ऐप्लिकेशन

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

वीडियो

• किसी भी स्क्रीन साइज़ के लिए Android के यूज़र इंटरफ़ेस (यूआई) बनाना
• डिवाइस का नाप या आकार | Android डेवलपर समिट '22

{% endverba नया %}

आपके लिए सुझाव

• ध्यान दें: JavaScript बंद होने पर लिंक टेक्स्ट दिखता है
• मौजूदा कोड में कॉम्पोनेंट मैप करना
• लेआउट की बुनियादी बातें लिखना
• Jetpack Compose के चरण

{% शब्दों का हूबहू %}