विंडो साइज़ क्लास, व्यूपोर्ट ब्रेकपॉइंट का एक सेट होता है. इससे आपको रिस्पॉन्सिव/अडैप्टिव लेआउट को डिज़ाइन, डेवलप, और टेस्ट करने में मदद मिलती है. ब्रेकपॉइंट, लेआउट को आसान बनाने के साथ-साथ, खास मामलों के लिए आपके ऐप्लिकेशन को ऑप्टिमाइज़ करने की सुविधा देते हैं.
विंडो साइज़ की क्लास, आपके ऐप्लिकेशन के लिए उपलब्ध डिसप्ले एरिया को कॉम्पैक्ट, मीडियम या बड़ा के तौर पर बांटती हैं. उपलब्ध चौड़ाई और ऊंचाई को अलग-अलग कैटगरी में रखा जाता है. इसलिए, किसी भी समय आपके ऐप्लिकेशन में विंडो के साइज़ की दो कैटगरी होती हैं—एक चौड़ाई के लिए, एक ऊंचाई के लिए. वर्टिकल स्क्रोलिंग की सुविधा हर जगह उपलब्ध होने की वजह से, आम तौर पर उपलब्ध चौड़ाई, उपलब्ध ऊंचाई से ज़्यादा अहम होती है. इसलिए, हो सकता है कि चौड़ाई वाली विंडो साइज़ क्लास, आपके ऐप्लिकेशन के यूज़र इंटरफ़ेस के लिए ज़्यादा काम की हो.
आंकड़ों में दिखाए गए तरीके से, ब्रेकपॉइंट की मदद से डिवाइसों और कॉन्फ़िगरेशन के हिसाब से, लेआउट के बारे में सोचा जा सकता है. साइज़ क्लास के हर ब्रेकपॉइंट से, डिवाइस के सामान्य मामलों के लिए ज़्यादातर मामलों का पता चलता है. ब्रेकपॉइंट पर आधारित लेआउट के डिज़ाइन के बारे में सोचते समय, यह एक मददगार फ़्रेम ऑफ़ रेफ़रंस हो सकता है.
| साइज़ क्लास | ब्रेकपॉइंट | डिवाइस की जानकारी |
|---|---|---|
| कॉम्पैक्ट चौड़ाई | width < 600dp | 99.96% फ़ोन पोर्ट्रेट मोड में |
| मीडियम चौड़ाई | 600dp ≤ चौड़ाई < 840dp | 93.73% टैबलेट पोर्ट्रेट मोड में,
पोर्ट्रेट मोड में, फ़ोल्ड किए गए सबसे बड़े इनर डिसप्ले |
| बढ़ाई गई चौड़ाई | चौड़ाई 840dp से ज़्यादा हो | 97.22% टैबलेट पर लैंडस्केप मोड में,
लैंडस्केप में, अनफ़ोल्ड किए गए सबसे बड़े इनर डिसप्ले |
| कॉम्पैक्ट ऊंचाई | height < 480dp | 99.78% फ़ोन लैंडस्केप में |
| मीडियम हाइट | 480dp ≤ height < 900dp | 96.56% टैबलेट लैंडस्केप मोड में,
97.59% फ़ोन पोर्ट्रेट मोड में |
| बढ़ाई गई ऊंचाई | ऊंचाई ≥ 900dp | 94.25% टैबलेट, पोर्ट्रेट मोड में |
साइज़ क्लास को फ़िज़िकल डिवाइसों के तौर पर विज़ुअलाइज़ करना फ़ायदेमंद हो सकता है. हालांकि, विंडो साइज़ के क्लास, डिवाइस की स्क्रीन के साइज़ से तय नहीं होते. विंडो साइज़ क्लास, isTablet टाइप के लॉजिक के लिए नहीं हैं. इसके बजाय, विंडो साइज़ की क्लास, आपके ऐप्लिकेशन के लिए उपलब्ध विंडो साइज़ से तय होती हैं. इससे कोई फ़र्क़ नहीं पड़ता कि ऐप्लिकेशन किस तरह के डिवाइस पर चल रहा है. इस बात के दो अहम असर होते हैं:
फ़िज़िकल डिवाइसों के लिए, यह गारंटी नहीं दी जा सकती कि वे किसी खास विंडो साइज़ क्लास के होंगे. कई वजहों से, आपके ऐप्लिकेशन के लिए उपलब्ध स्क्रीन स्पेस, डिवाइस के स्क्रीन साइज़ से अलग हो सकता है. मोबाइल डिवाइसों पर, स्प्लिट स्क्रीन मोड की मदद से स्क्रीन को दो ऐप्लिकेशन के बीच बांटा जा सकता है. ChromeOS पर, Android ऐप्लिकेशन को डेस्कटॉप जैसी विंडो में दिखाया जा सकता है. इन विंडो का साइज़ अपनी पसंद के मुताबिक बदला जा सकता है. फ़ोल्ड किए जा सकने वाले डिवाइसों में दो अलग-अलग साइज़ की स्क्रीन हो सकती हैं. इन स्क्रीन को डिवाइस को फ़ोल्ड या अनफ़ोल्ड करके अलग-अलग ऐक्सेस किया जा सकता है.
विंडो के साइज़ की कैटगरी, आपके ऐप्लिकेशन के पूरे लाइफ़टाइम में बदल सकती है. ऐप्लिकेशन के चलने के दौरान, डिवाइस के ओरिएंटेशन में बदलाव, मल्टीटास्किंग, और स्क्रीन को फ़ोल्ड करने/अनफ़ोल्ड करने से, स्क्रीन पर उपलब्ध जगह में बदलाव हो सकता है. इस वजह से, विंडो साइज़ क्लास डाइनैमिक होती है और आपके ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) को इसके हिसाब से बदलना चाहिए.
विंडो के साइज़ की क्लास, Material Design लेआउट के दिशा-निर्देशों में कॉम्पैक्ट, मीडियम, और बड़ा किए गए ब्रेकपॉइंट से मैप होती हैं. ऐप्लिकेशन के लेआउट के लिए हाई-लेवल के फ़ैसले लेने के लिए, विंडो साइज़ क्लास का इस्तेमाल करें. जैसे, स्क्रीन के अतिरिक्त स्पेस का फ़ायदा पाने के लिए, किसी खास कैननिकल लेआउट का इस्तेमाल करना है या नहीं.
हमारे पास आपके मौजूदा
WindowSizeClass
इसका इस्तेमाल करके
WindowSizeClass#compute()
Jetpack ने एक फ़ंक्शन दिया है
WindowManager लाइब्रेरी. यह उदाहरण
यह दिखाता है कि विंडो के साइज़ की क्लास का हिसाब कैसे लगाया जाता है और
विंडो के साइज़ की क्लास में हुए बदलाव:
class MainActivity : Activity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// ...
// Replace with a known container that you can safely add a
// view to where the view won't affect the layout and the view
// won't be replaced.
val container: ViewGroup = binding.container
// Add a utility view to the container to hook into
// View.onConfigurationChanged(). This is required for all
// activities, even those that don't handle configuration
// changes. You can't use Activity.onConfigurationChanged(),
// since there are situations where that won't be called when
// the configuration changes. View.onConfigurationChanged() is
// called in those scenarios.
container.addView(object : View(this) {
override fun onConfigurationChanged(newConfig: Configuration?) {
super.onConfigurationChanged(newConfig)
computeWindowSizeClasses()
}
})
computeWindowSizeClasses()
}
private fun computeWindowSizeClasses() {
val metrics = WindowMetricsCalculator.getOrCreate().computeCurrentWindowMetrics(this)
val width = metrics.bounds.width()
val height = metrics.bounds.height()
val density = resources.displayMetrics.density
val windowSizeClass = WindowSizeClass.compute(width/density, height/density)
// COMPACT, MEDIUM, or EXPANDED
val widthWindowSizeClass = windowSizeClass.windowWidthSizeClass
// COMPACT, MEDIUM, or EXPANDED
val heightWindowSizeClass = windowSizeClass.windowHeightSizeClass
// Use widthWindowSizeClass and heightWindowSizeClass.
}
}
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// ...
// Replace with a known container that you can safely add a
// view to where the view won't affect the layout and the view
// won't be replaced.
ViewGroup container = binding.container;
// Add a utility view to the container to hook into
// View.onConfigurationChanged(). This is required for all
// activities, even those that don't handle configuration
// changes. You can't use Activity.onConfigurationChanged(),
// since there are situations where that won't be called when
// the configuration changes. View.onConfigurationChanged() is
// called in those scenarios.
container.addView(new View(this) {
@Override
protected void onConfigurationChanged(Configuration newConfig) {
super.onConfigurationChanged(newConfig);
computeWindowSizeClasses();
}
});
computeWindowSizeClasses();
}
private void computeWindowSizeClasses() {
WindowMetrics metrics = WindowMetricsCalculator.getOrCreate()
.computeCurrentWindowMetrics(this);
int width = metrics.getBounds().width
int height = metrics.getBounds().height()
float density = getResources().getDisplayMetrics().density;
WindowSizeClass windowSizeClass = WindowSizeClass.compute(width/density, height/density)
// COMPACT, MEDIUM, or EXPANDED
WindowWidthSizeClass widthWindowSizeClass = windowSizeClass.getWindowWidthSizeClass()
// COMPACT, MEDIUM, or EXPANDED
WindowHeightSizeClass heightWindowSizeClass = windowSizeClass.getWindowHeightSizeClass()
// Use widthWindowSizeClass and heightWindowSizeClass.
}
}
विंडो के साइज़ की जांच करने वाली क्लास
लेआउट में बदलाव करते समय, सभी विंडो साइज़ पर लेआउट के व्यवहार की जांच करें. खास तौर पर, कॉम्पैक्ट, मीडियम, और बड़ा किए गए ब्रेकपॉइंट की चौड़ाई पर.
अगर आपके पास कॉम्पैक्ट स्क्रीन के लिए कोई मौजूदा लेआउट है, तो सबसे पहले अपने लेआउट को बड़े किए गए चौड़ाई साइज़ क्लास के लिए ऑप्टिमाइज़ करें. इसकी वजह यह है कि इस साइज़ क्लास में, ज़्यादा कॉन्टेंट और यूज़र इंटरफ़ेस (यूआई) में बदलाव करने के लिए ज़्यादा जगह मिलती है. इसके बाद, तय करें कि मीडियम चौड़ाई वाले साइज़ क्लास के लिए कौनसा लेआउट सही रहेगा. इसके लिए, कोई खास लेआउट जोड़ें.
अगले चरण
रिस्पॉन्सिव/अडैप्टिव लेआउट बनाने के लिए, विंडो साइज़ क्लास का इस्तेमाल करने के तरीके के बारे में ज़्यादा जानने के लिए, यहां दी गई जानकारी देखें:
Compose पर आधारित लेआउट के लिए: अलग-अलग डिसप्ले साइज़ के साथ काम करना
व्यू पर आधारित लेआउट के लिए: व्यू के साथ रिस्पॉन्सिव/अडैप्टिव डिज़ाइन
सभी डिवाइसों और स्क्रीन साइज़ पर ऐप्लिकेशन को बेहतर बनाने के बारे में ज़्यादा जानने के लिए, ये देखें:
- अपने यूज़र इंटरफ़ेस (यूआई) को रिस्पॉन्सिव लेआउट पर माइग्रेट करना
- बड़ी स्क्रीन पर ऐप्लिकेशन की क्वालिटी