डेवलपर को अक्सर फ़ोल्ड किए जा सकने वाले डिवाइसों के लिए ऐप्लिकेशन बनाते समय, खास तरह की समस्याओं का सामना करना पड़ता है. खास तौर पर, Samsung Trifold या ओरिजनल Pixel Fold जैसे डिवाइसों के लिए. ये डिवाइस लैंडस्केप फ़ॉर्मैट में खुलते हैं (rotation_0 = landscape). डेवलपर की गलतियों में ये शामिल हैं:
- डिवाइस के ओरिएंटेशन के बारे में गलत अनुमान लगाना
- इस्तेमाल के ऐसे उदाहरण जिन पर ध्यान नहीं दिया गया
- कॉन्फ़िगरेशन में बदलाव होने पर, वैल्यू को फिर से कैलकुलेट या कैश न कर पाना
डिवाइस से जुड़ी खास समस्याओं में ये शामिल हैं:
- कवर और अंदरूनी डिसप्ले के बीच डिवाइस के नैचुरल ओरिएंटेशन में अंतर (rotation_0 = पोर्ट्रेट के आधार पर अनुमान लगाया गया है). इससे फ़ोल्ड और अनफ़ोल्ड करने के दौरान ऐप्लिकेशन काम नहीं करते
- अलग-अलग स्क्रीन डेंसिटी और डेंसिटी कॉन्फ़िगरेशन में बदलाव को गलत तरीके से हैंडल करना
- कैमरा सेंसर के नैचुरल ओरिएंटेशन पर निर्भर होने की वजह से, कैमरे की झलक देखने में समस्याएं आ रही हैं
फ़ोल्ड किए जा सकने वाले डिवाइसों पर लोगों को अच्छी क्वालिटी का अनुभव देने के लिए, इन ज़रूरी बातों पर ध्यान दें:
- ऐप्लिकेशन के ओरिएंटेशन का पता लगाने के लिए, डिवाइस के फ़िज़िकल ओरिएंटेशन के बजाय, ऐप्लिकेशन के इस्तेमाल की जा रही स्क्रीन के हिसाब से ओरिएंटेशन का पता लगाएं
- डिवाइस के ओरिएंटेशन और आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) को सही तरीके से मैनेज करने के लिए, कैमरे की झलक अपडेट करें. इससे, तिरछी झलक से बचा जा सकता है. साथ ही, स्ट्रेच या क्रॉप की गई इमेज को रोका जा सकता है
- डिवाइस को फ़ोल्ड या अनफ़ोल्ड करने के दौरान, ऐप्लिकेशन को चालू रखें. इसके लिए,
ViewModelया इसी तरह के अन्य तरीकों का इस्तेमाल करके, ऐप्लिकेशन की स्थिति को बनाए रखें. इसके अलावा, स्क्रीन डेंसिटी और स्क्रीन की दिशा में होने वाले बदलावों को मैन्युअल तरीके से मैनेज करें. इससे ऐप्लिकेशन को रीस्टार्ट करने या उसकी स्थिति को मिटाने से रोका जा सकता है - मोशन सेंसर का इस्तेमाल करने वाले ऐप्लिकेशन के लिए, कोऑर्डिनेट सिस्टम को स्क्रीन के मौजूदा ओरिएंटेशन के हिसाब से अडजस्ट करें. साथ ही, rotation_0 = पोर्ट्रेट के आधार पर अनुमान लगाने से बचें. इससे उपयोगकर्ता के इंटरैक्शन की सटीक जानकारी मिलती है
अडैप्टिव
अगर आपका ऐप्लिकेशन पहले से ही अडैप्टिव है और अडैप्टिव ऐप्लिकेशन की क्वालिटी के लिए दिशा-निर्देशों में बताए गए ऑप्टिमाइज़ेशन लेवल (टियर 2) के मुताबिक है, तो यह फ़ोल्ड किए जा सकने वाले डिवाइसों पर ठीक से काम करेगा. अगर ऐसा नहीं है, तो ट्राइफ़ोल्ड और लैंडस्केप फ़ोल्ड किए जा सकने वाले डिवाइसों की खास जानकारी की दोबारा जांच करने से पहले, Android के अडैप्टिव डेवलपमेंट से जुड़े इन बुनियादी सिद्धांतों को पढ़ें.
अडैप्टिव लेआउट
आपके यूज़र इंटरफ़ेस (यूआई) को न सिर्फ़ अलग-अलग स्क्रीन साइज़ के हिसाब से काम करना चाहिए, बल्कि आसपेक्ट रेशियो में रीयल-टाइम में होने वाले बदलावों के हिसाब से भी काम करना चाहिए. जैसे, फ़ोल्ड किए जा सकने वाले डिवाइस को खोलना और मल्टी-विंडो या डेस्कटॉप विंडो मोड में जाना. अनुकूलित लेआउट के बारे में जानकारी लेख में, इन कामों को करने के बारे में ज़्यादा जानकारी दी गई है:
- अडैप्टिव लेआउट डिज़ाइन और लागू करना
- विंडो के साइज़ के हिसाब से, अपने ऐप्लिकेशन के प्राइमरी नेविगेशन में बदलाव करना
- अपने ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) को अडैप्ट करने के लिए, विंडो साइज़ क्लास का इस्तेमाल करना
- Jetpack API का इस्तेमाल करके, लिस्ट‑डिटेल जैसे कैननिकल लेआउट को आसानी से लागू करें
विंडो के साइज़ की क्लास
फ़ोल्ड किए जा सकने वाले डिवाइसों में, लैंडस्केप मोड में फ़ोल्ड किए जा सकने वाले डिवाइस और ट्राइफ़ोल्ड डिवाइस शामिल हैं. ये डिवाइस, विंडो के साइज़ की क्लास को तुरंत कॉम्पैक्ट, मीडियम, और बड़ा कर सकते हैं. इन क्लास को समझने और लागू करने से, यह पक्का किया जा सकता है कि आपका ऐप्लिकेशन, डिवाइस की मौजूदा स्थिति के हिसाब से सही नेविगेशन कॉम्पोनेंट और कॉन्टेंट डेंसिटी दिखाए.
यहां दिए गए उदाहरण में, Material 3 अडैप्टिव लाइब्रेरी का इस्तेमाल किया गया है. इससे यह पता चलता है कि ऐप्लिकेशन के लिए कितना स्पेस उपलब्ध है. इसके लिए, सबसे पहले currentWindowAdaptiveInfoV2() फ़ंक्शन को शुरू किया जाता है. इसके बाद, विंडो साइज़ क्लास के लिए, उससे जुड़े लेआउट का इस्तेमाल किया जाता है:
val adaptiveInfo = currentWindowAdaptiveInfoV2()
val windowSizeClass = adaptiveInfo.windowSizeClass
when {
windowSizeClass.isWidthAtLeastBreakpoint(
WIDTH_DP_EXPANDED_LOWER_BOUND
) -> // Expanded
windowSizeClass.isWidthAtLeastBreakpoint(
WIDTH_DP_MEDIUM_LOWER_BOUND
) -> // Medium
else -> // Compact
}
ज़्यादा जानकारी के लिए, विंडो के साइज़ क्लास का इस्तेमाल करना लेख पढ़ें.
ऐप्लिकेशन की क्वालिटी को ज़रूरत के हिसाब से अडजस्ट करना
ऐडैप्टिव ऐप्लिकेशन की क्वालिटी से जुड़े दिशा-निर्देशों के टियर 2 (ऐडैप्टिव ऐप्लिकेशन ऑप्टिमाइज़ किया गया) या टियर 1 (ऐडैप्टिव ऐप्लिकेशन अलग-अलग डिवाइसों के हिसाब से बनाया गया) का पालन करने से, यह पक्का किया जा सकता है कि आपका ऐप्लिकेशन, तीन बार फ़ोल्ड होने वाले डिवाइसों, लैंडस्केप मोड में फ़ोल्ड होने वाले डिवाइसों, और बड़ी स्क्रीन वाले अन्य डिवाइसों पर लोगों को बेहतरीन अनुभव दे. इन दिशा-निर्देशों में, कई टियर लेवल पर ज़रूरी जांच शामिल हैं. इससे, अडैप्टिव विज्ञापन से लेकर अलग-अलग तरह के विज्ञापन दिखाए जा सकते हैं.
Android 16 और उसके बाद के वर्शन
Android 16 (एपीआई लेवल 36) और इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, सिस्टम उन डिसप्ले पर स्क्रीन की दिशा, साइज़ बदलने, और आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) से जुड़ी पाबंदियों को अनदेखा करता है जिनकी सबसे कम चौड़ाई >= 600dp है. ऐप्लिकेशन, पूरी डिसप्ले विंडो को भर देते हैं. भले ही, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) या उपयोगकर्ता की पसंदीदा ओरिएंटेशन (स्क्रीन की दिशा) कुछ भी हो. साथ ही, अब लेटरबॉक्सिंग कंपैटिबिलिटी मोड का इस्तेमाल नहीं किया जाता.
ध्यान देने वाली खास बातें
ट्राइफ़ोल्ड और लैंडस्केप फ़ोल्ड किए जा सकने वाले डिवाइसों में, हार्डवेयर से जुड़ी कुछ खास सुविधाएं होती हैं. इनके लिए, खास तौर पर सेंसर, कैमरे की झलक, और कॉन्फ़िगरेशन की निरंतरता (फ़ोल्ड करने, खोलने या साइज़ बदलने पर स्थिति बनाए रखना) से जुड़ी खास हैंडलिंग की ज़रूरत होती है.
कैमरे से मिल रही झलक
लैंडस्केप फ़ोल्ड किए जा सकने वाले डिवाइसों या आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) की कैलकुलेशन में, आम तौर पर यह समस्या आती है. जैसे, मल्टी-विंडो, डेस्कटॉप विंडोइंग या कनेक्ट किए गए डिसप्ले वाले डिवाइसों में, कैमरे की झलक स्ट्रेच की गई, साइडवे, काटी गई या घुमाई गई दिखती है.
अनुमान मेल नहीं खाते
यह समस्या अक्सर बड़ी स्क्रीन और फ़ोल्ड किए जा सकने वाले डिवाइसों पर होती है. ऐसा इसलिए होता है, क्योंकि ऐप्लिकेशन, कैमरा सुविधाओं (जैसे कि आसपेक्ट रेशियो और सेंसर ओरिएंटेशन) और डिवाइस की सुविधाओं (जैसे कि डिवाइस ओरिएंटेशन और नैचुरल ओरिएंटेशन) के बीच तय किए गए संबंध मान सकते हैं.
डिवाइस के नए साइज़, डाइमेंशन या कॉन्फ़िगरेशन से यह धारणा गलत साबित होती है. फ़ोल्ड किए जा सकने वाले डिवाइस में, डिवाइस को घुमाए बिना डिसप्ले का साइज़ और आसपेक्ट रेशियो बदला जा सकता है. उदाहरण के लिए, डिवाइस को खोलने पर आसपेक्ट रेशियो बदल जाता है. हालांकि, अगर उपयोगकर्ता डिवाइस को घुमाता नहीं है, तो उसका रोटेशन पहले जैसा ही रहता है. अगर कोई ऐप्लिकेशन यह मानता है कि आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात), डिवाइस के रोटेशन से जुड़ा है, तो वह कैमरे की झलक को गलत तरीके से रोटेट या स्केल कर सकता है. ऐसा तब भी हो सकता है, जब कोई ऐप्लिकेशन यह मान लेता है कि कैमरे के सेंसर का ओरिएंटेशन, पोर्ट्रेट डिवाइस के ओरिएंटेशन से मेल खाता है. हालांकि, लैंडस्केप फ़ोल्ड किए जा सकने वाले डिवाइसों के लिए यह हमेशा सही नहीं होता.
पहला तरीका: Jetpack CameraX (सबसे अच्छा)
सबसे आसान और भरोसेमंद तरीका, Jetpack CameraX लाइब्रेरी का इस्तेमाल करना है. इसके PreviewView यूज़र इंटरफ़ेस (यूआई) एलिमेंट को, झलक से जुड़ी सभी मुश्किलों को अपने-आप मैनेज करने के लिए डिज़ाइन किया गया है:
PreviewViewसेंसर के ओरिएंटेशन, डिवाइस के रोटेशन, और स्केलिंग के हिसाब से सही तरीके से अडजस्ट होता है.- यह कैमरे की इमेज के आसपेक्ट रेशियो को बनाए रखता है. आम तौर पर, यह इमेज को बीच में रखकर और काट-छांट करके (FILL_CENTER) ऐसा करता है.
- अगर ज़रूरत हो, तो झलक को लेटरबॉक्स करने के लिए, स्केल टाइप को
FIT_CENTERपर सेट किया जा सकता है.
ज़्यादा जानकारी के लिए, CameraX के दस्तावेज़ में झलक लागू करना लेख पढ़ें.
दूसरा समाधान: CameraViewfinder
अगर Camera2 के मौजूदा कोड बेस का इस्तेमाल किया जा रहा है, तो CameraViewfinder लाइब्रेरी (एपीआई लेवल 21 के साथ काम करती है) एक और आधुनिक समाधान है. यह TextureView या SurfaceView का इस्तेमाल करके, कैमरा फ़ीड को आसानी से दिखाता है. साथ ही, आपके लिए सभी ज़रूरी बदलाव (आस्पेक्ट रेशियो, स्केल, और रोटेशन) लागू करता है.
ज़्यादा जानकारी के लिए, पेश है कैमरा व्यूफ़ाइंडर ब्लॉग पोस्ट और कैमरा प्रीव्यू डेवलपर गाइड देखें.
तीसरा समाधान: Camera2 को मैन्युअल तरीके से लागू करना
अगर CameraX या CameraViewfinder का इस्तेमाल नहीं किया जा सकता, तो आपको स्क्रीन की दिशा और आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) की मैन्युअल तरीके से गणना करनी होगी. साथ ही, यह पक्का करना होगा कि कॉन्फ़िगरेशन में हर बदलाव के साथ गणनाएं अपडेट की गई हों:
CameraCharacteristicsसे कैमरे के सेंसर का ओरिएंटेशन (उदाहरण के लिए, 0, 90, 180, 270 डिग्री) पाएं.- डिवाइस के डिसप्ले के मौजूदा रोटेशन की जानकारी पाएं. उदाहरण के लिए, 0, 90, 180, 270 डिग्री.
- इन दो वैल्यू का इस्तेमाल करके, अपने
SurfaceViewयाTextureViewके लिए ज़रूरी बदलावों का पता लगाएं. - पक्का करें कि आपके आउटपुट
Surfaceका आसपेक्ट रेशियो, कैमरे की झलक के आसपेक्ट रेशियो से मेल खाता हो, ताकि इमेज में कोई गड़बड़ी न हो. - ऐसा हो सकता है कि कैमरा ऐप्लिकेशन, स्क्रीन के किसी हिस्से में चल रहा हो. यह मल्टी-विंडो या डेस्कटॉप विंडोविंग मोड में या कनेक्ट किए गए डिसप्ले पर चल रहा हो. इस वजह से, कैमरा व्यूफ़ाइंडर के डाइमेंशन तय करने के लिए स्क्रीन साइज़ का इस्तेमाल नहीं किया जाना चाहिए. इसके बजाय, विंडो मेट्रिक का इस्तेमाल करें.
ज़्यादा जानकारी के लिए, डेवलपर के लिए बनी कैमरे की झलक गाइड और अलग-अलग फ़ॉर्म फ़ैक्टर पर आपका Camera ऐप्लिकेशन वीडियो देखें.
चौथा समाधान: इंटेंट का इस्तेमाल करके, कैमरे से जुड़ी बुनियादी कार्रवाइयां करना
अगर आपको कैमरे की ज़्यादा सुविधाओं की ज़रूरत नहीं है, तो डिवाइस के डिफ़ॉल्ट कैमरा ऐप्लिकेशन का इस्तेमाल करके, फ़ोटो या वीडियो कैप्चर करने जैसे बुनियादी काम किए जा सकते हैं. आपको कैमरा लाइब्रेरी के साथ इंटिग्रेट करने की ज़रूरत नहीं है. इसके बजाय, इंटेंट का इस्तेमाल करें.
ज़्यादा जानकारी के लिए, कैमरा इंटेंट देखें.
कॉन्फ़िगरेशन और डेटा उपलब्ध कराते रहना
फ़ोल्ड किए जा सकने वाले डिवाइसों में यूज़र इंटरफ़ेस (यूआई) को बेहतर तरीके से इस्तेमाल किया जा सकता है. हालांकि, इनमें फ़ोल्ड नहीं किए जा सकने वाले डिवाइसों की तुलना में कॉन्फ़िगरेशन में ज़्यादा बदलाव किए जा सकते हैं. आपके ऐप्लिकेशन को कॉन्फ़िगरेशन में हुए इन बदलावों और उनके कॉम्बिनेशन को मैनेज करना होगा. जैसे, डिवाइस को घुमाना, फ़ोल्ड/अनफ़ोल्ड करना, और मल्टी-विंडो या डेस्कटॉप मोड में विंडो का साइज़ बदलना. साथ ही, ऐप्लिकेशन की स्थिति को बनाए रखना या उसे वापस लाना होगा. उदाहरण के लिए, ऐप्लिकेशन में ये चीज़ें लगातार उपलब्ध होनी चाहिए:
- ऐप्लिकेशन की स्थिति में बदलाव होने पर भी, ऐप्लिकेशन क्रैश नहीं होना चाहिए. साथ ही, लोगों के लिए रुकावट पैदा करने वाले बदलाव नहीं होने चाहिए. उदाहरण के लिए, स्क्रीन स्विच करते समय या ऐप्लिकेशन को बैकग्राउंड में भेजते समय
- स्क्रोल किए जा सकने वाले फ़ील्ड की स्क्रोल पोज़िशन
- टेक्स्ट फ़ील्ड में टाइप किया गया टेक्स्ट और कीबोर्ड की स्थिति
- मीडिया के चलने की स्थिति, ताकि कॉन्फ़िगरेशन में बदलाव होने पर, वीडियो वहीं से शुरू हो जहां उसे छोड़ा गया था
कॉन्फ़िगरेशन में होने वाले ऐसे बदलाव जिन्हें बार-बार ट्रिगर किया जाता है उनमें screenSize, smallestScreenSize, screenLayout, orientation, density, fontScale, touchscreen, और keyboard शामिल हैं.
android:configChanges और कॉन्फ़िगरेशन में हुए बदलावों को मैनेज करना लेख पढ़ें. ऐप्लिकेशन की स्थिति को मैनेज करने के बारे में ज़्यादा जानने के लिए, यूज़र इंटरफ़ेस (यूआई) की स्थितियां सेव करना लेख पढ़ें.
डेंसिटी के कॉन्फ़िगरेशन में बदलाव
ट्राइफ़ोल्ड और लैंडस्केप फ़ोल्ड किए जा सकने वाले डिवाइसों की आउटर और इनर स्क्रीन पर, पिक्सल डेंसिटी अलग-अलग हो सकती है. इसलिए, density के लिए कॉन्फ़िगरेशन में बदलाव करने पर ज़्यादा ध्यान देने की ज़रूरत होती है. डिसप्ले डेंसिटी (सघनता) बदलने पर, Android आम तौर पर गतिविधि को रीस्टार्ट कर देता है. इससे डेटा मिट सकता है. सिस्टम को गतिविधि फिर से शुरू करने से रोकने के लिए, मेनिफ़ेस्ट में डेंसिटी हैंडलिंग का एलान करें. साथ ही, अपने ऐप्लिकेशन में प्रोग्राम के हिसाब से कॉन्फ़िगरेशन में बदलाव मैनेज करें.
AndroidManifest.xml कॉन्फ़िगरेशन
density: इससे यह पता चलता है कि ऐप्लिकेशन, स्क्रीन की डेंसिटी में होने वाले बदलाव को मैनेज करेगा- कॉन्फ़िगरेशन में हुए अन्य बदलावों के बारे में जानकारी देना: कॉन्फ़िगरेशन में अक्सर होने वाले अन्य बदलावों के बारे में भी जानकारी देना अच्छा होता है. उदाहरण के लिए,
screenSize,orientation,keyboardHidden,fontScaleवगैरह
डेंसिटी (और कॉन्फ़िगरेशन में हुए अन्य बदलावों) के बारे में बताने से, सिस्टम को गतिविधि को फिर से शुरू करने से रोका जा सकता है. इसके बजाय, यह onConfigurationChanged() को कॉल करता है.
onConfigurationChanged() लागू करना
डेंसिटी में बदलाव होने पर, आपको अपने संसाधनों को अपडेट करना होगा. जैसे, बिटमैप को फिर से लोड करना या लेआउट के साइज़ का फिर से हिसाब लगाना. इसके लिए, आपको इस कॉलबैक का इस्तेमाल करना होगा:
- पुष्टि करें कि डीपीआई को
newConfig.densityDpiपर सेट किया गया है - कस्टम व्यू, कस्टम ड्रॉएबल वगैरह को नई डेंसिटी पर रीसेट करना
प्रोसेस किए जाने वाले संसाधन आइटम
- इमेज रिसॉर्स: बिटमैप और ड्रॉएबल को डेनसिटी के हिसाब से बनाए गए रिसॉर्स से बदलें या स्केल को सीधे तौर पर अडजस्ट करें
- लेआउट यूनिट (डीपी से पिक्सल में कन्वर्ज़न): व्यू के साइज़, मार्जिन, और पैडिंग की फिर से गिनती करें
- फ़ॉन्ट और टेक्स्ट का साइज़: एसपी यूनिट के टेक्स्ट साइज़ को फिर से लागू करें
- कस्टम
View/Canvasड्राइंग:Canvasको ड्रा करने के लिए इस्तेमाल की गई पिक्सल पर आधारित वैल्यू अपडेट करें
ऐप्लिकेशन का ओरिएंटेशन तय करना
अडैप्टिव लेआउट बनाते समय, डिवाइस के रोटेशन पर कभी भी भरोसा न करें. ऐसा इसलिए, क्योंकि बड़ी स्क्रीन वाले डिवाइसों पर इसे अनदेखा कर दिया जाएगा. साथ ही, मल्टी-विंडो मोड में मौजूद ऐप्लिकेशन का ओरिएंटेशन, डिवाइस के ओरिएंटेशन से अलग हो सकता है. इसके बजाय, Configuration.orientation या WindowMetrics का इस्तेमाल करके यह पता लगाएं कि विंडो के साइज़ के हिसाब से, आपका ऐप्लिकेशन फ़िलहाल लैंडस्केप या पोर्ट्रेट स्क्रीन की दिशा में है या नहीं.
पहला समाधान: Configuration.orientation का इस्तेमाल करें
इस प्रॉपर्टी से पता चलता है कि फ़िलहाल आपका ऐप्लिकेशन किस ओरिएंटेशन में दिख रहा है.
दूसरा समाधान: WindowMetrics#getBounds() का इस्तेमाल करें
ऐप्लिकेशन के मौजूदा डिसप्ले बाउंड्री की जानकारी पाई जा सकती है. साथ ही, स्क्रीन की दिशा तय करने के लिए, इसकी चौड़ाई और ऊंचाई देखी जा सकती है.
अगर आपको फ़ोन (या फ़ोल्ड किए जा सकने वाले डिवाइसों की बाहरी स्क्रीन) पर ऐप्लिकेशन के ओरिएंटेशन को सीमित करना है, लेकिन बड़ी स्क्रीन वाले डिवाइसों पर नहीं, तो फ़ोन पर ऐप्लिकेशन के ओरिएंटेशन को सीमित करना, लेकिन बड़ी स्क्रीन पर नहीं लेख पढ़ें.
पोस्चर और डिसप्ले मोड
फ़ोल्ड किए जा सकने वाले डिवाइसों को अलग-अलग तरह से इस्तेमाल किया जा सकता है. जैसे, टेबलटॉप और HALF_OPENED. ये दोनों ही, पोर्ट्रेट और लैंडस्केप मोड में फ़ोल्ड किए जा सकने वाले डिवाइसों के साथ काम करते हैं. हालांकि, ट्राइफ़ोल्ड को टेबलटॉप मोड में इस्तेमाल नहीं किया जा सकता. साथ ही, इन्हें HALF_OPENED के तौर पर इस्तेमाल नहीं किया जा सकता. ट्राइफ़ोल्ड डिवाइसों में, पूरी तरह से खोलने पर बड़ी स्क्रीन मिलती है. इससे लोगों को बेहतर अनुभव मिलता है.
फ़ोल्ड किए जा सकने वाले ऐसे डिवाइसों पर अपने ऐप्लिकेशन को अलग दिखाने के लिए जो HALF_OPENED के साथ काम करते हैं, Compose Material 3 के अडैप्टिव एपीआई का इस्तेमाल करें. जैसे, collectFoldingFeaturesAsState() और currentWindowAdaptiveInfoV2().
फ़ोल्ड किए जा सकने वाले डिवाइसों की अलग-अलग स्थितियों और कैमरा प्रीव्यू की सुविधा के बारे में ज़्यादा जानने के लिए, डेवलपर के लिए उपलब्ध ये गाइड पढ़ें:
- फ़ोल्ड किए जा सकने वाले डिवाइसों के बारे में जानकारी
- अपने ऐप्लिकेशन को फ़ोल्ड किए जा सकने वाले डिवाइसों के हिसाब से बनाना
फ़ोल्ड किए जा सकने वाले डिवाइसों पर, वीडियो देखने का खास अनुभव मिलता है. रियर डिसप्ले मोड और ड्यूअल‑स्क्रीन मोड की मदद से, फ़ोल्ड किए जा सकने वाले डिवाइसों के लिए डिसप्ले की खास सुविधाएं बनाई जा सकती हैं. जैसे, रियर‑कैमरा सेल्फ़ी की झलक देखना और इनर और आउटर स्क्रीन पर एक साथ अलग-अलग डिसप्ले दिखाना. ज़्यादा जानकारी के लिए, यह लेख पढ़ें:
सेंसर की नैचुरल ओरिएंटेशन के हिसाब से ओरिएंटेशन लॉक करना
इस्तेमाल के कुछ खास उदाहरणों के लिए, nosensor फ़्लैग का इस्तेमाल किया जा सकता है. खास तौर पर, उन ऐप्लिकेशन के लिए जो डिवाइस के मुड़े हुए मोड से जुड़ी नहीं हैं और पूरी स्क्रीन पर दिखती हैं. इस फ़्लैग की मदद से, ऐप्लिकेशन को डिवाइस के नैचुरल ओरिएंटेशन पर लॉक किया जा सकता है. उदाहरण के लिए, Pixel Fold के मुड़े होने पर डिवाइस का ओरिएंटेशन पोर्ट्रेट होता है, जबकि खुले होने पर डिवाइस का ओरिएंटेशन लैंडस्केप होता है. nosensor फ़्लैग जोड़ने से, आउटर डिसप्ले पर ऐप्लिकेशन को पोर्ट्रेट मोड में लॉक किया जा सकता है. साथ ही, इनर डिसप्ले पर ऐप्लिकेशन को लैंडस्केप मोड में लॉक किया जा सकता है.
<activity
android:name=".MainActivity"
android:screenOrientation="nosensor">
गेम और एक्सआर सेंसर रीमैपिंग
गेम और एक्सआर ऐप्लिकेशन के लिए, सेंसर का रॉ डेटा (जैसे, जाइरोस्कोप या एक्सलरोमीटर) डिवाइस के फ़िक्स्ड कोऑर्डिनेट सिस्टम में उपलब्ध कराया जाता है. अगर उपयोगकर्ता डिवाइस को घुमाकर लैंडस्केप मोड में गेम खेलता है, तो सेंसर ऐक्सिस स्क्रीन के साथ नहीं घूमते हैं. इस वजह से, गेम को कंट्रोल करने में समस्या आती है.
इस समस्या को ठीक करने के लिए, मौजूदा Display.getRotation() की जांच करें और उसके मुताबिक ऐक्सिस को फिर से मैप करें:
- रोटेशन 0: x=x, y=y
- 90 डिग्री घुमाना: x=-y, y=x
- 180 डिग्री का घुमाव: x=-x, y=-y
- 270 डिग्री का घुमाव: x=y, y=-x
कंपास या XR ऐप्लिकेशन में इस्तेमाल किए जाने वाले रोटेशन वेक्टर के लिए, SensorManager.remapCoordinateSystem() का इस्तेमाल करें. इससे, कैमरे के लेंस की दिशा या स्क्रीन के सबसे ऊपर वाले हिस्से को मौजूदा रोटेशन के आधार पर नए ऐक्सिस पर मैप किया जा सकता है.
ऐप्लिकेशन के साथ काम करने से जुड़ी समस्या
ऐप्लिकेशन को, ऐप्लिकेशन की क्वालिटी से जुड़े दिशा-निर्देशों का पालन करना होगा. इससे यह पक्का किया जा सकेगा कि ऐप्लिकेशन, सभी साइज़, डाइमेंशन या कॉन्फ़िगरेशन वाले डिवाइसों और कनेक्ट किए गए डिसप्ले के साथ काम करता हो. अगर कोई ऐप्लिकेशन दिशा-निर्देशों का पालन नहीं करता है, तो डिवाइस बनाने वाली कंपनियां, कंपैटिबिलिटी से जुड़ी सुविधाएं लागू कर सकती हैं. हालांकि, इससे उपयोगकर्ता का अनुभव खराब हो सकता है.
ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म में दी गई कंपैटिबिलिटी से जुड़ी समस्याओं को हल करने के तरीकों की पूरी सूची देखें. खास तौर पर, कैमरा प्रीव्यू, ओवरराइड, और Android 16 API में हुए बदलावों से जुड़े तरीके देखें. इनसे आपके ऐप्लिकेशन के काम करने के तरीके में बदलाव हो सकता है.
अडैप्टिव ऐप्लिकेशन बनाने के बारे में ज़्यादा जानने के लिए, अडैप्टिव ऐप्लिकेशन की क्वालिटी से जुड़े दिशा-निर्देश पढ़ें.