फ़ोल्ड किए जा सकने वाले डिवाइसों के लिए ऐप्लिकेशन बनाते समय, डेवलपर को अक्सर अलग-अलग तरह की समस्याएं आती हैं. खास तौर पर, Samsung Trifold या ओरिजनल Pixel Fold जैसे डिवाइसों के लिए. ये डिवाइस लैंडस्केप फ़ॉर्मैट में खुलते हैं (rotation_0 = landscape). डेवलपर से होने वाली गलतियों में ये शामिल हैं:
- डिवाइस के ओरिएंटेशन के बारे में गलत अनुमान लगाना
- इस्तेमाल के उदाहरणों को नज़रअंदाज़ करना
- कॉन्फ़िगरेशन में बदलाव होने पर, वैल्यू को फिर से कैलकुलेट या कैश न करना
डिवाइस से जुड़ी खास समस्याओं में ये शामिल हैं:
- कवर और इनर डिसप्ले के बीच, डिवाइस के नैचुरल ओरिएंटेशन में अंतर होना. ऐसा rotation_0 = पोर्ट्रेट के आधार पर अनुमान लगाने की वजह से होता है. इससे, फ़ोल्ड और अनफ़ोल्ड करने पर ऐप्लिकेशन काम नहीं करते
- स्क्रीन की डेंसिटी अलग-अलग होना और डेंसिटी कॉन्फ़िगरेशन में बदलाव को गलत तरीके से हैंडल करना
- कैमरे के सेंसर के नैचुरल ओरिएंटेशन पर निर्भर होने की वजह से, कैमरे की झलक से जुड़ी समस्याएं होना
फ़ोल्ड किए जा सकने वाले डिवाइसों पर, लोगों को अच्छी क्वालिटी का अनुभव देने के लिए, इन अहम पहलुओं पर फ़ोकस करें:
- ऐप्लिकेशन के ओरिएंटेशन का पता लगाने के लिए, डिवाइस के फ़िज़िकल ओरिएंटेशन के बजाय, स्क्रीन के उस असल हिस्से को देखें जिस पर ऐप्लिकेशन दिखता है
- डिवाइस के ओरिएंटेशन और आसपेक्ट रेशियो को सही तरीके से मैनेज करने के लिए, कैमरे की झलक को अपडेट करें. साथ ही, साइड में दिखने वाली झलक से बचें और यह पक्का करें कि इमेज स्ट्रेच या क्रॉप न हों
- डिवाइस को फ़ोल्ड या अनफ़ोल्ड करने के दौरान, ऐप्लिकेशन की स्थिति बनाए रखें. इसके लिए, या तो
स्थिति को
ViewModelया इसी तरह के तरीकों से बनाए रखें या स्क्रीन की डेंसिटी और ओरिएंटेशन में होने वाले बदलावों को मैन्युअल तरीके से हैंडल करें. इससे, ऐप्लिकेशन रीस्टार्ट नहीं होते या उनकी स्थिति नहीं बदलती - मोशन सेंसर का इस्तेमाल करने वाले ऐप्लिकेशन के लिए, कोऑर्डिनेट सिस्टम को स्क्रीन के मौजूदा ओरिएंटेशन के हिसाब से अडजस्ट करें. साथ ही, rotation_0 = पोर्ट्रेट के आधार पर अनुमान न लगाएं. इससे, लोगों को सटीक इंटरैक्शन की गारंटी मिलती है
ज़रूरत के हिसाब से काम करने वाले ऐप्लिकेशन बनाना
अगर आपका ऐप्लिकेशन पहले से ही ज़रूरत के हिसाब से काम करता है और ऐप्लिकेशन की क्वालिटी से जुड़े दिशा-निर्देशों में बताए गए ऑप्टिमाइज़ किए गए लेवल (टियर 2) के मुताबिक है, तो यह फ़ोल्ड किए जा सकने वाले डिवाइसों पर अच्छी तरह काम करेगा. अगर ऐसा नहीं है, तो ट्राइफ़ोल्ड और लैंडस्केप फ़ोल्ड किए जा सकने वाले डिवाइसों की खास जानकारी की दोबारा जांच करने से पहले, Android के ज़रूरत के हिसाब से काम करने वाले ऐप्लिकेशन डेवलपमेंट से जुड़े इन बुनियादी कॉन्सेप्ट की समीक्षा करें.
अडैप्टिव लेआउट
आपके यूज़र इंटरफ़ेस (यूआई) को न सिर्फ़ अलग-अलग स्क्रीन साइज़, बल्कि आसपेक्ट रेशियो में रीयल-टाइम में होने वाले बदलावों को भी हैंडल करना होगा. जैसे, अनफ़ोल्ड करना और मल्टी-विंडो या डेस्कटॉप विंडोविंग मोड में जाना. इनके बारे में ज़्यादा जानने के लिए, अडैप्टिव लेआउट के बारे में जानकारी देखें:
- अडैप्टिव लेआउट डिज़ाइन और लागू करना
- विंडो के साइज़ के हिसाब से, अपने ऐप्लिकेशन के प्राइमरी नेविगेशन को अडजस्ट करना
- अपने ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) को अडैप्ट करने के लिए, विंडो साइज़ क्लास का इस्तेमाल करना
- Jetpack API का इस्तेमाल करके, लिस्ट‑डिटेल जैसे कैननिकल लेआउट को लागू करने की प्रोसेस को आसान बनाना
विंडो साइज़ क्लास
लैंडस्केप फ़ोल्ड किए जा सकने वाले डिवाइसों और ट्राइफ़ोल्ड सहित, फ़ोल्ड किए जा सकने वाले डिवाइस, कॉम्पैक्ट, मीडियम, और एक्सपैंडेड विंडो साइज़ क्लास के बीच तुरंत स्विच कर सकते हैं. इन क्लास को समझने और लागू करने से, यह पक्का होता है कि आपका ऐप्लिकेशन, डिवाइस की मौजूदा स्थिति के हिसाब से सही नेविगेशन कॉम्पोनेंट और कॉन्टेंट डेंसिटी दिखाए.
यहां दिए गए उदाहरण में, Material 3 अडैप्टिव लाइब्रेरी का इस्तेमाल करके यह पता लगाया गया है कि ऐप्लिकेशन के लिए कितनी जगह उपलब्ध है.
इसके लिए, सबसे पहले
currentWindowAdaptiveInfo() फ़ंक्शन को कॉल किया गया है.
इसके बाद, तीनों विंडो साइज़ क्लास के लिए, उनसे जुड़े लेआउट का इस्तेमाल किया गया है:
val adaptiveInfo = currentWindowAdaptiveInfo()
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 का इस्तेमाल करके, कैमरे के फ़ीड को दिखाने की प्रोसेस को आसान बनाता है. साथ ही, आपके लिए सभी ज़रूरी ट्रांसफ़ॉर्मेशन (आसपेक्ट रेशियो, स्केल, और रोटेशन) लागू करता है.
ज़्यादा जानकारी के लिए, Camera Viewfinder लॉन्च करने के बारे में जानकारी देने वाला ब्लॉग पोस्ट और कैमरे की झलक के लिए डेवलपर गाइड देखें.
तीसरा तरीका: Camera2 को मैन्युअल तरीके से लागू करना
अगर CameraX या CameraViewfinder का इस्तेमाल नहीं किया जा सकता, तो आपको ओरिएंटेशन और आसपेक्ट रेशियो को मैन्युअल तरीके से कैलकुलेट करना होगा. साथ ही, यह पक्का करना होगा कि कॉन्फ़िगरेशन में हर बदलाव के साथ, कैलकुलेशन अपडेट की जाएं:
CameraCharacteristicsसे, कैमरे के सेंसर का ओरिएंटेशन (उदाहरण के लिए, 0, 90, 180, 270 डिग्री) पाएं.- डिवाइस का मौजूदा डिसप्ले रोटेशन (उदाहरण के लिए, 0, 90, 180, 270 डिग्री) पाएं.
SurfaceViewयाTextureViewके लिए ज़रूरी ट्रांसफ़ॉर्मेशन तय करने के लिए, इन दोनों वैल्यू का इस्तेमाल करें.- यह पक्का करें कि आपके आउटपुट
Surfaceका आसपेक्ट रेशियो, कैमरे की झलक के आसपेक्ट रेशियो से मेल खाता हो, ताकि इमेज में कोई गड़बड़ी न हो. - कैमरा ऐप्लिकेशन, स्क्रीन के किसी हिस्से में चल रहा हो सकता है. जैसे, मल्टी-विंडो या डेस्कटॉप विंडोविंग मोड में या कनेक्टेड डिसप्ले पर. इसलिए, कैमरे के व्यूफ़ाइंडर के डाइमेंशन तय करने के लिए, स्क्रीन साइज़ का इस्तेमाल नहीं किया जाना चाहिए. इसके बजाय, विंडो मेट्रिक का इस्तेमाल करें.
ज़्यादा जानकारी के लिए, कैमरे की झलक के लिए डेवलपर गाइड और अलग-अलग फ़ॉर्म फ़ैक्टर पर आपका कैमरा ऐप्लिकेशन वीडियो देखें.
चौथा तरीका: इंटेंट का इस्तेमाल करके, कैमरे की बुनियादी कार्रवाइयां करना
अगर आपको कैमरे की ज़्यादा सुविधाओं की ज़रूरत नहीं है, तो एक आसान तरीका यह है कि डिवाइस के डिफ़ॉल्ट कैमरा ऐप्लिकेशन का इस्तेमाल करके, कैमरे की बुनियादी कार्रवाइयां की जाएं. जैसे, फ़ोटो या वीडियो कैप्चर करना. आपको कैमरा लाइब्रेरी के साथ इंटिग्रेट करने की ज़रूरत नहीं है. इसके बजाय, इंटेंट का इस्तेमाल करें.
ज़्यादा जानकारी के लिए, कैमरे के इंटेंट लेख पढ़ें.
कॉन्फ़िगरेशन और स्थिति बनाए रखना
फ़ोल्ड किए जा सकने वाले डिवाइसों से, यूज़र इंटरफ़ेस (यूआई) की वर्सटैलिटी बढ़ती है. हालांकि, इनमें, फ़ोल्ड न किए जा सकने वाले डिवाइसों के मुकाबले, कॉन्फ़िगरेशन में ज़्यादा बदलाव हो सकते हैं. आपके ऐप्लिकेशन को, कॉन्फ़िगरेशन में होने वाले इन बदलावों और उनके कॉम्बिनेशन को मैनेज करना होगा. जैसे, डिवाइस रोटेशन, फ़ोल्ड/अनफ़ोल्ड करना, और मल्टी-विंडो या डेस्कटॉप मोड में विंडो का साइज़ बदलना. साथ ही, ऐप्लिकेशन की स्थिति को बनाए रखना या उसे वापस लाना होगा. उदाहरण के लिए, ऐप्लिकेशन को स्थिति बनाए रखने के लिए, इन बातों का ध्यान रखना होगा:
- ऐप्लिकेशन की स्थिति बनाए रखना. ऐसा करने से, ऐप्लिकेशन क्रैश नहीं होगा या लोगों के लिए कोई समस्या नहीं होगी. उदाहरण के लिए, स्क्रीन स्विच करते समय या ऐप्लिकेशन को बैकग्राउंड में भेजते समय
- स्क्रोल किए जा सकने वाले फ़ील्ड की स्क्रोल पोज़िशन
- टेक्स्ट फ़ील्ड में टाइप किया गया टेक्स्ट और कीबोर्ड की स्थिति
- मीडिया प्लेबैक की पोज़िशन, ताकि कॉन्फ़िगरेशन में बदलाव शुरू होने पर, प्लेबैक वहीं से शुरू हो जहां वह रुका था
कॉन्फ़िगरेशन में होने वाले बदलावों में, अक्सर 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 मोड में इस्तेमाल किए जा सकने वाले फ़ोल्ड किए जा सकने वाले डिवाइसों पर, अपने ऐप्लिकेशन को अलग-अलग तरीके से दिखाने के लिए, Jetpack
WindowManager API का इस्तेमाल करें. जैसे, FoldingFeature.
फ़ोल्ड किए जा सकने वाले डिवाइसों के पोस्चर, स्थितियों, और कैमरे की झलक की सुविधा के बारे में ज़्यादा जानने के लिए, डेवलपर के लिए बनी इन गाइड को देखें:
- फ़ोल्ड किए जा सकने वाले डिवाइसों के बारे में जानकारी
- अपने ऐप्लिकेशन को फ़ोल्ड किए जा सकने वाले डिवाइसों के हिसाब से बनाना
फ़ोल्ड किए जा सकने वाले डिवाइसों से, देखने का शानदार अनुभव मिलता है. रियर डिसप्ले मोड और ड्यूअल‑स्क्रीन मोड की मदद से, फ़ोल्ड किए जा सकने वाले डिवाइसों के लिए, डिसप्ले की खास सुविधाएं बनाई जा सकती हैं. जैसे, रियर‑कैमरा सेल्फ़ी की झलक और इनर और आउटर स्क्रीन पर एक साथ, लेकिन अलग-अलग डिसप्ले. ज़्यादा जानकारी के लिए, ये लेख पढ़ें:
ओरिएंटेशन को नैचुरल सेंसर ओरिएंटेशन पर लॉक करना
इस्तेमाल के कुछ खास मामलों में—खास तौर पर, ऐसे ऐप्लिकेशन जिन्हें डिवाइस की फ़ोल्ड की गई स्थिति से अलग, पूरी स्क्रीन पर दिखाने की ज़रूरत होती है—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
रोटेशन वेक्टर (कंपास या एक्सआर ऐप्लिकेशन में इस्तेमाल किए जाते हैं) के लिए, SensorManager.remapCoordinateSystem() का इस्तेमाल करके, कैमरे के लेंस की दिशा या स्क्रीन के सबसे ऊपरी हिस्से को मौजूदा रोटेशन के आधार पर नए ऐक्सिस पर मैप करें.
ऐप्लिकेशन की कंपैटिबिलिटी
ऐप्लिकेशन को, ऐप्लिकेशन की क्वालिटी से जुड़े दिशा-निर्देशों का पालन करना होगा, ताकि सभी फ़ॉर्म फ़ैक्टर और कनेक्टेड डिसप्ले पर कंपैटिबिलिटी बनी रहे. अगर कोई ऐप्लिकेशन, दिशा-निर्देशों का पालन नहीं कर पाता है, तो डिवाइस बनाने वाली कंपनियां, कंपैटिबिलिटी से जुड़ी सेटिंग लागू कर सकती हैं. हालांकि, इससे लोगों के अनुभव पर असर पड़ सकता है.
ज़्यादा जानकारी के लिए, प्लैटफ़ॉर्म पर कंपैटिबिलिटी से जुड़े वर्कअराउंड की पूरी सूची देखें. खास तौर पर, कैमरे की झलक, ओवरराइड, और Android 16 API में होने वाले बदलावों से जुड़े वर्कअराउंड देखें. इनसे, आपके ऐप्लिकेशन के व्यवहार में बदलाव हो सकता है.
ज़रूरत के हिसाब से काम करने वाले ऐप्लिकेशन बनाने के बारे में ज़्यादा जानने के लिए, ऐप्लिकेशन की क्वालिटी से जुड़े दिशा-निर्देश देखें.