Android के लिए विकास के कुछ "नुकसान"

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

इस लेख में, मैं कई वास्तविक बगों पर विचार करना चाहूंगा जो हमारे उपयोगकर्ताओं के बीच हुए हैं और उन्हें हल करने के तरीकों के बारे में बात करते हैं।

लेख संभावित समस्याओं का एक विस्तृत विश्लेषण होने का दिखावा नहीं करता है, यह सिर्फ एक वास्तविक एंड्रॉइड एप्लिकेशन के जीवन की कहानी है।

RTFM ( http://en.wikipedia.org/wiki/RTFM )

चूंकि एंड्रॉइड के लिए विकसित करते समय आपको यह ध्यान रखना होगा कि आपका एप्लिकेशन विभिन्न उपकरणों की एक बड़ी संख्या पर चल सकता है, आपको संगतता समस्याओं के बारे में सोचने की आवश्यकता है।

उदाहरण के लिए, हमारे उपयोगकर्ताओं को हुई त्रुटियों में से एक:

java.lang.NoClassDefFoundError: android.util.Patterns 

और कारण सरल है, प्रलेखन के अनुसार, क्लास android.util.Patterns एपीआई संस्करण 8 (एंड्रॉइड 2.2.x) के साथ उपलब्ध है, और उपयोगकर्ता के पास 2.1 संस्करण था। हमने इस कोड को try/catch में लपेटकर निश्चित किया है।

यहाँ प्रलेखन के असावधान पढ़ने के कारण एक और समान समस्या है:

 android.os.NetworkOnMainThreadException at android.os.StrictMode$AndroidBlockGuardPolicy.onNetwork(StrictMode.java:1077) at java.net.InetAddress.lookupHostByName(InetAddress.java:477) at java.net.InetAddress.getAllByNameImpl(InetAddress.java:277) at java.net.InetAddress.getAllByName(InetAddress.java:249) 

बात यह है कि संस्करण 3.0 से Android में डिफ़ॉल्ट रूप से सख्त मोड ( http://developer.android.com/reference/android/os/StrictMode.html ) सक्षम हो गया है। इसका मतलब है कि आपका एप्लिकेशन मुख्य UI थ्रेड से सीधे नेटवर्क तक नहीं पहुंच सकता है, क्योंकि इसमें कुछ समय लग सकता है और मुख्य थ्रेड अवरुद्ध है और अन्य घटनाओं पर प्रतिक्रिया नहीं देता है। हमने इस तरह के व्यवहार से बचने की कोशिश की, लेकिन एक स्थान पर एक साधारण नेटवर्क कॉल बनी रही। समस्या को इस तथ्य से हल किया गया था कि हमने इस कोड को किसी अन्य थ्रेड में स्थानांतरित कर दिया।

डिवाइस को घुमाएं - क्या उपयोगकर्ता के लिए सरल और अधिक परिचित हो सकता है?

ऐसा लगता है कि मोबाइल उपकरणों के लिए, स्क्रीन अभिविन्यास को बदलना एक ऐसी चीज है जो अक्सर उपयोग की जाती है और परिचित है कि इसे एपीआई में परिलक्षित किया जाना चाहिए। यानी इस स्थिति को बहुत सरलता से संभाला जाना चाहिए। लेकिन नहीं। कई बारीकियां हैं।

मान लीजिए हमें एक ऐसा एप्लिकेशन बनाने की ज़रूरत है जो किसी चीज़ की सूची डाउनलोड करता है और उसे स्क्रीन पर प्रदर्शित करता है। यानी जब Activity शुरू होती है ( onCreate() विधि में) हम स्ट्रीम शुरू करते हैं (ताकि UI स्ट्रीम को ब्लॉक न करें), जो डेटा लोड करेगा। यह धागा कुछ समय से चल रहा है, इसलिए हम ProgressDialog में लोडिंग प्रक्रिया प्रदर्शित करेंगे। सब कुछ सरल और अद्भुत है।

लेकिन, लोड करने के बाद, उपयोगकर्ता ने डिवाइस को चारों ओर घुमा दिया और यहां हमें पता चला कि ProgressDialog फिर से दिखाई दिया और हमने फिर से अपना डेटा लोड किया। लेकिन कुछ भी नहीं बदला है? डिवाइस को चालू करके किसी व्यक्ति के लिए इस सूची को देखना अधिक सुविधाजनक है।

और बात यह है कि onCreate() विधि को न केवल तब कहा जाता है जब Activity , बल्कि स्क्रीन को घुमाए जाने पर भी! लेकिन हम उपयोगकर्ता को डाउनलोड के लिए फिर से इंतजार करने के लिए मजबूर नहीं करना चाहते हैं। हमें केवल पहले से लोड किए गए डेटा को फिर से दिखाना है।

यदि हम इंटरनेट पर खोज करते हैं, तो हमें इस समस्या के वर्णन के लिए कई लिंक मिलेंगे और इस समस्या को हल करने के तरीके की एक बड़ी संख्या भी। और सबसे बुरी बात यह है कि इनमें से अधिकांश लिंक गलत समाधान प्रदान करते हैं। इसका एक उदाहरण इस प्रकार है - http://codesex.org/articles/33-android-rotate

onConfigurationChanged() माध्यम से स्क्रीन रोटेशन प्रोसेसिंग न करें! यह गलत है! आधिकारिक दस्तावेज में स्पष्ट रूप से कहा गया है कि " इस विशेषता का उपयोग करने से बचा जाना चाहिए और केवल अंतिम उपाय के रूप में उपयोग किया जाना चाहिए। " Http://developer.android.com/guide/topics/manifest/activity-element.html#config

लेकिन सही दृष्टिकोण यहाँ वर्णित है - http://developer.android.com/guide/topics/resources/runtime-changes.html और जैसा कि अभ्यास से पता चलता है, इसे लागू करना आसान नहीं है।

विचार यह है कि स्क्रीन को onRetainNonConfigurationInstance() से पहले onRetainNonConfigurationInstance() Android आपकी Activity के onRetainNonConfigurationInstance() विधि को कॉल करेगा। और आप इस विधि से डेटा (उदाहरण के लिए, लोड की गई वस्तुओं की एक सूची) को वापस कर सकते हैं, जो आपकी Activity के onCreate() विधि में 2 कॉल के बीच सहेजा जाएगा। फिर, जब आप getLastNonConfigurationInstance() कॉल करते हैं onCreate() तो आप getLastNonConfigurationInstance() कॉल कर सकते हैं जो आपके लिए सहेजे गए डेटा को लौटा देगा। यानी Activity बनाते समय Activity आप getLastNonConfigurationInstance() कॉल getLastNonConfigurationInstance() और यदि यह आपको डेटा getLastNonConfigurationInstance() , तो यह डेटा पहले ही लोड हो चुका है और आपको केवल इसे प्रदर्शित करने की आवश्यकता है। यदि आपने डेटा वापस नहीं किया है, तो डाउनलोड शुरू करें।

लेकिन व्यवहार में, स्थिति इस तरह दिखती है। जब उपयोगकर्ता डिवाइस को घुमाता है तो हमारे पास 2 विकल्प हो सकते हैं। पहला विकल्प यह है कि जब डेटा लोड हो रहा है (हमारी स्ट्रीम काम कर रही है जो डेटा को लोड करता है और उसी समय ProgressDialog प्रदर्शित होता है) या डेटा पहले से लोड है और हमने उन्हें प्रदर्शन के लिए सूची में सहेजा है। यह पता चला है कि पहले मामले में, मुड़ते समय, हमें एक काम करने वाले धागे के लिंक को बचाना होगा, और दूसरे मामले में, पहले से लोड की गई सूची का लिंक। हम ऐसा करते हैं।

लेकिन यह हमारे कोड को जटिल बनाता है और मुझे सरल और सहज नहीं लगता है। इसके अलावा, जब स्क्रीन के ओरिएंटेशन में बदलाव होता है और हमने डेटा लोडिंग स्ट्रीम को सेव कर लिया होता है, तो हम onCreate() साथ फिर से ProgressDialog को पुनर्स्थापित करने के लिए मजबूर हो जाते हैं! और अगर आप यहां जोड़ते हैं कि हमारे एप्लिकेशन में उपयोगकर्ता विभिन्न स्थानों से डेटा डाउनलोड कर सकता है और हमारे पास एक डेटा लोडिंग स्ट्रीम नहीं है, लेकिन कई - एक साधारण स्क्रीन रोटेशन की सेवा करने वाले कोड की मात्रा बस बहुत बड़ी हो जाती है।

ईमानदारी से, मुझे यह समझ में नहीं आया कि यह इतना कठिन क्यों किया गया।

धाराओं या AsyncTask का उपयोग करने के बारे में थोड़ा और अधिक।

आइए डेटा को किसी अन्य स्ट्रीम में थोड़ा और विस्तार से देखें, क्योंकि एक ही समय में अप्रत्याशित "आश्चर्य" हमें इंतजार कर रहा था।

सिद्धांत का एक सा: मुख्य UI थ्रेड के अलावा एक थ्रेड के निर्माण और संचालन की सुविधा के लिए, एक विशेष वर्ग बनाया गया था - AsyncTask ( http://developer.android.com/reference/android/os/AsyncTask.html )

इसका सार यह है कि इसके पास पहले से तैयार तरीके हैं onPreExecute() और onPostExecute(Result) जो मुख्य UI थ्रेड में निष्पादित होते हैं और जो कुछ प्रदर्शित करने के लिए कार्य करते हैं और एक doInBackground (Parad ...) विधि है जिसके अंदर मुख्य काम और यह एक अलग धागे में स्वचालित रूप से शुरू होता है। यह कैसा दिखता है, इसके लिए नमूना कोड यहां दिया गया है:

 private class MyTask extends AsyncTask<Void, Void, Void> { private ProgressDialog spinner; @Override protected void onPreExecute() { //     ProgressDialog //       //     UI  spinner = new ProgressDialog(MyActivity.this); spinner.setMessage(" ..."); spinner.show(); } @Override protected Void doInBackground(Void... text) { //         //       } @Override protected void onPostExecute(Void result) { //  .  ProgressDialog. //     UI  spinner.dismiss(); } } 

सब कुछ सरल और सुंदर है।

लेकिन अब थोड़ा अभ्यास। यहाँ एक वास्तविक उपयोगकर्ता से एक त्रुटि है:

 android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@40515bd0 is not valid; is your activity running? at android.view.ViewRoot.setView(ViewRoot.java:534) at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:177) at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:91) at android.view.Window$LocalWindowManager.addView(Window.java:424) at android.app.Dialog.show(Dialog.java:241) at ru.reminded.android.social.SocialDataLoader.onPreExecute(SocialDataLoader.java:106) at android.os.AsyncTask.execute(AsyncTask.java:391) at ru.reminded.android.util.SocialAdapterUtils.loadAdapterData(SocialAdapterUtils.java:52) at ru.reminded.android.util.SocialAdapterUtils.access$0(SocialAdapterUtils.java:50) at ru.reminded.android.util.SocialAdapterUtils$1.onComplete(SocialAdapterUtils.java:41) 

और इस त्रुटि का मतलब है कि जब हम onPreExecute() विधि में onPreExecute() , तो MyActivity के संदर्भ में बनाया गया यह ProgressDialog पहले MyActivity ही निष्क्रिय है और यह स्क्रीन पर नहीं है! ठीक है, मैं अब भी समझता हूं कि onPostExecute() कॉल करने पर यह कैसे हो सकता है। यानी उदाहरण के लिए, जब हम डेटा लोड कर रहे थे, तो उपयोगकर्ता ने वापस क्लिक किया और हमारे ProgressDialog ने स्क्रीन को छोड़ दिया। लेकिन यह कैसे सही कहा जा सकता है जब लोड कहा जाता है, जब Activity बंद होने पर यह कोड तुरंत शुरू होता है, मेरे लिए स्पष्ट नहीं है।

लेकिन किसी भी स्थिति में, हमें ऐसी स्थितियों को संभालना चाहिए, इसलिए हमने स्पिनर.शो spinner.show() और spinner.dismiss() विधियों को try/catch साथ ऐसा करने का फैसला किया। बेशक, समाधान बहुत सुंदर नहीं है, लेकिन हमारे मामले में यह काफी कार्यात्मक है।

वैसे, एंड्रॉइड के लिए फेसबुक एसडीके में उदाहरण के लिए एक ही कोड है, जिसे अन्य अनुभवी डेवलपर्स द्वारा विकसित किया गया था। और हमारे पास ऐसी परिस्थितियां भी थीं जब ProgressDialog बंद होने पर एप्लिकेशन क्रैश हो गया। हमें उनके कोड में प्रसंस्करण जोड़ना था। तो यह समस्या केवल हम में ही नहीं है।

यहां एक और समस्या जोड़ें जो पहले वर्णित थी। डिवाइस को चालू करते समय, आपको ProgressDialog को फिर से बनाना होगा यदि डेटा लोडिंग के दौरान बारी थी। इससे यहां हेल्पर कोड भी जुड़ जाएगा।

और यह याद रखने योग्य है कि doInBackground() विधि को एक अलग थ्रेड में निष्पादित किया जाता है, और इसलिए यदि डेटा लोड करते समय कोई त्रुटि हुई है, तो आप सीधे वहां से अलर्ट जारी नहीं कर सकते हैं, क्योंकि यह यूआई स्ट्रीम नहीं है। आपको त्रुटि को सहेजने की आवश्यकता है, और फिर onPostExecute(Void result) विधि में लोड स्ट्रीम से बाहर निकलने के बाद, आप पहले से ही कुछ दिखा सकते हैं।

यानी फिर से, बहुत सारे सहायक कोड और इतना सरल नहीं ...

AlarmManager

और ऐसे क्षण हैं जो प्रलेखन में बिल्कुल भी वर्णित नहीं हैं। उदाहरण के लिए, हमारे आवेदन में हम अलार्म मैनजर ( http://developer.android.com/reference/android/app/AlarmManager.html ) का उपयोग करते हैं जो हमें उपयोगकर्ता को संदेश जारी करने में थोड़ी देर के बाद मदद करता है जब हमारा आवेदन पहले से ही बंद है।

यह अलार्म मैनजर एक बहुत ही उपयोगी चीज है, एकमात्र समस्या यह है कि कभी-कभी यह इसमें मौजूद सूचनाओं को "खो" देता है! हमने यह समझने के लिए बहुत समय बिताया कि यह कैसे और क्यों होता है, सभी दस्तावेज के माध्यम से अफवाह हुई और कुछ भी नहीं मिला। काफी संयोग से, हम "इस चर्चा" - http://stackoverflow.com/questions/9101818/how-to-create-a-persistent-alarmmanager पर आ गए।

यह पता चला है कि यदि एप्लिकेशन क्रैश हो जाता है, या उपयोगकर्ता कार्य प्रबंधक (जो संभव है और काफी सामान्य है) के माध्यम से आवेदन को मारता है, तो अलार्म मैनजर में इस एप्लिकेशन के लिए सभी सूचनाएं DELETED हैं! यह आश्चर्य की बात है! मुझे वहां की एक टिप्पणी विशेष रूप से पसंद आई: "पुनः अलार्म रद्द: स्पष्टीकरण के लिए धन्यवाद। मैंने एंड्रॉइड टीम के ऑफिस के घंटे g + हैंगआउट पर यह पूछा और वे इस व्यवहार के बारे में भ्रमित भी लग रहे थे। क्या यह कहीं भी प्रलेखित है? "

इसलिए अब जब आप एप्लिकेशन शुरू करते हैं, तो हम कॉन्फ़िगर किए गए नोटिफिकेशन को फिर से बनाने के लिए मजबूर होते हैं, क्योंकि इस तरह के नोटिफिकेशन होने या नहीं होने की जांच करने के लिए AlarmManager में एक API भी नहीं है।

ऐसा होता है ...

यहां कुछ और त्रुटियां हैं जो हमने अपने उपयोगकर्ताओं के साथ पंजीकृत की हैं। हमारे आवेदन में, हम विभिन्न सामाजिक नेटवर्क के लिए OAuth प्रमाणीकरण का उपयोग करते हैं और इसलिए Android में एक पूर्णकालिक ब्राउज़र लॉन्च करने के लिए मजबूर होते हैं (जिसके माध्यम से OAuth काम करना चाहिए)। उसी समय, यह समय-समय पर "गिर" जाता है

 android.util.AndroidRuntimeException: { what=1004 when=-14ms arg2=1 } This message is already in use. at android.os.MessageQueue.enqueueMessage(MessageQueue.java:187) at android.os.Handler.sendMessageAtTime(Handler.java:457) at android.os.Handler.sendMessageDelayed(Handler.java:430) at android.os.Handler.sendMessage(Handler.java:367) at android.os.Message.sendToTarget(Message.java:349) at android.webkit.WebView$5.onClick(WebView.java:1250) at com.android.internal.app.AlertController$ButtonHandler.handleMessage(AlertController.java:172) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:130) at android.app.ActivityThread.main(ActivityThread.java:3703) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:507) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599) at dalvik.system.NativeStart.main(Native Method) 

एक और बात:

 java.lang.NullPointerException at android.os.Message.sendToTarget(Message.java:348) at android.webkit.WebView$4.onClick(WebView.java:1060) at com.android.internal.app.AlertController$ButtonHandler.handleMessage(AlertController.java:158) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:123) at android.app.ActivityThread.main(ActivityThread.java:4627) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:521) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:860) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618) at dalvik.system.NativeStart.main(Native Method) 

