Flutter: जब ओएस द्वारा ऐप को मार दिया जाता है तो इंस्टेंस स्थिति सहेजी नहीं जाती है

https://github.com/flutter/flutter/issues/3427 भी संबंधित होने की संभावना है।

@eseidelGoogle यह सही है। स्पंदन गतिविधि स्थिति को किस प्रारूप में सहेजा जा सकता है, यदि यह वर्तमान संस्करण के समान ही हो सकता है?

अभी हम कुछ बचाने के लिए कुछ नहीं करते हैं।

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

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

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

लेकिन किसी भी मामले में हमें आज से बेहतर जरूर करना चाहिए।

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

वाह मुझे नहीं पता था कि यह मामला था? यह वास्तव में महत्वपूर्ण है, और यह उल्लेखनीय है कि कम मेमोरी वाले उपकरणों पर प्रक्रिया को आसानी से मारा जा सकता है!

PageStore (या संबंधित) को serialization.dart के माध्यम से onSaveInstanceState में बाइट स्ट्रीम के रूप में सहेजने के बारे में क्या?

@Takhion क्या आप "पेजस्टोर" को लिंक कर सकते हैं जिसका आप उल्लेख कर रहे हैं? मुझे इस मुद्दे को हल करने की कोशिश करने में दिलचस्पी है क्योंकि ऐसा लगता है कि इसे जल्द ही ठीक नहीं किया जाएगा (2029 का 31 दिसंबर आईएमएचओ बहुत दूर है)

@LouisCAD सुनिश्चित करें कि यह यहाँ है: https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/widgets/page_storage.dart

मुझे लगता है कि आपको इससे अधिक बचत करने की आवश्यकता होगी हालांकि: कम से कम वर्तमान मार्ग और शायद कुछ राज्य?
आपको क्या लगता है @Hixie?

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

क्या हम डार्ट कोड में आवश्यक जीवनचक्र की घटनाओं ("आप मारे जाने वाले हैं!", "बधाई हो, अब आप बहाल हो गए हैं") को उजागर करते हैं, ताकि डेवलपर्स स्थायी स्थिति को संभाल सकें? ऐसा लगता है कि समाधान तलाशने के लिए डेवलपर्स को अनलॉक करने की पर्याप्त क्षमता है। विचार?

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

@LouisCAD प्रतिक्रिया के लिए धन्यवाद। मैं कदमों में सोच रहा हूँ... पहला कदम क्या है? क्या हमारे पास अभी तक जीवनचक्र की घटनाओं का खुलासा नहीं हुआ है?

@sethladd मुझे जो कुछ भी मिला वह यह है , जो इंस्टेंस स्थिति को सहेजने/बहाल करने के लिए किसी भी कॉलबैक का खुलासा नहीं करता है

@ हिक्सी आपने # 3427 में उल्लेख किया है कि हमारे पास जीवनचक्र के लिए हुक हैं। क्या आपका मतलब https://docs.flutter.io/flutter/widgets/WidgetsBindingObserver-class.html से था ?

स्पंदन डिफ़ॉल्ट रूप से एकाधिक गतिविधियों का उपयोग कर रहा है? (उदाहरण के लिए यदि आप एक नई स्क्रीन पर जाते हैं)।

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

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

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

मैंने Android पर प्रक्रिया मृत्यु के बारे में एक लेख लिखा था https://medium.com/inloop/android-process-kill-and-the-big-implications-for-your-app-1ecbed4921cb

इसके अलावा, ऑनस्टॉप () स्थिति (होम पर क्लिक करने के बाद या यदि ऐप वर्तमान अग्रभूमि ऐप नहीं है onSaveInstanceState(Bundle) पर कॉल करके अपने राज्य को संग्रहीत करना आवश्यक है। तो हो सकता है कि फ़्लटर गतिविधि से आपकी "स्क्रीन" पर इस onCreate(Bundle saveInstanceState ) या onRestoreInstanceState(Bundle saveInstanceState) जीवनचक्र कॉलबैक में सहेजे गए राज्य के साथ बंडल वापस मिल जाएगा।

तो संक्षेप में - फ़्लटर शायद onSaveInstanceState() और onRestoreInstanceState() कॉलबैक अग्रेषित कर सकता है। आदर्श रूप से आप Android बंडल ऑब्जेक्ट को किसी ऐसी चीज़ में लपेटेंगे जिसका उपयोग फ़्लटर में भी किया जा सकता है। अगला कदम यह होगा कि स्क्रीन के अंदर सभी फ़्लटर विजेट्स को भी इन कॉलबैक के बारे में सूचित किया जाएगा और उनका उपयोग अपनी वर्तमान स्थिति को बनाए रखने के लिए किया जाएगा।
एंड्रॉइड ओएस तब बंडल लेगा और वास्तव में इसे डिस्क पर बनाए रखेगा ताकि प्रक्रिया के मारे जाने की स्थिति में यह खो न जाए और फिर से डिसेरिएलाइज़ किया जा सके।

उसके साथ अच्छा भाग्य :-)। कृपया ध्यान रखें और फ़्लटर के लिए इस Android स्थिति / जीवनचक्र नरक का बहुत अधिक परिचय न दें।

मुझे यकीन नहीं है कि यह आईओएस पर कैसे काम करता है - लेकिन मुझे लगता है कि कुछ समान है लेकिन इसका उपयोग करने के लिए "आवश्यक" नहीं है (?)

मेरे लिए एक जीवनचक्र कॉलबैक ठीक रहेगा। मैं सिर्फ धारावाहिक रेडक्स राज्य को स्टोर/लोड करूंगा।

पूरी प्रतिक्रिया के लिए धन्यवाद! @Takhion ने भी यहां मदद की पेशकश की। शायद एक एपीआई डिजाइन और पुस्तकालय एक अच्छी शुरुआत है? यदि वह पुस्तकालय काम करता है, तो हम और अधिक औपचारिक रूप से एकीकृत करने के लिए देख सकते हैं। साथ ही, पुस्तकालय यह पहचानने में मदद करेगा कि हमें निम्न-स्तरीय इंजन (यदि कुछ भी हो) पर क्या करने की आवश्यकता है। मूल रूप से: ठोस एपीआई प्रस्ताव क्या है?

स्पंदन डिफ़ॉल्ट रूप से एकाधिक गतिविधियों का उपयोग कर रहा है? (उदाहरण के लिए यदि आप एक नई स्क्रीन पर जाते हैं)

@DanielNovak Flutter अपनी "रूटिंग" प्रणाली का उपयोग करता है और डिफ़ॉल्ट रूप से यह एकल गतिविधि में एकल दृश्य के माध्यम से Android के साथ एकीकृत होता है। आप एक संकर एंड्रॉयड / स्पंदन एप्लिकेशन और इस तरह के संभावित कई गतिविधियों और स्पंदन दृश्य के रूप में हो सकता है, लेकिन इस मामले में आप आसानी से बचाने / सीधे Android के माध्यम से उदाहरण के राज्य बहाल कर सकते हैं।

मैं सिर्फ क्रमबद्ध रेडक्स राज्य को स्टोर/लोड करूंगा

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

स्पंदन Android ऑनपॉज़ जीवनचक्र घटना को उजागर करता है। Android onDestroy() जीवनचक्र घटना उजागर नहीं होती है। मुझे लगता है कि इंस्टेंस संबंधित स्थिति को संग्रहीत करने के लिए ऑनपॉज़() ईवेंट में शामिल होने का सही तरीका होगा।
Android के onSaveInstanceState() और onRestoreInstanceState() के साथ संगत होने के लिए,
@sethladd @LouisCAD क्या किसी ने डिज़ाइन प्रस्ताव बनाया है?

@ राजू-कड़वा ऑन पॉज़() इष्टतम नहीं है, ऑनसेव इंस्टेंसस्टेट() में हुक करना बेहतर है। यहां onSaveInstanceState से javadoc है जिसमें उल्लेख किया गया है कि onPause() को onSaveInstanceState की तुलना में अधिक नियमित रूप से कहा जाता है (आप आवश्यकता से अधिक बार राज्य की बचत को ट्रिगर कर रहे होंगे या जब यह बिल्कुल भी आवश्यक नहीं होगा):

इस पद्धति को गतिविधि जीवनचक्र कॉलबैक जैसे कि ऑनपॉज़ () के साथ भ्रमित न करें, जिसे हमेशा तब कहा जाता है जब कोई गतिविधि पृष्ठभूमि में या विनाश के रास्ते पर रखी जा रही हो, या ऑनस्टॉप () जिसे विनाश से पहले कहा जाता है। एक उदाहरण जब ऑनपॉज़ () और ऑनस्टॉप () कहा जाता है और यह विधि नहीं है जब कोई उपयोगकर्ता गतिविधि बी से गतिविधि ए पर वापस जाता है: बी पर सेव इंस्टेंसस्टेट (बंडल) पर कॉल करने की कोई आवश्यकता नहीं है क्योंकि उस विशेष उदाहरण को कभी भी बहाल नहीं किया जाएगा , इसलिए सिस्टम इसे कॉल करने से बचता है। एक उदाहरण जब onPause () को कॉल किया जाता है और onSaveInstanceState (बंडल) नहीं कहा जाता है, जब गतिविधि A के सामने गतिविधि B लॉन्च की जाती है: सिस्टम गतिविधि A पर onSaveInstanceState (बंडल) को कॉल करने से बच सकता है यदि यह B के जीवनकाल के दौरान नहीं मारा जाता है ए के यूजर इंटरफेस की स्थिति बरकरार रहेगी।

@Takhion

इंस्टेंस स्टेट बंडल को आपके संपूर्ण एंड्रॉइड ऐप स्टेट के लिए 1MB की हार्ड लिमिट के साथ IPC से गुजरना होगा

यह मेरा मुद्दा नहीं है।
मुझे बस यह जानने की जरूरत है कि कब बने रहना/पुनर्स्थापित करना है, डिस्क पर खुद को बनाए रखना मेरे लिए ठीक है।

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

@Takhion तुम मेरे पंखों के नीचे की हवा हो। प्रस्ताव देखने के लिए इंतजार नहीं कर सकता!

ठीक है, इसलिए मैं इसके लिए एक पीआर बना रहा हूं और मैंने एक रोडब्लॉक मारा: [ View.onSaveInstanceState ] (या [ Activity.onSaveInstanceState ], मामले के लिए) को सेव की गई इंस्टेंस स्थिति को समकालिक रूप से प्रदान करने की आवश्यकता है , और से मेरा अनुभव (और यह [टिप्पणी]) ऐसा लगता है कि होस्ट/प्लेटफ़ॉर्म संदेश केवल async हो सकते हैं। मुझे संदेह है क्योंकि वे एंड्रॉइड की संदेश कतार का उपयोग करते हैं।

