ChromeOS की टीम, डेवलपर टूल और फ़्रेमवर्क को बेहतर बनाने के लिए प्रतिबद्ध है. इससे Android ऐप्लिकेशन डेवलपर, अपने ऐप्लिकेशन को Chromebook के लिए आसानी से ऑप्टिमाइज़ कर पाएंगे. इसके लिए, हमें लगातार ऐसे तरीकों पर ध्यान देना होगा जिनसे डेवलपर को असरदार टूल सेट उपलब्ध कराए जा सकें. इससे उन्हें बड़ी स्क्रीन और ChromeOS के लिए ऐप्लिकेशन बनाने का बेहतर अनुभव मिल पाएगा.
समय के साथ-साथ, ChromeOS में कई बदलाव हुए हैं. इनमें से एक चुनौती, इंजीनियरों को गंभीर समस्याओं के बारे में समय पर और बार-बार बताना है. लिंट के नियम, क्वालिटी के लिए बहुत ज़रूरी होते हैं. ये डेवलपर को उन समस्याओं के बारे में बताते हैं जिन्हें ठीक न करने पर समस्याएं आ सकती हैं. लिंट के अपडेट किए गए नियमों से, डेवलपर को यह बेहतर तरीके से पता चलता है कि उनके ऐप्लिकेशन, ChromeOS पर कैसे काम करते हैं. साथ ही, उन्हें सॉफ़्टवेयर और हार्डवेयर से जुड़ी उन समस्याओं के बारे में भी पता चलता है जो ChromeOS डिवाइस पर चलने वाले Android ऐप्लिकेशन में ज़रूर आएंगी.
इन लिंट नियमों के बारे में ज़्यादा जानने और यह समझने के लिए कि ये नियम क्यों ज़रूरी हैं, हमारी ब्लॉग पोस्ट पढ़ें.
ये लिंट नियम कहां हैं?
हम कुछ महीनों से इस सुविधा पर काम कर रहे हैं. Android Studio के रिलीज़ शेड्यूल के साथ, कुछ लिंट नियमों को Electric Eel Canary बिल्ड के साथ पेश किया जा रहा है. इनमें से कुछ लिंट नियम, अब Flamingo Canary रिलीज़ में भी उपलब्ध हैं. हम आने वाले महीनों में, Android Studio के स्टेबल वर्शन में इन सुविधाओं को शामिल करने के लिए काम करते रहेंगे.
ध्यान देने वाली एक और अहम बात यह है कि Android Studio के नए वर्शन में, ये नियम डिफ़ॉल्ट रूप से चालू होंगे. इसका मकसद, इंजीनियरों को ChromeOS और बड़ी स्क्रीन के लिए ऐप्लिकेशन बनाने के बारे में ज़्यादा जानकारी देना है.
लिंट के नए नियम (Flamingo Canary 3 के हिसाब से अपडेट किए गए)
x86/x86_64 ABI के साथ काम करता है
ज़्यादातर Chromebook, Intel आर्किटेक्चर पर काम करते हैं. इसलिए, ये मुख्य रूप से x86 आर्किटेक्चर वाले प्लैटफ़ॉर्म होते हैं. जब NDK कोड को बाइनरी के हिस्से के तौर पर शामिल किया जाता है, तब ChromeOS को सही तरीके से काम करने के लिए x86 की ज़रूरत होती है. इससे परफ़ॉर्मेंस बेहतर होती है, क्योंकि ARM लाइब्रेरी से अनुवाद करने की ज़रूरत नहीं होती. इसलिए, हम आपको यह सुझाव देते हैं कि आपकी डेवलपमेंट टीम, x86 या बेहतर होगा कि x86_64 आर्किटेक्चर के लिए सहायता जोड़े. इससे ChromeOS या किसी भी Intel डिवाइस पर नेटिव कोड की परफ़ॉर्मेंस बेहतर होगी.
उपाय
अगर हो सके, तो build.gradle में मौजूद abiSplits के अंदर x86 और x86_64 को जोड़ें. साथ ही, पक्का करें कि इन एबीआई के साथ काम करने के लिए, कोड को सही फ़ोल्डर में जोड़ा जा रहा हो. ज़्यादा जानकारी के लिए, Android ABIs के बारे में दस्तावेज़ और ADS से ABI Support के बारे में बातचीत देखें.
ध्यान दें: पक्का करें कि इस्तेमाल की जा रही तीसरे पक्ष की सभी लाइब्रेरी में x86 और x86_64 बाइनरी भी शामिल हों.
ChromeOS के हार्डवेयर से जुड़ी सीमाएं
ज़्यादातर ChromeOS डिवाइसों में, Android फ़ोन की तुलना में हार्डवेयर सेंसर और अन्य सुविधाएं कम होती हैं. इस नियम का मकसद, डेवलपर को यह बताना है कि अगर android:required=true के साथ <uses-feature> फ़्लैग का इस्तेमाल किया जाता है, तो आपका ऐप्लिकेशन ChromeOS पर Google Play Store पर उपलब्ध नहीं होगा. हमारा सुझाव है कि आप यह पक्का करें कि हार्डवेयर की सुविधा डिफ़ॉल्ट रूप से ज़रूरी न हो. इससे यह पक्का किया जा सकेगा कि आपका ऐप्लिकेशन ज़्यादा से ज़्यादा डिवाइसों पर ऐक्सेस किया जा सके. इसके बजाय, रन टाइम में किसी खास हार्डवेयर की जांच करने के लिए, डिफ़ेंसिव कोड जोड़ा जा सकता है. इसका एक उदाहरण यह होगा
<uses-feature android:name="android.hardware.camera" android:required="true">
उपाय
पक्का करें कि आपके ऐप्लिकेशन में मौजूद सुविधाएं वाकई ज़रूरी हों. अगर ऐसा नहीं है, तो android:required पैरामीटर को false में बदलें. साथ ही, जब एपीआई कॉल की ज़रूरत हो, तब डिफ़ेंसिव प्रोग्रामिंग जोड़ें. ज़्यादा जानकारी के लिए, साफ़ तौर पर बताई गई सुविधाओं के बारे में दस्तावेज़ देखें.
ऐसी गतिविधियां जिनका साइज़ नहीं बदला जा सकता
डिफ़ॉल्ट रूप से, Android Runtime for ChromeOS, Chromebook पर Android R या उसके बाद का वर्शन चलाने वाले Android ऐप्लिकेशन को फ़ोन या टैबलेट वर्शन में शुरू करता है. यह डिफ़ॉल्ट यूज़र इंटरफ़ेस (यूआई) की स्थिति पर आधारित होता है. हालांकि, एक तीसरा विकल्प भी है, जो ChromeOS उपयोगकर्ताओं के लिए बेहतर है. यह विकल्प, साइज़ बदलने वाला मोड है. इस फ़्लैग को अपनी गतिविधि के हिस्से के तौर पर चालू करने से, उन उपयोगकर्ताओं को फ़ायदा मिलता है जो मल्टी-विंडो वाले किसी भी एनवायरमेंट में आपके ऐप्लिकेशन का इस्तेमाल कर सकते हैं. वे आपके ऐप्लिकेशन का साइज़ बदलकर, उसे अपनी ज़रूरत के हिसाब से कर सकते हैं. इन बदलावों की मदद से, उपयोगकर्ता अपनी ज़रूरतों के हिसाब से यूज़र इंटरफ़ेस (यूआई) को बड़ा या छोटा कर सकेंगे. अपने मेनिफ़ेस्ट में ये बदलाव जोड़ने के बाद, अपने ऐप्लिकेशन को नीचे दिए गए डेस्कटॉप एम्युलेटर के हिसाब से टेस्ट करें.
उपाय
अपनी AndroidManifest.xml फ़ाइल में मौजूद गतिविधि में resizableActivity="true" एट्रिब्यूट जोड़ें. ज़्यादा जानकारी के लिए, बड़ी स्क्रीन पर ऐप्लिकेशन इस्तेमाल करने से जुड़ी पाबंदियों के बारे में दस्तावेज़ पढ़ें.
कॉन्फ़िगरेशन में बदलाव
रीसाइज़ की जा सकने वाली स्क्रीन के साथ एक बड़ी समस्या यह है कि जब भी कोई उपयोगकर्ता ऐप्लिकेशन का साइज़ बदलता है, तो onConfigurationChanged() को कॉल किया जाता है. अगर आपका ऐप्लिकेशन उस तरीके के अंदर पूरी तरह से फिर से ड्रॉ कर रहा है, तो इससे परफ़ॉर्मेंस पर असर पड़ेगा. फ़िलहाल, हम यह जांच कर रहे हैं कि finish() को onConfigurationChanged के अंदर कॉल न किया जाए. ऐसा इसलिए, क्योंकि आपको savedInstanceState को ज़्यादा बारीकी से मैनेज करना चाहिए, न कि पूरे व्यू को फिर से रेंडर करना चाहिए. हम ऐसे मामलों का पता लगाते रहेंगे जिनमें परफ़ॉर्मेंस में गिरावट आएगी. साथ ही, इस नियम को उसके मुताबिक अपडेट करते रहेंगे.
उपाय
पक्का करें कि आपकी गतिविधियों और फ़्रैगमेंट में, onConfigurationChanged() API के अंदर finish() को कॉल न किया गया हो. ज़्यादा जानकारी के लिए, कॉन्फ़िगरेशन में हुए बदलावों को मैनेज करने से जुड़ा दस्तावेज़ पढ़ें.
कीबोर्ड और माउस की सुविधा
Jetpack Compose का इस्तेमाल बढ़ने की वजह से, हम यह पक्का करना चाहते थे कि इन लाइब्रेरी का इस्तेमाल करके ऐप्लिकेशन बनाने के दौरान, माउस और कीबोर्ड की सुविधा भी शामिल हो. समय के साथ, हम माउस, कीबोर्ड, ट्रैकपैड, और अन्य पेरिफ़ेरल इंटरैक्शन के इस्तेमाल को बढ़ाते रहेंगे. बेसलाइन अनुभव पाने के लिए, आपको Gradle की डिपेंडेंसी को ज़रूरी वर्शन में अपडेट करना होगा.
उपाय
androidx.compose.foundation:foundation को कम से कम 1.2 वर्शन पर अपडेट करें. ज़्यादा जानकारी के लिए, Compose वर्शन के रिलीज़ नोट लिखना लेख पढ़ें.
अहम जानकारी: 90% उपयोगकर्ता, Chromebook पर ऐप्लिकेशन के साथ इंटरैक्ट करने के लिए कीबोर्ड और माउस का इस्तेमाल करते हैं. (सोर्स: Google का 2022 का इंटरनल डेटा*)
सुझाव/राय दें या शिकायत करें
टीम, इन टूल को बेहतर बनाने के साथ-साथ बड़ी स्क्रीन के लिए ऑप्टिमाइज़ेशन से जुड़े दस्तावेज़ों को बेहतर बनाने के लिए लगातार काम कर रही है. इस प्रोसेस में सबसे अहम चरण यह है कि आप हमें Android Studio में लागू किए गए लिंट के नियमों के बारे में सुझाव/राय दें या शिकायत करें. इससे हमें यह पता चलेगा कि ये नियम कितने सटीक और मददगार हैं. इसके लिए, नियम के बारे में सुझाव/राय दें या शिकायत करें. Android Studio में lint नियम दिखने पर, “इस चेतावनी के बारे में सुझाव, शिकायत या राय दें” पर क्लिक करें. आपको एक ऐसे डायलॉग पर ले जाया जाएगा जो यहां दिए गए डायलॉग जैसा दिखता है. दी गई जानकारी जितनी सटीक और ज़्यादा होगी, हम उतने ही बेहतर तरीके से और तेज़ी से ज़रूरी बदलाव कर पाएंगे.
