आसानी से इस्तेमाल करने के लिए डिज़ाइन करना

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

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

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

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

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

इस दस्तावेज़ में, बिना किसी रुकावट के काम करने से जुड़ी सामान्य समस्याओं और उनसे बचने के तरीके के बारे में बताया गया है.

डेटा को न हटाएं

हमेशा ध्यान रखें कि Android एक मोबाइल प्लैटफ़ॉर्म है. यह बात आपको सामान्य लग सकती है, लेकिन यह याद रखना ज़रूरी है कि कोई दूसरी ऐक्टिविटी (जैसे कि "इनकमिंग फ़ोन कॉल" ऐप्लिकेशन) किसी भी समय आपकी ऐक्टिविटी के ऊपर पॉप-अप हो सकती है. इससे onSaveInstanceState() और onPause() तरीके ट्रिगर होंगे. साथ ही, इससे आपका ऐप्लिकेशन बंद हो जाएगा.

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

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

रॉ डेटा को सार्वजनिक न करें

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

"Android Way" का मतलब है कि एक ContentProvider बनाया जाए, ताकि आपके डेटा को अन्य ऐप्लिकेशन के साथ शेयर किया जा सके. इसके लिए, एक साफ़-सुथरा, सोच-समझकर बनाया गया, और रखरखाव में आसान एपीआई इस्तेमाल किया जाता है. ContentProvider का इस्तेमाल करना, Java भाषा के इंटरफ़ेस को डालने जैसा है. इससे, कोड के दो ऐसे हिस्सों को अलग-अलग किया जा सकता है जो एक-दूसरे से काफ़ी जुड़े हुए हैं. इसका मतलब है कि ContentProvider के इंटरफ़ेस में बदलाव किए बिना, अपने डेटा के इंटरनल फ़ॉर्मैट में बदलाव किया जा सकता है. साथ ही, इससे दूसरे ऐप्लिकेशन पर कोई असर नहीं पड़ेगा.

उपयोगकर्ता को बीच में न रोकें

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

इसका मतलब है कि बैकग्राउंड में चल रही BroadcastReceivers या Services से startActivity() को कॉल न करें. ऐसा करने से, फ़िलहाल चल रहा ऐप्लिकेशन बंद हो जाएगा. इससे उपयोगकर्ता को परेशानी होगी. इससे भी बुरी बात यह है कि आपकी गतिविधि "कीस्ट्रोक बैंडिट" बन सकती है. इसका मतलब है कि उसे वह इनपुट मिल सकता है जो उपयोगकर्ता पिछली गतिविधि को दे रहा था. आपके ऐप्लिकेशन के काम के आधार पर, यह बुरी खबर हो सकती है.

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

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

क्या आपको कई काम करने हैं? थ्रेड में जवाब देना

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

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

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

किसी एक ऐक्टिविटी स्क्रीन पर बहुत ज़्यादा जानकारी न दिखाएं

इस्तेमाल करने लायक किसी भी ऐप्लिकेशन में, कई अलग-अलग स्क्रीन होती हैं. अपने यूज़र इंटरफ़ेस की स्क्रीन डिज़ाइन करते समय, पक्का करें कि आपने Activity ऑब्जेक्ट के एक से ज़्यादा इंस्टेंस का इस्तेमाल किया हो.

डेवलपमेंट के आपके अनुभव के आधार पर, हो सकता है कि आप किसी गतिविधि को Java ऐप्लेट की तरह समझें. ऐसा इसलिए, क्योंकि यह आपके ऐप्लिकेशन का एंट्री पॉइंट होता है. हालांकि, यह पूरी तरह से सही नहीं है: जहां ऐप्लेट सबक्लास, Java ऐप्लेट के लिए एक ही एंट्री पॉइंट होता है वहीं ऐक्टिविटी को आपके ऐप्लिकेशन के लिए, संभावित तौर पर कई एंट्री पॉइंट में से एक माना जाना चाहिए. आपकी "मुख्य" ऐक्टिविटी और अन्य ऐक्टिविटी के बीच सिर्फ़ यह अंतर होता है कि "मुख्य" ऐक्टिविटी, AndroidManifest..xml फ़ाइल में "android.intent.action.MAIN" ऐक्शन में दिलचस्पी दिखाने वाली एकमात्र ऐक्टिविटी होती है.

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

सिस्टम की थीम को बढ़ाना

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

एक से ज़्यादा स्क्रीन रिज़ॉल्यूशन के साथ काम करने के लिए, यूज़र इंटरफ़ेस (यूआई) डिज़ाइन करना

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

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

मान लें कि नेटवर्क की स्पीड धीमी है

Android डिवाइसों में, नेटवर्क से कनेक्ट करने के कई विकल्प मिलेंगे. सभी में डेटा ऐक्सेस करने की सुविधा होगी. हालांकि, कुछ में यह सुविधा दूसरों की तुलना में ज़्यादा तेज़ी से काम करेगी. हालांकि, सबसे कम स्पीड वाला नेटवर्क GPRS है. यह GSM नेटवर्क के लिए, 3G से कम स्पीड वाली डेटा सेवा है. 3G की सुविधा वाले डिवाइस भी, 3G के अलावा अन्य नेटवर्क पर ज़्यादा समय बिताएंगे. इसलिए, आने वाले समय में भी नेटवर्क की स्पीड कम रहेगी.

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

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

टचस्क्रीन या कीबोर्ड का इस्तेमाल न करें

Android, कई तरह के हैंडसेट के साथ काम करेगा. इसका मतलब यह है कि कुछ Android डिवाइसों में पूरा "QWERTY" कीबोर्ड होगा, जबकि अन्य डिवाइसों में 40 बटन, 12 बटन या अन्य बटन कॉन्फ़िगरेशन होंगे. इसी तरह, कुछ डिवाइसों में टच-स्क्रीन होगी, लेकिन कई में नहीं होगी.

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

डिवाइस की बैटरी की खपत कम करें

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

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

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