@sethladd @Hixie @eseidelGoogle @ jason-simmons कृपया मुझे बताएं कि एंड्रॉइड से स्पंदन के लिए एकल सिंक्रोनस/ब्लॉकिंग कॉल करने का एक आसान तरीका है जिसमें एड-हॉक सी/सी ++ कोड शामिल नहीं है, क्योंकि [ dart:jni सेवानिवृत्त हो गया है]?

प्रतिलिपि @mravn-google

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

final MethodChannel channel = new MethodChannel(messenger, someName);
final CountDownLatch latch = new CountDownLatch(1);
channel.invokeMethod("someMethod", someArguments, new MethodChannel.Result() {
  <strong i="6">@Override</strong>
  public void success(Object result) {
    // handle successful invocation
    latch.countDown();
  }
  <strong i="7">@Override</strong>
  public void error(String errorCode, String errorMessage, Object errorDetails) {
    // handle failed invocation
    latch.countDown();
  }
  <strong i="8">@Override</strong>
  public void notImplemented() {
    // handle invocation of unimplemented method
    latch.countDown();
  }
});
try {
  latch.await();
} catch (InterruptedException e) {
  // handle interruption
}

आप कुंडी के बगल में एक final AtomicReference<SomeType> चर (या समान) घोषित कर सकते हैं, यदि आपको // handle xxx स्थानों से मूल्यों को latch.await() रिटर्न के बाद चलने वाले कोड तक पहुंचाने की आवश्यकता है।

धन्यवाद @ mravn-google!

@ mravn-google यह वही पहला तरीका है जिसकी मैंने कोशिश की थी, लेकिन Android पर मुख्य सूत्र हमेशा के लिए await() कॉल पर लटका रहता है :(

@Takhion ठीक है, बिल्कुल।

आप लैच का उपयोग करके हमेशा एसिंक्रोनस एपीआई कॉल को सिंक्रोनस में बदल सकते हैं

... जब तक कि एसिंक प्रतिक्रिया उस थ्रेड तक नहीं पहुंचाई जाती है जिस पर आप पहले से हैं: - /

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

@ mravn-google दुर्भाग्य से एंड्रॉइड इन खराब "अवसर की तुल्यकालिक विंडो" का _full_ है, जहां विधि कॉल से लौटने से पहले सब कुछ होने की आवश्यकता है! मेरे सिर के शीर्ष पर: कई Activity जीवनचक्र की घटनाएं, Broadcast Receiver , SyncAdapter आदि में विधियां। मुझे ईमानदारी से आश्चर्य है कि यह पहले एक बड़ा मुद्दा नहीं रहा है!

मेरी राय में, अगर हम चाहते हैं कि स्पंदन वास्तव में "मूल" एपीआई के माध्यम से फीचर समानता प्राप्त करे, तो सिंक्रोनस संदेश संचार होना जरूरी है।

@ मिट-मिट मेरा मतलब था SystemChannels.lifecycle और कुछ भी जो इसका उपयोग करता है, हाँ।

क्या यह https://github.com/flutter/flutter/issues/7560 जैसा ही है?

@sethladd मुझे ऐसा लगता है।

@ mravn-गूगल धन्यवाद! मैंने इसके पक्ष में #7560 बंद कर दिया है, बस बातचीत को धोखा देने और केंद्रीकृत करने के लिए।

मैं इस तरह के प्लेटफ़ॉर्म-टू-डार्ट संचार के लिए MethodChannel एक सिंक्रोनस समकक्ष जोड़ने की ओर झुकाव कर रहा हूं।

@ mravn-google यह कैसा चल रहा है? क्या मैं मदद कर सकता हूँ?

@Takhion धन्यवाद! जल्द ही होना चाहिए। मैं एक सिंक्रोनस मेथड चैनल पर काम कर रहा हूं, और मुझे उम्मीद है कि एक या दो दिन में पीआर हो जाएगा। एक बार जब यह वहां पहुंच जाएगा तो मैं आपकी समीक्षा के लिए पूछूंगा। मैं यह जांचने के लिए नए चैनल को onSaveInstanceState तक हुक करना चाहता हूं कि सब कुछ उस परिदृश्य में इरादा के अनुसार काम करता है। यदि आपके पास पहले से ही एक उदाहरण ऐप है जिसमें आप योगदान कर सकते हैं, तो यह बहुत अच्छा होगा।

@ mravn-google कमाल है! मेरे पास ऐप नहीं है क्योंकि मैं सीधे ढांचे को संशोधित कर रहा हूं, लेकिन मैं निश्चित रूप से एक नमूना प्रदान कर सकता हूं। बीटीडब्ल्यू मैं सीधे BinaryMessages का उपयोग कर रहा हूं क्योंकि एंड्रॉइड पक्ष पर कोडेक की कोई आवश्यकता नहीं है (यह सिर्फ बाइट्स पास हो गया है), क्या यह ठीक है?

तुम लोग कमाल के हो।

@Takhion BinaryMessages का सीधा उपयोग ठीक है, अगर आपको कोडेक की कोई आवश्यकता नहीं है। मैं एक जोड़ रहा हूँ

void setSynchronousMessageHandler(String channel, ByteData handler(ByteData message))

उस वर्ग को।

@Takhion स्ट्राइक handler को लागू करने के लिए डार्ट वीएम में सिर्फ सिंक्रोनस कॉल नहीं कर सकते। तो BinaryMessages अपरिवर्तित रहेगा। इसके बजाय, हमेशा की तरह, डार्ट कोड के दृष्टिकोण से सब कुछ async होगा। परिवर्तन BinaryMessenger और इसके कार्यान्वयन को प्लेटफॉर्म पर किया जाएगा। मैं जोड़ूंगा

ByteBuffer sendSynchronous(String channel, ByteBuffer message);

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

@ mravn-google मेरे लिए काम करता है, क्योंकि यह हमें डार्ट की ओर से डेटा वापस भेजने से नहीं रोकता है, भले ही यह एक async कॉल हो: +1:
मुझे लगता है कि डार्ट एसिंक्स प्रतिक्रिया में Future.value(...) का उपयोग करने पर कोई अनुकूलन नहीं होगा?

@Takhion कृपया https://github.com/flutter/engine/pull/4358 पर एक नज़र डालें

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

आईओएस डेवलपर्स उम्मीद करते हैं कि यह संरक्षण/बहाल करने की प्रक्रिया लगभग स्वचालित हो। मुझे लगता है, यदि आपका लक्ष्य वास्तव में क्रॉस-प्लेटफ़ॉर्म ढांचा बनाना है, तो आपको निश्चित रूप से इसे ध्यान में रखना चाहिए।

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

@Zhuinden उन चीजों के बारे में शिकायत न करें जो अभी भी बीटा में हैं? :)

अन्य सिंक्रोनस एपीआई onLowMemory और onTrimMemory और onConfigurationChanged नहीं जानते हैं कि आईओएस में भी समान एपीआई या तंत्र हैं या नहीं

हम फ़्लटर पर त्रुटिपूर्ण एंड्रॉइड सेव एंड रिस्टोरेशन मैकेनिज्म को पुन: पेश नहीं करना चाहते हैं: लेन-देन आकार सीमा के कारण आप पूरे राज्य को बंडल में नहीं सहेज सकते।

एंड्रॉइड पर, आपके पास कई स्टेट सेव/रेस्टोरेशन लॉजिक्स होते हैं:

• डेवलपर का सहेजा गया इंस्टेंसस्टेट, लेकिन आप बड़ी वस्तुओं को अंदर स्टोर नहीं कर सकते, जैसे तत्वों की सूची
• डेटाबेस, जहां आप बड़ी वस्तुओं को स्टोर कर सकते हैं
• अधिकांश विजेट अपने स्वयं के राज्य का प्रबंधन भी करते हैं
• गतिविधि/टुकड़ा ढेर

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

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

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

निचला बिंदु: राज्य को बचाने / बहाल करने के लिए कम बॉयलरप्लेट (नेविगेटर जैसी चीजों के लिए) बनाने के लिए स्पंदन पक्ष में सुधार की गुंजाइश है। लेकिन मुझे नहीं लगता कि इसे प्लेटफॉर्म सेव/रिस्टोर स्टेट को हुक देना चाहिए।

ज़रूर, आप आसानी से स्क्रॉल स्थिति को सहेज नहीं पाएंगे, लेकिन कौन परवाह करता है।

सब लोग? मैं वास्तव में निराश होऊंगा यदि ऐप हर बार अपनी सूची को रीसेट करता है तो मैं गलती से एक अभिविन्यास परिवर्तन को ट्रिगर करता हूं। :पी

@Saketme FWIW, स्पंदन अभिविन्यास परिवर्तन पर स्क्रॉल स्थिति को रीसेट नहीं करता है।

एंड्रॉइड गो डिवाइस पर थोड़े से मल्टीटास्किंग के साथ फ़्लटर ऐप का उपयोग करना मज़ेदार होना चाहिए! हर बार 1GB RAM या उससे कम के दबाव में होने पर प्रगति खो जाती है

@ साकेतमे : जैसा कि @ mravn-google ने कहा, स्पंदन Android गतिविधियों जैसे कॉन्फ़िगरेशन परिवर्तनों के लिए बाध्य नहीं है।
केवल राज्य प्रबंधन की आवश्यकता तब होती है जब पृष्ठभूमि में रहते हुए ओएस द्वारा ऐप को मार दिया जाता है।

@LouisCAD निश्चित रूप से राज्य को बचाने और बहाली महत्वपूर्ण है।
स्पंदन डेवलपर्स पहले से ही इस तर्क को स्वयं लागू कर सकते हैं, और फ़्लटर को शायद इसे कम बॉयलरप्लेट बनाने के तरीके प्रदान करने चाहिए। हालाँकि, Android द्वारा पेश किया गया तंत्र त्रुटिपूर्ण है और हम गतिविधि onSaveInstanceState / onRestoreInstanceState में हैक करने के बजाय फ़्लटर के साथ कुछ बेहतर डिज़ाइन करने का अवसर ले सकते हैं।

इस मुद्दे की वर्तमान स्थिति क्या है?

चैट ऐप के मामले पर विचार करें, जहां मैं TextField में एक लंबा संदेश टाइप कर रहा हूं।
अचानक मुझे एक फोन कॉल आता है और कुछ समय बाद, ओएस कम मेमोरी के कारण चैट ऐप को बंद कर देता है।
फोन कॉल के बाद, मैं चैट ऐप पर वापस आ जाता हूं। क्या स्पंदन स्वचालित रूप से बना रहेगा और मेरे द्वारा लिखे जा रहे संदेश को फिर से बनाएगा? या ऐप को मैन्युअल रूप से इसे जारी रखना और फिर से बनाना है?