और यह भी:

 java.lang.IndexOutOfBoundsException: setSpan (-1 ... -1) starts before 0 at android.text.SpannableStringBuilder.checkRange(SpannableStringBuilder.java:949) at android.text.SpannableStringBuilder.setSpan(SpannableStringBuilder.java:522) at android.text.SpannableStringBuilder.setSpan(SpannableStringBuilder.java:514) at android.text.Selection.setSelection(Selection.java:74) at android.text.Selection.setSelection(Selection.java:85) at android.widget.TextView.performLongClick(TextView.java:8621) at android.webkit.WebTextView.performLongClick(WebTextView.java:617) at android.webkit.WebView.performLongClick(WebView.java:4471) at android.webkit.WebView$PrivateHandler.handleMessage(WebView.java:8285) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:150) at android.app.ActivityThread.main(ActivityThread.java:4389) at java.lang.reflect.Method.invokeNative(Native Method) at java.lang.reflect.Method.invoke(Method.java:507) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:849) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:607) at dalvik.system.NativeStart.main(Native Method) 

निष्कर्ष

ऊपर वर्णित सब कुछ के बावजूद, मुझे एंड्रॉइड विकसित करना पसंद है। असल में, एपीआई अच्छी तरह से सोचा और सुविधाजनक है।

बस हर जगह यह try/catch का उपयोग try/catch लायक है। यहां तक ​​कि जहां यह बिल्कुल स्पष्ट नहीं है।

और फिर भी ... निश्चित रूप से, नहीं - ऐसा नहीं है, लेकिन उस तरह - हमेशा उपयोगकर्ताओं से त्रुटियों के बारे में जानकारी एकत्र करते हैं। हम इसके लिए ACRA लाइब्रेरी ( http://code.google.com/p/acra/ ) का उपयोग करते हैं। इसके डेवलपर्स को बहुत बहुत धन्यवाद!