"लगातार स्थिति" बनाम "वर्तमान स्थिति"

Question

onPause() में क्या सहेजना है और onSaveInstanceState() में सहेजने के लिए क्या निर्णय लेने का प्रयास कर रहा है, मैंने संकेतों और स्पष्ट दिशानिर्देशों के लिए संपूर्ण SO को कॉम्बो किया।

अगर मैं सही ढंग से समझ, onSaveInstanceState(), "क्रम परिवर्तन" या "वर्तमान स्थिति" (जो कुछ भी है कि इसका मतलब है) को बचाने के लिए सबसे अच्छा है, जबकि onPause() "लगातार राज्य" (जो कुछ भी है कि इसका मतलब है) को बचाने के लिए सबसे अच्छा है।

मुझे अभी भी यह तय करने में कठिनाई हो रही है कि मेरे आवेदन में "लगातार स्थिति" बनाम "वर्तमान स्थिति" क्या है। उदाहरण के लिए, जबकि उपयोगकर्ता वरीयताएं स्पष्ट रूप से लगातार होती हैं, क्या मुझे उन्हें onPause() में सहेजने की आवश्यकता होती है जब उपयोगकर्ता उन्हें हमेशा बदलते समय Android UI फ्रेमवर्क द्वारा स्वचालित रूप से सहेजे जाते हैं?

क्या कक्षा डेटा सदस्यों को onSaveInstanceState() में सहेजने की आवश्यकता है? क्या मुझे अपने आवेदन में प्रत्येक कक्षा के लिए ऐसा करने की ज़रूरत है?

मैं उलझन में हूं।

क्या आप onPause() में सहेजे जाने वाले वास्तविक दुनिया के उदाहरण ला सकते हैं और onSaveInstanceState() में क्या सहेजा जाना चाहिए? डिवाइस कॉन्फ़िगरेशन परिवर्तनों के लिए Except, यानी।

-

कुछ नए अंतर्दृष्टि, के बाद मेरे सवाल का जवाब दिया गया है:

• onSaveInstanceState के Bundlenot written to anything है, और यह किसी भी तरह से एक समान नहीं है।
• ऑनसेवस्टेंसस्टेट Bundle डेटा केवल held in memory होगा जब तक कि एप्लिकेशन बंद न हो जाए।

Answer 1

आपको उपयोगकर्ता प्राथमिकताओं को ऑन-ऑन में स्टोर करने की आवश्यकता नहीं है क्योंकि जैसा कि आप कहते हैं, ढांचा आपके लिए करता है।

लगातार डेटा बनाम राज्य जानकारी के बीच अंतर करने के लिए, एक टेक्स्ट एडिटर एप्लिकेशन के बारे में सोचें।

लगातार डेटा

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

राज्य डेटा

इसी तरह, आप 2 टैब और एक चर पटरियों कि जो टैब वर्तमान में चयनित किया गया है का कहना है। यह राज्य डेटा है जिसे आप ऑनवेस्टेंसस्टेट() पर स्टोर करेंगे।

ग्रे बात

अंत में कल्पना करें कि आप संपादक कि वर्णों की संख्या और संपादक में लाइनों की संख्या का ट्रैक रखता है में एक वर्ग है। यह राज्य डेटा है, आप इसे SaveInstanceState() पर संग्रहीत कर सकते हैं या आप इसे फिर से फेंक सकते हैं और फिर से शुरू करते समय इसे फिर से समझ सकते हैं। चाहे आप इसे फेंक दें, इस पर निर्भर हो सकता है कि गणना करने में कितना समय लगता है, उदाहरण के लिए यदि आप डेटा संग्रह करके नेटवर्क अनुरोध को रोक सकते हैं, तो ऐसा करें।

आगे विचार

अपने अनुप्रयोग के साथ खेल के द्वारा यह हो, तो एक ऐसा क्षेत्र है जहां आप सही डेटा दूर गिलहरी करने में विफल रहा स्पष्ट होना चाहिए। होम बटन हिट करने जैसी चीजें करना सुनिश्चित करें और फिर डिवाइस मैनेजर से अपना ऐप बंद करें। यह आपको कोने के मामलों को हिट करने देगा जहां आपका ऐप बंद होने की बजाए बंद हो गया है।

यदि आपका यूआई राज्य जीवन चक्र की घटनाओं में सुसंगत है और आपका उपयोगकर्ता डेटा रहता है, तो अच्छी नौकरी।

संपादित करें टिप्पणी

मुझे लगता है कि यहाँ मापदंड के 2 टुकड़े जब/क्या बचाने के लिए निर्धारित करने के लिए देखते हैं पर आधारित है।

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

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

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

• का एक प्राचीन लोड संस्करण क्या डेटा चालू करने के लिए है कि पिछले राज्य में उपयोगकर्ता देखा बदलने की जरूरत की कल्पना?
• आपको वापस पाने के लिए स्टोर करने के लिए आपको कौन सी डेटा स्टोर करने की आवश्यकता है?

यह वास्तव में कैसे एंड्रॉयड काम करता है, अपनी गतिविधि को नष्ट कर दिया और निर्मित कर रहा है और यह गति में टुकड़े फिर से स्थापित करने के लिए (यदि आप ऐसा करने के लिए चुनते हैं) अपने काम है।

Answer 2

यहां उत्तर दिया गया है। आप राज्य को तीन अलग-अलग तरीकों से बचा सकते हैं।

1) उप-वर्गीकरण ऐप (एक अच्छा विचार नहीं)। 2) साझा किए गए संदर्भ (सरल डेटा, त्वरित और विश्वसनीय के लिए अच्छा) 3) SQLite डेटाबेस (अधिक जटिल, विश्वसनीय भी)।

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

ऑनसेवस्टेंसस्टेट() लेआउट या अभिविन्यास परिवर्तन से संबंधित अस्थायी चर सहेजने के लिए है।

सारांश में लगातार राज्य/डेटा (कि एक दुर्घटना में जीवित रहने चाहिए), यथाशीघ्र बचाया जाना चाहिए, onPause() के लिए इंतजार नहीं है, क्योंकि वहाँ कोई गारंटी नहीं है। यही वास्तविकता है।

Answer 3

मेरे पास एक ऐसा गेम है, जहां मैं लगातार डेटा को गेमरवर में सहेजना चाहता हूं।

क्योंकि इसमें कुछ समय लग सकता है, मुझे में प्रयास करने और सहेजने की अच्छी बात नहीं है, बल्कि onStop में।

परीक्षण मैंने किया है के अनुसार, onStop पृष्ठभूमि में जबकि ब्लॉक चलाने के लिए सक्षम होने लगते हैं, कम से कम ऐसा है जब मैं (और onStop में 10m पाश को 1 के लिए एक सरल के साथ परीक्षण) घर प्रेस । क्या कोई इस अवरोध सिद्धांत की पुष्टि कर सकता है?

onStop, Honeycomb अप (api11+) की जरूरत है इससे पहले कि onClose कहा जाता है क्योंकि उस संस्करण इससे पहले कि आप को मार डाला हो सकता है।

here देखें और तालिका में killable देखें - यदि वास्तविकता दस्तावेज़ीकरण से मेल खाता है तो दूसरा प्रश्न है :)।