स्क्रॉल स्थिति और मार्ग के अलावा, "राज्य" और क्या हैं जिन्हें आमतौर पर डेवलपर्स द्वारा प्रबंधित नहीं किया जाता है?

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

मैं वास्तव में इस पर सोया था और मुझे एहसास हुआ कि स्पंदन देवों के लिए यह पता लगाना वास्तव में काफी आसान है कि आवेदन प्रक्रिया मृत्यु से वापस आया है या पूरी तरह से नया उदाहरण है।

बहुत आसान, जब तक वे savedInstanceState == null (यह मानते हुए कि उन्होंने onSaveInstanceState(bundle) में कम से कम 1 आइटम रखा है)। यदि एक स्थिर बूलियन ध्वज isFirstInit == false और savedInstanceState != null , तो यह प्रक्रिया मृत्यु के बाद है।

फिर वे जटिल स्थिति के लिए किसी भी प्रकार का क्रमांकन/डिसेरिएलाइज़ेशन कॉलबैक बना सकते हैं जिसे savedInstanceState == null पता लगाने पर स्वचालित रूप से साफ़ किया जा सकता है। इस तरह उन्हें केवल कुछ यादृच्छिक बूलियन बनाए रखने की आवश्यकता होती है, लेकिन वे अपनी दृढ़ता प्रणाली का प्रबंधन कर सकते हैं।

बहुत सरल, जब तक वे सहेजे गए इंस्टेंसस्टेट == शून्य की जांच करते हैं (मानते हैं कि उन्होंने कम से कम 1 आइटम ऑनसेव इंस्टेंसस्टेट (बंडल) में रखा है)।

आईओएस पर कोई savedInstanceState और onSaveInstanceState है। लेकिन ऐप अभी भी ओएस द्वारा मारा जा सकता है।

एक सामान्य वर्कफ़्लो पर विचार करें:

• एक उपयोगकर्ता ऐप के अंदर एक विशिष्ट स्क्रीन पर जाता है
• फिर उपयोगकर्ता दूसरे ऐप पर स्विच करता है
• अचानक बुद्धिमान ओएस मेमोरी को संरक्षित करने के लिए पिछले ऐप को मारने का फैसला करता है
• उपयोगकर्ता पिछले ऐप पर लौटता है लेकिन उसे होम स्क्रीन दिखाई देती है। वह स्क्रीन नहीं जो तब खुली थी जब उसने ऐप को स्विच करने का फैसला किया था

तो, स्पंदन में स्क्रीन इतिहास को संरक्षित करने के लिए वर्तमान में अनुशंसित तरीका क्या है?

पीएस बेशक, यह महत्वपूर्ण नहीं है अगर आपके ऐप में सिर्फ एक स्क्रीन है: मुस्कुराओ:

@Zhuinden मैं कई परिदृश्यों को देखने में विफल रहता हूं जहां वैसे भी इसकी आवश्यकता है।

ए) चैट उदाहरण:
टेक्स्ट फ़ील्ड में लिखी गई पिछली सामग्री को हमेशा सहेजें और पुनर्स्थापित करें जो नहीं भेजी गई थी।

बी) लंबा रूप उदाहरण:

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

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

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

@Zhuinden https://github.com/flutter/flutter/issues/6827#issuecomment -335160555 से जीवनचक्र कॉलबैक ने मेरे चैट एप्लिकेशन के लिए काम किया। जब भी ऐप को बैकग्राउंड में स्विच किया जाता है तो मैं हर बार कुछ स्टेट सेव करता हूं। यह भी देखें https://docs.flutter.io/flutter/dart-ui/AppLifecycleState-class.html

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

फ़्लटर के स्टेटलेस विजेट्स ने _already_ UI स्थिति के लिए विजेट्स से बाहर और ऐप में ज़िम्मेदारी माइग्रेट कर दी है, इसलिए UI स्थिति को बनाए रखने/बहाल करने की समस्या को इसके बजाय _app_ स्थिति को बनाए रखने/बहाल करने की समस्या को तेजी से कवर किया गया है। मैं इसे एक अच्छी बात के रूप में देखता हूं, जैसा कि आईओएस और एंड्रॉइड में यूआई और ऐप की स्थिति को अलग-अलग व्यवहार करने के विपरीत है।

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

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

आईओएस दस्तावेज़:
https://developer.apple.com/library/content/featuredarticles/ViewControllerPGforiPhoneOS/PreservingandRestoreingState.html

एंड्रॉइड डॉक्स:
https://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState (android.os.Bundle)
https://developer.android.com/reference/android/app/Activity.html#onRestoreInstanceState (android.os.Bundle)

क्या इस मामले में कोई प्रगति हुई है? मुझे लगता है कि 'फर्स्ट रन' और 'रिस्टोर' प्रोसेस स्टेट के बीच अंतर करने की वास्तविक आवश्यकता है। जब उपयोगकर्ता किसी मारे गए प्रक्रिया पर वापस जाता है तो आप सही स्क्रीन दिखाने के लिए और कैसे प्रोग्राम कर सकते हैं?

@lukaspili आपने लिखा है: "केवल राज्य प्रबंधन की आवश्यकता होती है जब पृष्ठभूमि में रहते हुए ओएस द्वारा ऐप को मार दिया जाता है।"

ठीक है, फिर राउटर स्टैक के बारे में क्या, डिस्क पर भी सहेजें? इसके अलावा मैं t find proper solution to determine that application was restored. Every time when app goes to background I need to save router stack, app data, state to disc? What if I don Redux का उपयोग नहीं करता हूं?

मुझे लगता है कि पहले कदम के रूप में, हमें प्लगइन्स को राज्य को बचाने और पुनर्स्थापित करने की संभावना देनी चाहिए। यहाँ मेरा प्रस्ताव है: #२२३२८

क्या इस मुद्दे पर कोई अपडेट आया है?

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

यहां एक बड़ा मुद्दा है। मेरे पास दो महीने पहले @ मैथ्यू-कैरोल के साथ कुछ आगे था और मुझे पूरा विश्वास है कि यह चल रहा है।

मैंने एक पुस्तकालय बनाना शुरू कर दिया है जो इससे संबंधित है । मैं वास्तव में इसका उपयोग करने की अनुशंसा नहीं करता लेकिन यह केवल डार्ट-कार्यान्वयन का एक विचार है। #6225 ने चीजों को थोड़ा मुश्किल बना दिया।

मैंने देखा है कि Google Ads ऐप, जिसे फ़्लटर के साथ बनाया जा रहा है, गतिविधि के पुनरारंभ होने के बाद नेविगेशन स्थिति को सुरक्षित रखता है। यह जानने के लिए एक अच्छा संदर्भ होगा कि इसे कैसे कार्यान्वित किया जाता है, भले ही यह एक कामकाज हो।

@aletorrado यदि उपयोगकर्ता ने Android/IOS "टास्क मैनेजर" से ऐप को हटा दिया है और बाद में इसे फिर से लॉन्च किया है तो क्या Google Ads ऐप नेविगेशन स्थिति को सुरक्षित रखता है?

@gitspeak नहीं, यह केवल राज्य को संरक्षित करता है यदि गतिविधि स्वचालित रूप से ओएस द्वारा मार दी गई थी (शायद onSaveInstanceState हुक का उपयोग करके)।

@aletorrado तो हाँ, शायद यही एकमात्र तरीका है ...

मैंने वास्तव में Google Ads ऐप में प्रवेश करने की कोशिश की, लेकिन पहली स्क्रीन के बाद किसी भी स्क्रीन पर जाने के लिए आपके पास एक सक्रिय खाता होना चाहिए: DI यह परीक्षण नहीं कर सकता कि यह वास्तव में काम करता है या नहीं

ऐसा होता है। गारंटी. यह अन्य राज्य जैसे स्क्रॉल स्थिति को भी सुरक्षित रखता है।

कुछ भ्रम को स्पष्ट करने के लिए:

• हां, Google Ads ऐप Flutter के साथ लिखा गया है।
• प्रारंभिक गोद लेने वालों में से एक होने के नाते, उन्हें पृष्ठभूमि निष्पादन के लिए कुछ असामान्य करना पड़ा। एप्लिकेशन शुरू होने पर वे अपना मुख्य अलगाव बनाते हैं और बनाए रखते हैं (गतिविधि नहीं)। फिर, वे इस आइसोलेट को बनाए जाने पर फ़्लटर व्यू में पास कर देते हैं।
• जिसे आप "स्टेट कीपिंग" के रूप में देख रहे हैं, वह ऊपर वर्णित कार्यप्रणाली का एक साइड इफेक्ट है। जब आप Google Ads में गतिविधि को समाप्त कर देते हैं, तो Flutter का "UI" समाप्त नहीं होता है। इसे एप्लिकेशन संदर्भ से जुड़ी स्मृति में रखा जाता है। जब गतिविधि को फिर से शुरू किया जाता है, तो यह उसी आइसोलेट और वायोला को लोड करता है, आपको अपना UI वापस मिल जाता है।

हम इस समस्या को हल करने के लिए इस दृष्टिकोण की अनुशंसा नहीं करते हैं क्योंकि यह समस्या का समाधान बिल्कुल नहीं करता है। यदि आवेदन प्रक्रिया समाप्त हो जाती है, तो भी पूरा राज्य खो जाता है। आप सेटिंग > ऐप्स में जाकर इस प्रक्रिया को रोककर Google Ads के साथ इसे आज़मा सकते हैं। यूआई खो जाएगा।

स्थानीय स्तर पर अलग-थलग पड़े राज्य को बचाने का एक तरीका हो सकता है लेकिन इसकी और जांच की जरूरत है क्योंकि हमें यकीन नहीं है कि यह कितना व्यवहार्य/सुरक्षित है।

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

आप सेटिंग > ऐप्स में जाकर इस प्रक्रिया को रोककर Google Ads के साथ इसे आज़मा सकते हैं। यूआई खो जाएगा।

नहीं यह बिल्कुल ठीक है। किसी ऐप को फोर्स स्टॉपिंग करने से राज्य खो जाना चाहिए।

कम स्मृति की स्थिति से समाप्त नहीं किया जाना चाहिए।

किसी भी तरह से, अगर वे डिस्क/बंडल में कुछ भी जारी रखे बिना राज्य को सिंगलटन इन-मेमोरी के रूप में एप्लिकेशन में रखते हैं, तो यह खो जाएगा।

