मैं अपनी पहली Android एप्लिकेशन पर काम कर रहा हूँ सहेजा गया है। इसमें एक मॉडल है जो डेटाबेस के लिए जारी रहता है क्योंकि उपयोगकर्ता अपडेट करता है।onSaveInstanceState/onPause - जब तक प्रतीक्षा राज्य पूरी तरह से पहले की प्रक्रिया की इजाजत दी मारे जाने के लिए
जब onSaveInsanceState कहा जाता है, मैं एक आईडी है कि दस्तावेज़ उपयोगकर्ता डेटाबेस से पर काम कर रहा था लोड करने के लिए इस्तेमाल किया जा सकता सहेजना चाहते हैं। लेकिन यह केवल तभी हो सकता है जब दस्तावेज डेटाबेस को पूरी तरह हिट कर लेता है। कुछ मामलों में, एक जटिल दस्तावेज़ को जारी रखने में कई सेकंड लग सकते हैं (मुझे उम्मीद है कि जब मैं सभी वर्बोज़ लॉगिंग कर लेता हूं तो यह तेजी से बढ़ जाएगा, और वास्तविक उपयोग में उपयोगकर्ता द्वारा चरणबद्ध चरण में एक जटिल दस्तावेज़ बनाया जाएगा, जिनमें से प्रत्येक डेटाबेस के लिए जारी रहेगा, इसलिए एक जटिल दस्तावेज़ के लिए सभी को एक ही समय में सहेजने की संभावना नहीं है)।
अब, Android पर सूत्रण की # 1 नियम है, "यूआई धागा ब्लॉक नहीं है" तो निश्चित रूप से डीबी बातचीत एक अलग थ्रेड पर होता है। लेकिन एंड्रॉइड लाइफसाइक्ल की मेरी समझ यह है कि कई मामलों में SaveInstanceState को कॉल किया जा रहा है क्योंकि एंड्रॉइड सिस्टम प्रक्रिया को मारना चाहता है। इससे पता चलता है कि मैं इस विधि को वापस लौटने की अनुमति नहीं दे सकता जब तक कि डीबी थ्रेड दस्तावेज़ को सहेजने में समाप्त नहीं हो जाता (और वास्तव में मेरे वर्तमान डिज़ाइन के साथ, मुझे वास्तव में पता नहीं है कि दस्तावेज़ की आईडी संख्या तब तक डीबी में सहेजी गई है, इसलिए मैं इसे सहेजे गए राज्य के बंडल में भी नहीं डाल सकता)।
यह इन परिस्थितियों जारी रहती कार्य के लिए इंतजार कर रहे यूआई धागा ब्लॉक करने के लिए के तहत उचित किया जाना है? जब onSaveInstanceState कहा जाता है क्योंकि प्रक्रिया को मार दिया जा रहा है, तो ऐप अब अग्रभूमि में दिखाई नहीं दे रहा है, इसलिए उत्तरदायी बनने के लिए कोई इंटरफ़ेस नहीं है। जब गतिविधि उदाहरण एक config अद्यतन है, जो होता है जब स्क्रीन अभिविन्यास परिवर्तन वालों द्वारा नष्ट किया जा रहा है
लेकिन onSaveInstanceState भी कहा जाता है। यह बहुत दुर्भाग्यपूर्ण है जब स्क्रीन किनारे घूर्णन कई सेकंड के लिए कुछ भी करने में विफल रहता है। इस मामले में प्रक्रिया (और इसलिए मेमोरी स्पेस) अभी भी आसपास है, इसलिए मुझे यह सुनिश्चित करने की ज़रूरत नहीं है कि दस्तावेज़ डेटाबेस को हिट करता है, अगर मैं बस इसकी आईडी के बजाय बंडल में इसका संदर्भ संग्रहीत कर सकता हूं। लेकिन मुझे इन दो मामलों के बीच अंतर बताने के तरीके से अवगत नहीं है।
वहाँ इन स्थितियों के लिए एक स्वीकृत अभ्यास है? क्या मुझे थ्रेड को सुरक्षित रखने के लिए अवरुद्ध करना चाहिए? क्या मैं ब्लॉक और प्रतीक्षा करने के लिए सामान्य जावा थ्रेड प्राइमेटिव का उपयोग कर सकता हूं? क्या ऐसा कुछ है जो मैं कर सकता हूं धागे को अवरुद्ध नहीं करता है, लेकिन यह सुनिश्चित करता है कि एंड्रॉइड प्रक्रिया को बंद करने से पहले लगातार कार्य समाप्त हो जाएगा?
यह सब पर भी लागू होता है, onSaveInstanceState के रूप में आवश्यक नहीं है।
मैंने सोचा था कि 'AsyncTask' की बात यह थी कि यह * * यूआई धागा ब्लॉक नहीं करता? क्या यह लंबे समय तक चलने वाले संचालन करने के लिए इसका उपयोग करने का पूरा बिंदु नहीं है? – Ben
आप कॉन्फ़िग के परिवर्तन पर समस्या हो रही है तो न चिंता, बस इस गतिविधि टैग में अपने mainfest फ़ाइल में configChanges लिख, तो यह onSaveInstanceState() फोन कभी नहीं डब्ल्यूएलएल जब उन्मुखीकरण बदल जाता है। यह अभ्यस्त बल गतिविधि को पुन: प्रारंभ करने के लिए –
यही काम है (लेकिन अपने स्वयं समस्या नहीं है), लेकिन पूरी तरह से सवाल है, जो मैं लगातार डेटा सुनिश्चित करते हैं कि कैसे हमें वास्तव में बचाया जब एप्लिकेशन मार दिया जाता है, तो बचत एक पृष्ठभूमि द्वारा किया जाता है के लिए अप्रासंगिक है धागा। – Ben