यह शर्म की बात है कि मैं बिना किसी खाते के ऐप का परीक्षण नहीं कर सकता, क्योंकि मैं केवल ऐप के साथ छेड़छाड़ करने के लिए Google Ads खाता नहीं बनाऊंगा। : सोच_चेहरा:

देशी तरीकों में शामिल हों और अपने ऐप की स्थिति को चुनिंदा रूप से सहेजें ताकि आप इसे बाद में पुनर्स्थापित कर सकें।

वास्तव में सबसे अच्छा समाधान डिस्क पर सक्रिय स्थिति को जारी रखना होगा, और एंड्रॉइड मूल पक्ष पर प्रक्रिया मृत्यु का पता लगाना होगा; यदि आप प्रक्रिया की मृत्यु का पता लगाते हैं, तो डिस्क से पुनः लोड करें, अन्यथा इसे साफ़ करें और खरोंच से पुनरारंभ करें।

मैं फ़्लटर के नेविगेटर के बारे में आपको यह बताने के लिए पर्याप्त नहीं जानता कि क्या आप किसी प्रकार के setHistory या setBackstack विधि के साथ नेविगेशन इतिहास का पुनर्निर्माण कर सकते हैं जैसे आप बैकस्टैक या कंडक्टर या ऐसा कुछ करेंगे।

गतिविधियां/टुकड़े इस सामग्री को आंतरिक रूप से ActivityRecord/FragmentRecord के साथ संभालते हैं, इसलिए उनका उससे आगे उल्लेख नहीं किया जाता है।

उन सभी जानकारियों के लिए धन्यवाद @mehmetf। यह सुनकर दुख हुआ कि राज्य को बचाने/बहाल करने के लिए समर्थन लागू होने से बहुत दूर है।

हो सकता है कि flutter_redux कुछ एप्लिकेशन स्थिति को क्रमबद्ध

ठीक है, अगर आप डिस्क पर Redux स्टोर के ब्लॉब को जारी रखते हैं। बस "प्रक्रिया मृत्यु के बाद अनंत लोडिंग संवाद" समस्या से सावधान रहें। : सोच_चेहरा:

कुछ भ्रम को स्पष्ट करने के लिए:

दरअसल, मैं कुछ ज्यादा ही कंफ्यूज हूं..

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

यह मौजूदा मुद्दे से कैसे संबंधित है? क्या डार्ट आइसोलेट्स एक अलग प्रक्रिया में चलते हैं?

जिसे आप "स्टेट कीपिंग" के रूप में देख रहे हैं, वह ऊपर वर्णित कार्यप्रणाली का एक साइड इफेक्ट है। जब आप Google Ads में गतिविधि को समाप्त कर देते हैं, तो Flutter का "UI" समाप्त नहीं होता है। इसे एप्लिकेशन संदर्भ से जुड़ी स्मृति में रखा जाता है। जब गतिविधि को फिर से शुरू किया जाता है, तो यह उसी आइसोलेट और वायोला को लोड करता है, आपको अपना UI वापस मिल जाता है।

मेरी समझ यह है कि @aletorrado ने प्रक्रिया समाप्त होने के बाद "स्टेट कीपिंग" देखी, संभवत: जब ऐप को बैकग्राउंड में ले जाया गया था (एजी होम बटन दबाकर)।

एफवाईआई: जब रनटाइम पर "गतिविधि मर जाती है" तो प्रक्रिया को समाप्त करने के बाद हमेशा ऐसा होता है।

हम इस समस्या को हल करने के लिए इस दृष्टिकोण की अनुशंसा नहीं करते हैं क्योंकि यह समस्या का समाधान बिल्कुल नहीं करता है। यदि आवेदन प्रक्रिया समाप्त हो जाती है, तो भी पूरा राज्य खो जाता है। आप सेटिंग > ऐप्स में जाकर इस प्रक्रिया को रोककर Google Ads के साथ इसे आज़मा सकते हैं। यूआई खो जाएगा।

जैसा कि @Zhuinden ने उल्लेख किया है कि यह एक वैध "स्टेट कीपिंग" परिदृश्य नहीं है, इसलिए "टास्क मैनेजर" से ऐप को हटाने के लिए

स्थानीय स्तर पर अलग-थलग पड़े राज्य को बचाने का एक तरीका हो सकता है लेकिन इसकी और जांच की जरूरत है क्योंकि हमें यकीन नहीं है कि यह कितना व्यवहार्य/सुरक्षित है।

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

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

उन मामलों के लिए राज्य को बनाए रखने के लिए उपयुक्त एंड्रॉइड सुविधा को स्वीकार करने के बजाय कोई समाधान नहीं बताया गया था जहां रन-टाइम प्रक्रिया को समाप्त करने का निर्णय लेता है।

उन मामलों के लिए राज्य को बनाए रखने के लिए उपयुक्त एंड्रॉइड सुविधा को स्वीकार करने के बजाय कोई समाधान नहीं बताया गया था जहां रन-टाइम प्रक्रिया को समाप्त करने का निर्णय लेता है।

मैं थोड़े से वर्णन करता हूं कि हम क्या कर सकते हैं लेकिन मुझे स्पंदन के बारे में पर्याप्त जानकारी नहीं है कि क्या यह इसके लिए आवश्यक है (किसी भी समय मनमाने ढंग से नेविगेशन इतिहास स्थापित करने की क्षमता) का समर्थन करता है।

@Zhuinden onSaveInstanceState द्वारा कवर किए गए "ज़िलियन" एज केस हैं जो गतिविधियों/नियंत्रणों से संबंधित हैं ... इस पर मेरा विश्वास करें ... लेकिन शिक्षा अभ्यास के रूप में जांच करने के लिए आपका स्वागत है।

... और सिर्फ मेरी स्थिति को दोहराने के लिए: एंड्रॉइड टास्क/एक्टिविटीज, सर्विसेज, एप्लिकेशन लाइफ-साइकिल (ऑनसेव इंस्टेंसस्टेट समेत) एंड्रॉइड प्रोग्रामिंग कॉन्ट्रैक्ट का हिस्सा हैं "संयोग से" उन्हें पहली बार जावा में महसूस किया जाता है लेकिन मुख्य बात यह है कि वे हैं ऐप प्रक्रिया पर सिस्टम-स्तरीय बाधाओं को लागू करने के साधन और चूंकि फ़्लटर कोड एक एंड्रॉइड ऐप प्रक्रिया के भीतर रहता है, इसलिए इन बाधाओं को दरकिनार करना फ़्लटर के लिए नासमझी होगी।

प्रिय एंड्रॉइड डेवलपर्स,

न केवल कॉन्फ़िगरेशन परिवर्तनों में बल्कि प्रक्रिया मृत्यु के दौरान भी राज्य को सहेजकर अपने उपयोगकर्ताओं को सर्वश्रेष्ठ उपयोगकर्ता अनुभव प्रदान करने में आपके जुनून के लिए धन्यवाद। आपने ऊपर की 200 टिप्पणियों में पढ़ा होगा कि जब एप्लिकेशन स्थिति को बचाने की बात आती है तो फ़्लटर संघर्ष कर रहा होता है। मैं आपको बताना चाहता हूं कि इसे क्यों और कैसे हल किया जाए ।

मैं onSavedInstanceState उपयोग क्यों नहीं कर सकता?

onSavedInstanceState लिए डेवलपर्स को ऐप स्थिति को सिंक्रोनाइज़ करने की आवश्यकता होती है। आपको तुरंत लौटना होगा। लेकिन फ़्लटर के लिए संचार डिफ़ॉल्ट रूप से अतुल्यकालिक है ( Future )। इसलिए जब Android इसके लिए कहता है तो आप अपने फ़्लटर ऐप से सहेजी गई स्थिति का अनुरोध नहीं कर सकते।
_लेकिन आप सहेजी गई स्थिति को वापस कर सकते हैं यदि आपने इसे पहले ही बना लिया होता, है ना?_

समस्या यह नहीं है कि onSavedInstanceState दुर्गम है, समस्या समय की है। जब Android राज्य को बचाने के लिए कहता है, तो आपको डेटा की आवश्यकता नहीं होती है।

पुनर्प्राप्ति समाधान A: आपकी स्वयं की सहेजी गई इंस्टेंस स्थिति फ़ाइल

आप onSavedInstanceState सुन सकते हैं और इस घटना के बारे में अपने स्पंदन ऐप को सूचित कर सकते हैं। फिर अपनी ऐप स्थिति को सहेजें और इसे file में लिखें। जब आपका ऐप प्रोसेस डेथ से रिकवर हो जाता है (आप इसे एंड्रॉइड साइड पर savedInstanceState जरिए पता लगा सकते हैं) फाइल सिस्टम से फाइल लोड करें, इसे पार्स करें और अपनी स्थिति को रिकवर करें। (संकेत: प्लेटफ़ॉर्म चैनलों का उपयोग करें, वे आपके विचार से कहीं अधिक आसान हैं)।

आप उस स्थिति को भी पुनर्प्राप्त कर सकते हैं जब उपयोगकर्ताओं ने ऐप को मार दिया, या सहेजे गए राज्य को खारिज कर दिया यदि यह बहुत पुराना है!

रिकवरी समाधान बी: ​​लगातार राज्य बचाओ

हम एक टाइमर चला सकते हैं और लगातार ऐप स्टेट को प्लेटफॉर्म साइड पर मेमोरी में सेव कर सकते हैं। मान लें कि हर 3 सेकंड में। जब एंड्रॉइड onSavedInstanceState कॉल करता है तो हम पहले से सहेजी गई स्थिति को वापस कर सकते हैं। (हां, हम पिछले 3 वर्षों में हुए परिवर्तनों को खो सकते हैं)

पुनर्प्राप्ति समाधान C: प्रमुख बिंदुओं पर स्थिति सहेजें

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

सभी 3 समाधान संयुक्त हैं, जो आपके ऐप के लिए सबसे उपयुक्त है उसका उपयोग करें।

लेकिन मैं अपनी ऐप स्थिति को कैसे सहेज सकता हूं?

Android View s के विपरीत, Widget s में onSaveInstanceState कॉलबैक नहीं है। विजेट ट्री स्वचालित रूप से सहेजा नहीं जाता है। और यह अच्छी बात है! यूआई और राज्य अंततः अलग हो गए हैं और दृश्य स्थिति को बहाल करते समय या गतिविधियों और टुकड़ों को तत्काल करते समय कोई प्रतिबिंब जादू नहीं होता है।

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

हमारे प्रिय नमूना काउंटर ऐप को देखते हुए यह बहुत आसान हो सकता है:

// complete app state of sample application
{
  "counter": 24,
}

यदि आपके पास एकाधिक स्क्रीन या संवाद हैं तो आप निम्न ऐप स्टेट जेसन के साथ समाप्त हो सकते हैं:

{
    "currentRoute": "/todo-detail/241",
    "routes": {
        "todo-detail/241": {
            "edited": "true",
            "title": "Buy bananas",
            "picture": "http://....",
            "show_confirm_delete_dialog": "false"
        },
        "todo-list": {
            "current_scroll_position": "365",
            "filter": "Filter.TODAY"
        }
    }
}

वास्तविक कार्यान्वयन आपके ऐप आर्किटेक्चर पर बहुत अधिक निर्भर करता है।

• यदि आप Redux का उपयोग कर रहे हैं तो आप वैश्विक ऐप स्थिति को फ्लाई पर जारी रखने के लिए एक मिडलवेयर का उपयोग कर सकते हैं।
• यदि आप scoped_model का उपयोग कर रहे हैं तो यह मॉडल को बचाने के लिए पर्याप्त हो सकता है। उन्हें फिर से बनाना एक Redux राज्य को फिर से बनाने की तुलना में मौलिक रूप से अलग है।

सबसे अच्छी युक्तियाँ जो मैं आपको दे सकता हूँ:

• अपने UI और अपने मॉडलों को कड़ाई से अलग रखें।
• प्रत्येक स्क्रीन को देखें, और अपने आप से पूछें कि राज्य को पुनर्प्राप्त करने के लिए आपको वास्तव में क्या चाहिए। ज्यादातर समय यह वास्तव में ज्यादा नहीं होता है।
• अपने आईओएस colleagues और वे आपको बताएंगे कि उन्होंने वर्षों में encodeRestorableState माध्यम से राज्य बहाली को लागू नहीं किया है। Android 1M+ बनाम iOS 974

पास्कल

"गतिविधि न रखें" सेटिंग चालू करें।

नहीं, यह प्रक्रिया मृत्यु के विरुद्ध ठीक से परीक्षण नहीं करता है। ऐसा तब तक नहीं होता जब तक आप उस सेटिंग को स्पष्ट रूप से सक्षम नहीं करते। मैं

यदि आपके पास एकाधिक स्क्रीन या संवाद हैं तो आप निम्न ऐप स्टेट जेसन के साथ समाप्त हो सकते हैं:

{
  "currentRoute": "/todo-detail/241",
  "routes": {
      "todo-detail/241": {
          "edited": "true",
          "title": "Buy bananas",
          "picture": "http://....",
          "show_confirm_delete_dialog": "false"
      },
      "todo-list": {
          "current_scroll_position": "365",
          "filter": "Filter.TODAY"
      }
  }
 }

ओह बॉय, हम काम करने के लिए "नेविगेशन राज्य एक सीमित राज्य मशीन की स्थिति के रूप में आवेदन राज्य का हिस्सा है" तक पहुंच रहे हैं, लेकिन मुझे जिस तरह से दिखता है वह मुझे पसंद है

ओह बॉय, हम काम करने के लिए "नेविगेशन राज्य एक परिमित राज्य मशीन की स्थिति के रूप में आवेदन राज्य का हिस्सा है" तक पहुंच रहे हैं

मुझे शुरू मत करो।

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

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

और वह कुंजी है! (साथ ही "एंड्रॉइड सेवा" समर्थन)

@gitspeak , पिछले एक्सचेंज का इस मुद्दे से हमारा कोई लेना-देना नहीं था। मैं दोनों को छिपा दूंगा। यदि आप चर्चा जारी रखना चाहते हैं, तो कृपया मेरे जीथब हैंडल @ gmail.com का उपयोग करके मुझे पीएम करें। यहाँ स्पष्ट रूप से एक ग़लतफ़हमी है जो इस मुद्दे के दायरे से बाहर है।

फ़्लटर और एंड्रॉइड के बीच इंटरफेस पर काम करने वाले डेवलपर्स में से एक के रूप में, मैं राज्य को बचाने से जुड़े मुद्दों का एक अच्छा अवलोकन प्रदान करने के लिए

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

यदि आप में से कोई भी उस विशेष उपयोग-मामले का वर्णन करना चाहता है जिसे आपके ऐप को बचत राज्य के संबंध में समर्थन करने की आवश्यकता है, तो कृपया बेझिझक मुझे [email protected] पर ईमेल करें - मैं सक्रिय रूप से उपयोग-मामलों को

@passsy कृपया नीचे दी गई मेरी टिप्पणियों को रचनात्मक प्रतिक्रिया प्रदान करने के एक ईमानदार प्रयास के रूप में देखें

पुनर्प्राप्ति समाधान A: आपकी स्वयं की सहेजी गई इंस्टेंस स्थिति फ़ाइल
आप onSavedInstanceState को सुन सकते हैं और इस घटना के बारे में अपने स्पंदन ऐप को सूचित कर सकते हैं। फिर अपने ऐप की स्थिति को सेव करें और इसे एक फाइल में लिखें। जब आपका ऐप प्रोसेस डेथ से रिकवर हो जाता है (आप एंड्रॉइड साइड पर सेव्ड इंस्टेंसस्टेट के माध्यम से इसका पता लगा सकते हैं) फाइल सिस्टम से फाइल लोड करें, इसे पार्स करें और अपना स्टेट रिकवर करें। (संकेत: प्लेटफ़ॉर्म चैनलों का उपयोग करें, वे आपके विचार से कहीं अधिक आसान हैं)।
आप उस स्थिति को भी पुनर्प्राप्त कर सकते हैं जब उपयोगकर्ताओं ने ऐप को मार दिया, या सहेजे गए राज्य को खारिज कर दिया यदि यह बहुत पुराना है!

कई मुद्दों:

1) इस दृष्टिकोण के साथ एक अंतर्निहित नस्ल-स्थिति है। "स्टेट परसिस्टेंस" थ्रेड एंड्रॉइड ऐप मेन थ्रेड से बहुत अच्छी तरह से आगे निकल सकता है जो जीवन-चक्र की घटनाओं को आमंत्रित करता है, इस स्थिति में, फ़ाइल को लिखे जाने के दौरान प्रक्रिया को समाप्त किया जा सकता है। आप "स्टेट सेविंग" थ्रेड से एक पूर्णता संकेत पर एक जीवन-चक्र विधि में अवरुद्ध करके दो थ्रेड्स को समन्वयित करने का प्रयास कर सकते हैं, लेकिन अतिरिक्त सिंक्रनाइज़ेशन जटिलता को पेश करने के शीर्ष पर, शुद्धता का आश्वासन नहीं दे सकता है क्योंकि लंबे समय तक देरी से ANR शुरू हो सकता है। (https://developer.android.com/topic/performance/vitals/anr)
आप तर्क दे सकते हैं कि फाइल करने के लिए "स्टेट सेविंग" इतनी जल्दी है कि ऐसा होने की संभावना नहीं है, लेकिन थ्रेड शेड्यूलिंग और स्टोरेज लेटेंसी में वास्तविक देरी पर विचार करें, जबकि अन्य प्रक्रियाएं चल रही हैं जैसे कि बैकग्राउंड डाउनलोड, प्ले स्टोर अपडेट, मीडिया प्लेयर, आदि ... मैं हूं इस पर बहस करने में नहीं, लेकिन मेरा व्यक्तिगत अनुभव (दूसरों द्वारा साझा किया गया) यह है कि स्पष्ट रूप से एंड्रॉइड डिवाइस विंडोज पीसी को संक्रमित करने वाले "फ्लू" से प्रतिरक्षा नहीं हैं - वे समय के साथ धीमे भी हो जाते हैं। मैंने अभी हाल ही में अपने नेक्सस 7 को साफ किया और वाईफाई पर सभी ऐप्स को डाउनलोड और इंस्टॉल करने में न केवल HOURS लग गए, बल्कि डिवाइस की प्रतिक्रिया अब यह इंगित करने के लिए एक पूर्ण मजाक है जहां मुझे व्यंजनों को देखने के लिए भी धैर्य रखने का संदेह है।

2) आपके पास "बहुत पुराना तरीका" की विश्वसनीय परिभाषा नहीं हो सकती है। यदि मैं कार्य प्रबंधक से ऐप को त्याग देता हूं, तो मुझे उम्मीद है कि सभी राज्य तुरंत गायब हो जाएंगे, जबकि अगर मैं किसी अन्य ऐप पर स्विच करता हूं तो मुझे उम्मीद है कि जब तक फोन चालू है, तब तक राज्य अनिश्चित काल तक संरक्षित रहेगा। बिंदु होने के नाते, एंड्रॉइड आपको इन दो राज्यों के बीच अंतर करने का एक तरीका प्रदान नहीं करता है।

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

रिकवरी समाधान बी: ​​लगातार राज्य बचाओ
हम एक टाइमर चला सकते हैं और लगातार ऐप स्टेट को प्लेटफॉर्म साइड पर मेमोरी में सेव कर सकते हैं। मान लें कि हर 3 सेकंड में। जब Android तब SavedInstanceState पर कॉल करता है, तो हम पहले से सहेजी गई स्थिति को वापस कर सकते हैं। (हां, हम पिछले 3 वर्षों में हुए परिवर्तनों को खो सकते हैं)

बहुत असहमत, "समाधान ए" के आसपास के समान मुद्दों के अलावा, यह डेटा डुप्लिकेशन वर्म्स के एक कैन को खोलने का एक नया जोखिम जोड़ता है।

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

"समाधान ए" के आस-पास समान समस्याएं हैं।

विजेट ट्री स्वचालित रूप से सहेजा नहीं जाता है। और यह अच्छी बात है! यूआई और राज्य अंततः अलग हो गए हैं और दृश्य स्थिति को बहाल करते समय या गतिविधियों और टुकड़ों को तत्काल करते समय कोई प्रतिबिंब जादू नहीं होता है।

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

उपयुक्त ताले का उपयोग करते समय "समाधान ए" मेरे लिए पूरी तरह से व्यावहारिक लगता है, और यदि काम की मात्रा उचित है तो कोई एएनआर ट्रिगर नहीं किया जाना चाहिए। साथ ही, प्लेटफॉर्म के नोटिफिकेशन मैकेनिज्म को अपनाने से यह हर समय अनावश्यक क्रमांकन कार्य करने से बचता है, जो कि हर एक कीस्ट्रोक के लिए करना महंगा हो सकता है।

इस व्यवहार को स्वचालित करने की संभावना के बारे में, मुझे यह स्पष्ट लगता है कि डार्ट रनटाइम में कोई प्रतिबिंब तंत्र नहीं है, और स्पंदन में स्मृति में राज्य को संग्रहीत करने का कोई संरचित तरीका नहीं है, यह किसी भी तरह से संभव नहीं है। फिलहाल, मैं ऐसा करने के बारे में सोच सकता हूं कि सबसे आसान तरीका राज्य को एक गतिशील वस्तु में रखने के लिए ऑप्ट-इन करना होगा (जैसे this.props और this.state रिएक्ट पर)।

@aletorrado

उपयुक्त ताले का उपयोग करते समय "समाधान ए" मेरे लिए पूरी तरह से व्यावहारिक लगता है, और यदि काम की मात्रा उचित है तो कोई एएनआर ट्रिगर नहीं किया जाना चाहिए।

मैं सहमत हूं। जब ... जहां एंड्रॉइड मॉडल कहीं अधिक सरल और मजबूत है क्योंकि इसमें डेवलपर को ताले से निपटने की आवश्यकता नहीं होती है, यह डिस्क पर क्षणिक स्थिति को कायम नहीं रखता है और यह केवल उन मामलों के लिए राज्य को बरकरार रखता है जहां यह प्रासंगिक है जो आप (फड़फड़ाहट) Android जीवनचक्र की घटनाओं और onSaveInstance सुविधा में शामिल हुए बिना नहीं कर सकता - शुरू करने के लिए, तो यह किसके लिए अच्छा है?

साथ ही, प्लेटफॉर्म के नोटिफिकेशन मैकेनिज्म को अपनाने से यह हर समय अनावश्यक क्रमांकन कार्य करने से बचता है, जो कि हर एक कीस्ट्रोक के लिए करना महंगा हो सकता है।

प्रत्येक कुंजी स्ट्रोक को जारी रखने की कोई आवश्यकता नहीं है, बल्कि चयनित राज्यों से युक्त एक स्नैपशॉट है

बचने के लिए डेटा को केवल बाइटएरे के रूप में बंडल में संग्रहीत किया जाना चाहिए
मुख्य थ्रेड पर I/O के कारण किसी भी ANR या अंतराल को ट्रिगर करना।

बुधवार को, दिसंबर 19, 2018, 6:08 अपराह्न एलेजांद्रो टोराडो नोटिफिकेशन @github.com
लिखा था:

उपयुक्त का उपयोग करते समय "समाधान ए" मेरे लिए पूरी तरह से व्यावहारिक लगता है
यदि कार्य की मात्रा उचित हो तो कोई ANR चालू नहीं होना चाहिए।
साथ ही, प्लेटफॉर्म के नोटिफिकेशन मैकेनिज्म को अपनाकर ऐसा करने से बचता है
अनावश्यक क्रमांकन हर समय काम करता है, जो करना महंगा हो सकता है
हर एक कीस्ट्रोक के लिए।

इस व्यवहार को स्वचालित करने की संभावना के बारे में, मुझे यह स्पष्ट लगता है कि
डार्ट रनटाइम में कोई प्रतिबिंब तंत्र नहीं होना, और नहीं होना
स्पंदन में स्मृति में राज्य को संग्रहीत करने का संरचित तरीका, यह संभव नहीं है
किसी भी तरह से। फिलहाल, सबसे आसान तरीका जो मैं करने के बारे में सोच सकता हूं
यह राज्य को एक गतिशील वस्तु में रखने के लिए ऑप्ट-इन करना होगा (जैसे
this.props और this.state ऑन रिएक्ट)।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/flutter/flutter/issues/6827#issuecomment-448671264 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AGpvBUQk17YOsjLMHTWcdJHL9rR71u6lks5u6nKGgaJpZM4KwSuX
.

असली चालबाजी इस बाइटएरे का निर्माण कर रही है जिसके बारे में आप बात करते हैं: थोड़ा_मुस्कुराते हुए_फेस:

मैं इसके बजाय कहूंगा कि असली चालबाजी इसे बहाल करने में सक्षम होना है
बाइटअरे ठीक से।

बुधवार, 19 दिसंबर, 2018 को शाम 6:41 बजे गैबर वरदी नोटिफिकेशन @github.com ने लिखा:

असली चालबाजी इस बाइटएरे का निर्माण कर रही है जिसे आप . कहते हैं

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/flutter/flutter/issues/6827#issuecomment-४४८६८२२२९ ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AGpvBep8AW2xkKECt6uyTjqRGwri9Pmoks5u6npKgaJpZM4KwSuX
.

नहीं। एक बार आपके पास बाइट सरणी हो जाने के बाद, यह बहुत आसान है। जब आप इसे लोड कर रहे हों तो बस एक लोडिंग संकेतक दिखाएं (मान लें कि आपने चैनलों के साथ खुद को बताया है कि आपको इसे लोड करने की आवश्यकता है)।

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

इस समस्या के कारण, फ़्लटर ऐप्स Android में ठीक से एकीकृत नहीं हो सकते क्योंकि
जब रैम का दबाव होता है और उपयोगकर्ता स्विच करता है तो वे सही ढंग से व्यवहार नहीं करते हैं
वापस आने से पहले इन स्थितियों में ऐप्स।

गुरु, 20 दिसंबर, 2018 को 2:42 पूर्वाह्न गैबर वरदी नोटिफिकेशन @github.com ने लिखा:

नहीं। एक बार आपके पास बाइट सरणी हो जाने के बाद, यह बहुत आसान है। बस एक लोडिंग दिखाओ
संकेतक जब आप इसे लोड कर रहे हों (यह मानते हुए कि आपने खुद को बताया है)
चैनल जिन्हें आपको इसे लोड करने की आवश्यकता है)।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/flutter/flutter/issues/6827#issuecomment-448827537 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AGpvBR4rmSxelodAjZvcQ6kOwPd7yxKPks5u6ushgaJpZM4KwSuX
.

हम में से एक समूह ने यहां इस पर कुछ और चर्चा की: https://github.com/mehmetf/flutter/issues/1। इस मुद्दे पर प्रासंगिक बिंदु:

• ठीक करने के लिए (https://github.com/flutter/flutter/issues/6827#issuecomment-447488177): "डोन्ट कीप एक्टिविटीज" को चालू करके Google Ads का परीक्षण किया गया। उस स्थिति में ऐप प्रक्रिया समाप्त नहीं होती है, इसलिए मेरी व्याख्या (https://github.com/flutter/flutter/issues/6827#issuecomment-447955562) पर है। जैसा कि @gitspeak और @Zhuinden ने बताया है, यह उन परिदृश्यों का परीक्षण करने का एक अच्छा तरीका नहीं है

• जब भी एप्लिकेशन को बैकग्राउंड किया जाता है, तो पदानुक्रम में प्रत्येक दृश्य के लिए UI थ्रेड पर View.onSaveInstanceState को कॉल किया जाता है, जिसमें सेव इनेबल होता है। तो, डेवलपर के दृष्टिकोण से एक अच्छा समाधान इसे लागू करने के लिए FlutterView लिए होगा। यूआई थ्रेड के साथ दौड़ की स्थिति को रोकने के लिए (जिसे आप ब्लॉक नहीं कर सकते/नहीं कर सकते), इस विधि को फ़्लटर एप्लिकेशन तक नहीं पहुंचना चाहिए क्योंकि ऐसा करने का कोई सिंक्रोनस तरीका नहीं है।

• जो कुछ भी onSaveInstanceState सहेजता है वह 1MB से बड़ा नहीं हो सकता है इसलिए संपूर्ण पृथक राज्य को सहेजना प्रश्न से बाहर है। इसके बजाय, हम संभवतः कोड, संपत्ति और डेटा को विभाजित करने के तरीके के साथ आ सकते हैं जो अलग मेमोरी में निहित है और केवल डेटा भाग को पार्सल में क्रमबद्ध किया गया है।

• जब दृश्य को बाद में पुनर्स्थापित किया जाता है, तो FlutterView एक पृथक बनाता है और यदि कोई हो, तो पहले से सहेजे गए डेटा भाग को अनपैक करता है।

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

• मुझे लगता है कि जब भारत जैसे उभरते बाजारों की बात आती है तो यह एक और अधिक दबाव वाला मुद्दा होगा जहां फ़्लटर के कम-अंत वाले फोन पर चलने की उम्मीद है। Android Go में कहीं अधिक आक्रामक मेमोरी प्रबंधन रणनीति होने की भी अफवाह है।

• जब _application_ शुरू होता है (गतिविधि नहीं) तो वे अपना मुख्य आइसोलेट बनाते और बनाए रखते हैं। फिर, वे इस आइसोलेट को बनाए जाने पर फ़्लटर व्यू में पास कर देते हैं।

क्या आप इस कोड का एक उदाहरण प्रदान कर सकते हैं?

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

क्या आप इस कोड का एक उदाहरण प्रदान कर सकते हैं?

मैं एक कॉपी/पेस्ट प्रकार का उदाहरण प्रदान नहीं कर सकता लेकिन यहाँ क्या हो रहा है:

आवेदन

• अपने Application.onCreate , FlutterMain लिए इनिशियलाइज़ेशन फ़ंक्शंस को कॉल करें। ( startInitialization और ensureInitializationComplete )। आप स्पंदन/इंजन रेपो में इनके संदर्भ पा सकते हैं।
• एक नया FlutterNativeView ऑब्जेक्ट बनाएं, एप्लिकेशन इंस्टेंस में संदर्भ के रूप में पास करें।
• इस मूल दृश्य में अपना बंडल चलाएं ( runFromBundle उदाहरण देखें)।
• इस एप्लिकेशन में एक इंटरफ़ेस लागू करें जो आपको इस मूल दृश्य को वापस करने देता है ( FlutterNativeViewProvider जैसा कुछ)।

गतिविधि

• FlutterFragmentActivity बढ़ाएँ और इन दो विधियों को ओवरराइड करें:

  <strong i="26">@Override</strong>
  public FlutterNativeView createFlutterNativeView() {
    FlutterNativeViewProvider provider = (FlutterNativeViewProvider) getApplication();
    return provider.getFlutterNativeView();
  }

  <strong i="27">@Override</strong>
  public boolean retainFlutterNativeView() {
    return true;
  }

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

अस्वीकरण

1. जैसा कि मैंने ऊपर उल्लेख किया है, हम इस पैटर्न की पूरी तरह से निंदा नहीं करते हैं क्योंकि यह वास्तव में इस विशेष समस्या को हल नहीं करता है और यह काफी गड़बड़ है।

2. ध्यान दें कि इनमें से कई एपीआई बदलने के लिए तैयार हैं। चूंकि add2app उपयोग के मामले अभी भी विकसित हो रहे हैं, Android और iOS एम्बेडिंग API अभी तक काफी स्थिर नहीं हैं। हम हमेशा की तरह फ़्लटर-देव@ पर ब्रेकिंग बदलावों की घोषणा करेंगे।

@पाससी , @gitspeak

पुनर्प्राप्ति समाधान A: आपकी स्वयं की सहेजी गई इंस्टेंस स्थिति फ़ाइल

यह सुनिश्चित करने के लिए कि आपके पास एक वैध राज्य-फ़ाइल है, आप एक .tmp फ़ाइल में लिख सकते हैं और फिर लेखन पूरा होने पर नाम बदल सकते हैं। यदि आप पिछली राज्य फ़ाइल भी रखते हैं, तो आप हमेशा वैध स्थिति के साथ समाप्त हो जाएंगे। साथ ही जब राज्य को बचाते हुए प्रक्रिया को मार दिया जाता है।

@jsroest

आप हमेशा वैध स्थिति के साथ समाप्त होंगे।

लेकिन जरूरी नहीं कि सही स्थिति हो, जो पूरी बात की तरह हो..

गैर-वाष्पशील स्मृति के साथ शुरू करने के लिए राज्य को जारी रखने की भी कोई आवश्यकता नहीं है ..

@gitspeak

आप हमेशा वैध स्थिति के साथ समाप्त होंगे।

लेकिन जरूरी नहीं कि सही स्थिति हो, जो पूरी बात की तरह हो..

गैर-वाष्पशील स्मृति के साथ शुरू करने के लिए राज्य को जारी रखने की भी कोई आवश्यकता नहीं है ..

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

गैर-वाष्पशील स्मृति को बनाए रखने के कुछ फायदे हैं; प्रक्रिया 'फोन ड्रॉप्स', बैटरी परिवर्तन, हार्डवेयर विफलताओं, ओएस अपडेट, सामान्य रूप से रीबूट आदि पर भी मार दी जाती है, इसलिए गैर-वाष्पशील स्मृति में सहेजे जाने पर राज्य जारी रहता है।

@jsroest आपके तर्क मान्य हैं लेकिन क्षणिक यूआई स्थिति (उदाहरण के लिए स्क्रॉल स्थिति, सक्रिय चयन), अस्थायी टेक्स्ट इनपुट, आदि ...) ध्यान रखें कि इस प्रकार के डेटा को पुनर्स्थापित करना केवल उन स्थितियों में आवश्यक है जहां उपयोगकर्ता ने "स्क्रीन" को स्पष्ट रूप से त्याग दिया नहीं है, लेकिन उपयोगकर्ता-इनपुट अभी भी खो सकता है, जैसे कि जब कोई उपयोगकर्ता किसी अन्य ऐप पर स्विच करता है। बिजली-नुकसान पर क्षणिक स्थिति को पुनर्प्राप्त करने के लिए कोई उपयोगकर्ता-उम्मीद नहीं है, जैसे कि कोई उपयोगकर्ता अपेक्षा नहीं है कि ब्राउज़र सिस्टम पावर लॉस से पहले अंतिम प्रदर्शित वेबपेज को सटीक ऑफसेट पर स्क्रॉल करेगा। बिंदु होने के नाते, "क्षणिक स्थिति" माने जाने वाले डेटा की प्रकृति महत्वपूर्ण है और यहां चर्चा (विशेष रूप से Android onSaveInsatnceState सुविधा) उस प्रकार के डेटा को संभालने के बारे में है।

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

@jsroest

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

क्षमा करें, मुझे नहीं पता कि ऐसे ग्राहकों के लिए एप्लिकेशन कैसे बनाएं, शायद कोई और मदद कर सकता है ...

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

आगे पढ़ने की सिफारिश की:

https://developer.android.com/topic/libraries/ आर्किटेक्चर/सेविंग-स्टेट्स [उदाहरण के लिए ध्यान दें कि यह लेख स्थानीय स्टोरेज को onSaveInstanceState से कैसे अलग करता है]
https://developer.android.com/guide/topics/data/data-storage
https://firebase.google.com/docs/firestore/

@jsroest यदि आपके ग्राहक ऐप से वापस लौटने की अपेक्षा करते हैं, भले ही इसे बलपूर्वक रोक दिया गया हो, कार्य-साफ़ किया गया हो या ओएस को पुनरारंभ किया गया हो , तो यह पूरी तरह से कस्टम है, न कि लोग यहां किस बारे में बात कर रहे हैं।

onSaveInstanceState किसी दिए गए कार्य के लिए कार्य स्थिति को सहेज रहा था, लेकिन इसे टास्क क्लियर या फोर्स स्टॉप या OS रिबूट पर छोड़ दिया गया था।

@mehmetf मुझे लगता है कि यह मुद्दा वास्तव में वर्बोसिटी के स्तर पर पहुंच गया है, जिस पर इसे @LouisCAD आशीर्वाद के साथ, मेरा सुझाव है कि आप इस मुद्दे को बंद कर दें और एक नया खोलें जो आपके सबसे हालिया सारांश (शायद कुछ हद तक समस्या कथन और दायरे पर जोर देने के लिए अनुकूलित) के साथ-साथ पिछली चर्चाओं के संदर्भों के साथ शुरू होता है।

मैं सहमत हूं लेकिन मैं इसे @ मैथ्यू-कैरोल तक छोड़ दूंगा; वह संभवतः इस मुद्दे का स्वामी होगा।

प्रतिपुष्टि के लिए धन्यवाद।

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

मेरे कार्यक्रमों में आमतौर पर निम्नलिखित भाग होते हैं:

• जब उपयोगकर्ता काम पूरा कर लेता है तो स्थिर स्थिति से डेटा पुश करने के लिए बैकएंड।
• स्थिर स्थिति के लिए स्थानीय sqlite डेटाबेस
• मेमोरी डेटा-स्ट्रक्चर में क्षणिक अवस्था के लिए 'वेरिएबल' कहा जाता है जिसे गैर-वाष्पशील मेमोरी में क्रमबद्ध किया जा सकता है ताकि यह प्रक्रिया को आगे बढ़ा सके।

'चर' डेटा-स्ट्रक्चर में केवल सरल वर्ग होते हैं जो गुणों के साथ क्रमबद्ध होते हैं। इस 'चर' डेटास्ट्रक्चर का एक महत्वपूर्ण हिस्सा स्क्रीनस्टैक है। (बस सूची) जो स्क्रीन सबसे ऊपर है, वह आखिरी स्क्रीन है जिसके साथ उपयोगकर्ता ने इंटरैक्ट किया। नीचे वह है जिसे उपयोगकर्ता 'बैक' दबाते समय नेविगेट करता है।

मैं कल्पना कर सकता हूं कि इस डेटास्ट्रक्चर के क्रमबद्धता को ट्रिगर करने के लिए एंड्रॉइड प्लेटफॉर्म पर OnSaveInstanceState का उपयोग किया जा सकता है। कुछ इसी तरह के अन्य प्लेटफार्मों (आईओएस, भविष्य: जीत, मैक, वेब) पर पाया जाना है, लेकिन जैसा कि @passy ने सुझाव दिया है कि अन्य प्रमुख बिंदु भी इसे ट्रिगर कर सकते हैं और यह काफी अच्छा हो सकता है।

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

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

नमूना आवेदन, जहां SXXX एक संख्या के साथ एक स्क्रीन के लिए खड़ा है। संख्या का उपयोग केवल प्रोग्रामर को याद दिलाने के लिए किया जाता है कि कौन सी स्क्रीन कमोबेश एक साथ हैं।

S100 Main menu
  S200 Order pick
    S210 Select order
      S220 Confirm pick location
        S230 Pick nr of pieces
          S240 Report shortage
        S250 Scan dropoff location
    S300 Cycle count
      S210 XXXXXX
        S220 XXXXXX
      S230 XXXXXX
    S300 Reprint labels
      S310 XXXXXX

नमूना चर डेटास्ट्रक्चर

Class variables {
    Class AmbientVariables {
        ….
    }

    Class ScreenStack{
        List<string> ScreenStack;
    }

    Class Orderpick {
        int selected_order;
        string comfirmed_location;
        string nr_picked;
        ….
    }

    Class CycleCount {
        ….
    }

    Class ReprintLabels {
        ….
    }
}

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

मुझे एहसास है कि यह स्वचालित रूप से सभी क्षणिक स्थिति को नहीं बचाता है। उदाहरण के लिए, चयनित पाठ, सूचियों की स्थिति, एक विशिष्ट एनीमेशन की स्थिति। लेकिन प्रोग्रामर के रूप में, आप प्रति स्क्रीन तय कर सकते हैं कि सहेजने के लिए क्या आवश्यक है। हालांकि यह वही है जो @LouisCAD रोकने की कोशिश कर रहा है क्योंकि सभी बॉयलरप्लेट कोड की आवश्यकता है।

क्या मुझे एक नया मुद्दा बनाना चाहिए या क्या यह इस धागे में फिट बैठता है?

प्रतिक्रिया के लिए फिर से धन्यवाद, मैं वास्तव में इसकी सराहना करता हूं।

@jsroest विस्तृत स्पष्टीकरण के लिए धन्यवाद। कृपया इसे स्टैक ओवरफ्लो पर स्पंदन टैग के साथ पोस्ट करें। आप अनिवार्य रूप से एक सिफारिश के लिए पूछ रहे हैं कि कैसे अपने मार्गों की संरचना और निर्माण करें और लगातार भंडारण में अंतिम बार देखे गए मार्ग को कैसे बचाएं।

आप सोच सकते हैं कि इस विशेष समस्या को हल करने से आपकी समस्या भी हल हो जाती है लेकिन यह सच नहीं है। अगर आपको समझ में नहीं आता है तो आप मुझे मेरे जीथब हैंडल @ gmail.com पर पीएम कर सकते हैं।

इस मुद्दे पर कोई प्रगति?

@vanlooverenkoen सैद्धांतिक रूप से यदि आप नेविगेटर की रूट सूची और फ़ाइल (और स्टेटफुल विजेट्स की स्थिति) के लिए प्रमुख पदानुक्रम जारी रखते हैं, और इसे साफ़ करें जब एंड्रॉइड मूल पक्ष पर आपको savedInstanceState == null , तो आप संभावित रूप से इसे बना सकते हैं टिकाऊ और बहाल करने योग्य, यह इतना आसान नहीं है।

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

@jsroest @mehmetf @claudiofelber , क्या इस स्टैक ओवरफ्लो प्रश्न का उत्तर इन मुद्दों को संबोधित करता है? https://stackoverflow.com/questions/54015775/what-is-the-best-way-to-pass-data-or-arguments-between-flutter-app-screens/54015932

मैं शुरुआत से इसका पालन कर रहा हूं, लेकिन संदर्भ खो जाने के कारण मुझे संदेशों का एक समूह फिर से पढ़ना पड़ा।

यदि फ़्लटर टीम का मानना ​​​​है कि कम बाढ़ और स्पष्ट योजनाओं के साथ एक नया, ताजा मुद्दा होना चाहिए, तो मुझे इससे कोई समस्या नहीं है और परिणामस्वरूप इसे बंद कर दिया गया है।

मैंने प्रक्रिया समाप्त होने पर ऐप स्थिति को बचाने के लिए एंड्रॉइड और आईओएस तंत्र का लाभ उठाने के लिए नेटिव_स्टेट प्लगइन बनाया है।

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

ताओ ने मुझे अभी-अभी बताया कि पिछली गिरावट के हमारे सर्वेक्षण में यह चौथा सबसे अनुरोधित मुद्दा था। मुझे लगता है कि यहां व्यक्त की गई उपयोगकर्ता इच्छाओं का मिश्रण है (100 से अधिक टिप्पणियों में!)

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

एंड्रॉइड एप्लिकेशन में दो केंद्रीय थीम हैं:

1) प्रोसेस स्टेट मशीन (उर्फ लाइफसाइकिल इवेंट्स)।
2) यूआई टूलकिट।

स्पंदन करता है (2) लेकिन नहीं (1)। इसे दोनों को संबोधित करने की जरूरत है।

3 वर्ष...

त्वरित अद्यतन: मैं वर्तमान में इस समस्या के समाधान तलाशने पर सक्रिय रूप से काम कर रहा हूं।

@goderbauer बस यह सुनिश्चित करने के लिए कि यह केवल एक Android समस्या नहीं है, iOS में समान तंत्र है, हालांकि iOS ऐप्स पर प्रभाव शायद कम है। मैंने एक प्लगइन बनाया है जो ओएस तंत्र के माध्यम से राज्य को बचाने की अनुमति देता है जो देखने के लिए कुछ भी हो सकता है: https://github.com/littlerobots/flutter-native-state

@hvisser आप नेविगेशन स्थिति को सहेजने की अनुशंसा कैसे करते हैं? Flutter के नेविगेटर के पास getRoutes विधि नहीं है।

@hvisser हां, मैं इसे दोनों प्लेटफार्मों के लिए देख रहा हूं (और यह अन्य प्लेटफॉर्म में प्लग करने के लिए पर्याप्त लचीला होना चाहिए)। मैंने यह स्पष्ट करने के लिए प्लेटफ़ॉर्म-एंड्रॉइड लेबल हटा दिया है कि यह एक एंड्रॉइड विशिष्ट समस्या नहीं है।

@hvisser आप नेविगेशन स्थिति को सहेजने की अनुशंसा कैसे करते हैं? Flutter के नेविगेटर के पास getRoutes विधि नहीं है।

@Zhuinden नेविगेटर के पास पहले से ही इसके लिए समर्थन है (हालांकि मुझे नहीं लगता कि यह अच्छी तरह से जाना जाता है)। मेरे पास एक उदाहरण है कि इसे मूल राज्य परियोजना में कैसे स्थापित किया जाए, लेकिन TL; DR

• आप नामित मार्गों का उपयोग कर रहे होंगे
• मार्ग पदानुक्रमित होने चाहिए, उदाहरण के लिए /screen1/screen2 /screen1 पर अनुसरण करता है / पर अनुसरण करता है
• जब आप initialRoutes प्रॉपर्टी सेट करते हैं तो मार्ग नेविगेशन स्टैक पर धकेल दिए जाते हैं और आपके मार्ग इस तरह व्यवस्थित होते हैं
• मैं _थिंक_ आपको GlobalKey के लिए navigatorKey पर MaterialApp लेकिन यह मेरे मामले के लिए विशिष्ट हो सकता है।

इसलिए यदि आप initialRoutes से /screen1/screen2 पर सेट करते हैं और आपने अपने मार्ग सही तरीके से सेटअप किए हैं, तो नेविगेशन बहाल करना भी काम करेगा।

2 सिम कार्ड वाले पुराने उपकरणों पर एक और मामला जब आप देशी youtube पर हवाई जहाज मोड को चालू और बंद करते हैं और स्पंदन ऐप्स #49057 को पुनरारंभ करेंगे
वीडियो मेरे अंक में संलग्न है

स्पंदन डिबग मोड को अक्षम करने का प्रयास करें। यदि डिबग मोड सक्षम है तो ऐप हमेशा पुनरारंभ होता है।

डिबगशोचेक्डमोडबैनर: झूठा,

मैं 2018 जून/जुलाई से स्पंदन में काम कर रहा हूं और मुझे पता चला कि यह 2-3 महीने के बाद एक मुद्दा था। मुझे नहीं पता था कि यह इतना बड़ा मुद्दा बन गया है। मैं एक म्यूजिक प्लेयर ऐप बना रहा था और अगर मैं बैक बटन दबाता, तो फड़फड़ाहट हर राज्य को नष्ट कर देती थी जबकि बैकग्राउंड में म्यूजिक बजता रहता था। इसे वापस हल करने के लिए मैंने यह system_shortcuts लाइब्रेरी बनाई है।
pubspec.yaml में अपने प्रोजेक्ट में प्लगइन जोड़ें _[ उन लोगों के लिए जो शुरुआती हैं :) ]_

dependencies:
  flutter:
    sdk: flutter

  # The following adds the Cupertino Icons font to your application.
  # Use with the CupertinoIcons class for iOS style icons.
  cupertino_icons: ^0.1.2
  system_shortcuts:

मैं हमेशा एक ऐसे वर्कअराउंड का उपयोग मेरे लिए ठीक काम करता है लेकिन इसमें कुछ मुद्दे हैं, जिनका उल्लेख नीचे इस टिप्पणी में किया गया है, लेकिन वे मुझे इतना प्रभावित नहीं करते हैं।

उपयोग -

आप जिस भी विजेट पर हों और बैक बटन दबाएं, आप जानते हैं कि ऐप बंद हो जाएगा (यानी उपयोगकर्ता ऐप छोड़ देता है) इस तरह राज्य वर्ग में विजेट्स बाइंडिंग ऑब्सर्वर मिक्सिन जोड़ें

class _MusicPlayerState extends State<MusicPlayer>
    with WidgetsBindingObserver{
...
}

ऐसा करने के बाद didPopRoute विधि को ओवरराइड करें और

<strong i="21">@override</strong>
  Future<bool> didPopRoute() async {
    await SystemShortcuts.home();
  return true;
  }

_आइए समझें कि यह कैसे काम करता है_:
ऐप चल रहा है >> उपयोगकर्ता बैक बटन दबाता है >> होम बटन दबाया जाता है और बैक बटन नहीं होता है >> ऐप पृष्ठभूमि में जाता है और राज्य किसी भी आईटी को नष्ट नहीं करता है

कार्य नमूना -

_ संपादित करें _
_यह ऐप प्रदाता राज्य प्रबंधन का उपयोग करके लिखा गया है लेकिन ऐप को बंद करने और हाल ही में फिर से खोलने के बाद किसी भी राज्य को प्रबंधित करने के लिए कोई कोड नहीं है। यह सिर्फ वह कोड है जिसे हमने यहां काम करते हुए जोड़ा है।_

मुद्दे -

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

तथ्य यह है कि यह समस्या लगभग साढ़े तीन साल पुरानी है और अभी भी कुछ भी इतना परेशान करने वाला नहीं है।

जाहिरा तौर पर, यह मई 2020 तक काम करने के लिए तैयार है, वर्तमान में निर्धारित मील के पत्थर को देखते हुए… Google I/O के लिए समय पर?

ऊपर hvisser ने इस मुद्दे को हल कर दिया है, अब लोगों को केवल उस कोड को लिखने की जरूरत है जो इसे काम करता है

मैं इसके लिए समाधान प्रदान करने पर प्रगति कर रहा हूं। एक बार ऐसा करने के बाद कोई ऐप इंस्टेंस स्थिति को कैसे पुनर्स्थापित कर पाएगा, इसके शुरुआती पूर्वावलोकन के लिए इस पीआर को देखें: https://github.com/flutter/samples/pull/433।

दुर्भाग्य से, जब तक यह पूरा नहीं हो जाता, तब तक इसमें थोड़ा और समय लगेगा।

फ़्लटर में राज्य की बहाली कैसे करें, इसके विवरण के साथ डिज़ाइन दस्तावेज़ यहाँ उपलब्ध है: http://flutter.dev/go/state-restoration-design

सामान्य राज्य बहाली ढांचे के साथ पीआर जैसा कि ऊपर डिजाइन में उल्लिखित है, पोस्ट किया गया है: https://github.com/flutter/flutter/pull/60375। मैं अभी भी कुछ और परीक्षण कवरेज जोड़ने पर काम कर रहा हूं।

सामान्य राज्य बहाली ढांचा (https://github.com/flutter/flutter/pull/60375) सबमिट कर दिया गया है। अब मैं इसे अपने विजेट्स में एकीकृत करने पर काम कर रहा हूं। स्क्रॉल करने योग्य, टेक्स्ट फ़ील्ड और नेविगेटर के साथ शुरू करने जा रहे हैं।

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

फोन में बैटरी खत्म हो जाने या कर्नेल पैनिक होने या कुछ भी होने पर भी ऐप को रिस्टोर करने का फायदा होता है। मैं आपके SQLite कॉल के आस-पास एक ओओ रैपर बनाने की अनुशंसा करता हूं। डार्ट में SQLite.Net जैसा कुछ नहीं है जो दुर्भाग्य से आपके लिए स्वचालित रूप से करता है।

संपादित करें: यह भी कुछ ऐसा है जो हमने मोबाइल विकास के शुरुआती दिनों में किया था क्योंकि स्मृति इतनी सीमित थी और मेमोरी और डिस्क के बीच चीजों को स्वैप करने के लिए स्क्लाइट एक शानदार तरीका है।

मैं इस मुद्दे को बंद कर रहा हूं क्योंकि सामान्य राज्य बहाली ढांचा (और एंड्रॉइड एम्बेडिंग) उतरा है। शेष कार्य को अलग-अलग मुद्दों में ट्रैक किया जाता है:

• https://github.com/flutter/flutter/issues/62916 - राज्य बहाली ढांचे का उपयोग करने के लिए विगेट्स माइग्रेट करें
• https://github.com/flutter/flutter/issues/62915 - iOS एम्बेडर में स्टेट रिस्टोरेशन सक्षम करें

बहुत बढ़िया!!!!! धन्यवाद स्पंदन!!!