ViewModel के अंदर और बाहर बनाए रखें

कुछ बिंदु पर, मैंने समय-समय पर इस बात पर ध्यान दिया कि व्यूमेल वास्तव में Google के वास्तु घटकों से कैसे काम करता है। यह महसूस करते हुए कि मैं खुद समझ नहीं पाया, मैं इंटरनेट पर चढ़ गया और यह जानकर आश्चर्यचकित रह गया कि ViewModel को पकाने के तरीके पर अविश्वसनीय लेखों की एक अविश्वसनीय मात्रा है, LiveData के साथ दोस्त बनाएं, डैगर के माध्यम से पर्ची निर्भरता, RxJava के साथ मुकाबला और उपयोगिता की बदलती डिग्री के अन्य शीर्षक, हालाँकि, लगभग कुछ भी नहीं है कि अंदर क्या चल रहा है। इसलिए मैं इस अंतर को भरने की कोशिश करूंगा।

सावधानी

टीएल; डीआर यदि आप समय के लिए खेद महसूस करते हैं - आउटपुट के लिए नीचे रोल करें, तो आप कम खो देंगे।

तो पहली बात यह है कि आप ध्यान दे सकते हैं कि ViewModel के साथ वास्तु घटकों के 2 अलग-अलग पैकेज हैं, अर्थात्:

1) पुराना android.arch.lifecycle
2) नया androidx.lifecycle

Spoiler : उनके बीच बहुत अंतर नहीं है।

सभी काम चुनौती के पीछे है:

ViewModelProviders.of(activity).get(MyViewModel::class.java) 

चलिए विधि के साथ शुरू करते हैं

  public static ViewModelProvider of(@NonNull FragmentActivity activity) { return of(activity, null); } public static ViewModelProvider of(@NonNull FragmentActivity activity, @Nullable Factory factory) { Application application = checkApplication(activity); if (factory == null) { factory = ViewModelProvider.AndroidViewModelFactory.getInstance(application); } return new ViewModelProvider(ViewModelStores.of(activity), factory); } 

checkApplication सिर्फ नल की जांच करता है, और AndroidViewModelFactory सिर्फ थ्रेड-सेफ सिंगलटन है जो एप्लीकेशन स्टोर करता है। तो वे विशेष रुचि के नहीं हैं, ViewModelStores.of विधि में सबसे दिलचस्प है:

  public static ViewModelStore of(@NonNull FragmentActivity activity) { if (activity instanceof ViewModelStoreOwner) { return ((ViewModelStoreOwner) activity).getViewModelStore(); } return holderFragmentFor(activity).getViewModelStore(); } 

पहली नज़र में, यह अजीब लगता है - अगर यह पहले से ही इसे लागू करता है, तो ViewModelStoreOwner इंटरफ़ेस की उपस्थिति के लिए एक FragmentActivity की जांच क्यों करनी चाहिए? - यह हमेशा ऐसा नहीं था - 2018 के दूर फरवरी तक, जब समर्थन पुस्तकालय संस्करण 27.1.0 जारी किया गया था , तब FragmentActivity ने ViewModelStoreOwner को कभी लागू नहीं किया था। उसी समय, ViewModel ने अपने लिए काम किया।

तो आइए पुराने मामले से शुरू करते हैं - धारक का काम शुरू किया गया था :

  public static HolderFragment holderFragmentFor(FragmentActivity activity) { return sHolderFragmentManager.holderFragmentFor(activity); } 

अगला, बस एक नया धारक टुकड़ा प्राप्त करें या बनाएं:

  HolderFragment holderFragmentFor(FragmentActivity activity) { FragmentManager fm = activity.getSupportFragmentManager(); HolderFragment holder = findHolderFragment(fm); if (holder != null) { return holder; } holder = mNotCommittedActivityHolders.get(activity); if (holder != null) { return holder; } if (!mActivityCallbacksIsAdded) { mActivityCallbacksIsAdded = true; activity.getApplication().registerActivityLifecycleCallbacks(mActivityCallbacks); } holder = createHolderFragment(fm); mNotCommittedActivityHolders.put(activity, holder); return holder; } 

ठीक है, होल्डरफ्रेममेंट ने , निश्चित रूप से, बरकरार रखा

  public HolderFragment() { setRetainInstance(true); } 

वास्तव में, ViewModelStore ऑब्जेक्ट इसमें संग्रहीत है, जो बदले में ViewModel का एक बंडल रखता है:

  public class ViewModelStore { private final HashMap<String, ViewModel> mMap = new HashMap<>(); final void put(String key, ViewModel viewModel) { ViewModel oldViewModel = mMap.put(key, viewModel); if (oldViewModel != null) { oldViewModel.onCleared(); } } final ViewModel get(String key) { return mMap.get(key); } public final void clear() { for (ViewModel vm : mMap.values()) { vm.onCleared(); } mMap.clear(); } } 

केस लाइब्रेरी के 27.1.0 और उच्चतर संस्करण पर वापस जाते हैं। FragmentActivity पहले से ही ViewModelStoreOwner इंटरफ़ेस को लागू करता है, अर्थात यह केवल getViewModelStore विधि को लागू करता है:

  public ViewModelStore getViewModelStore() { if (this.getApplication() == null) { throw new IllegalStateException("Your activity is not yet attached to the Application instance. You can't request ViewModel before onCreate call."); } else { if (this.mViewModelStore == null) { FragmentActivity.NonConfigurationInstances nc = (FragmentActivity.NonConfigurationInstances)this.getLastNonConfigurationInstance(); if (nc != null) { this.mViewModelStore = nc.viewModelStore; } if (this.mViewModelStore == null) { this.mViewModelStore = new ViewModelStore(); } } return this.mViewModelStore; } } 

यहाँ मैं थोड़ा सा सरलीकृत करूँगा - NonConfigurationInstances एक ऐसी वस्तु है जो कॉन्फ़िगरेशन (स्पष्ट रूप से नाम से) पर निर्भर नहीं होनी चाहिए, जो गतिविधि में निहित है और गतिविधि के माध्यम से ActivClientRecord के अंदर और onStop और onDestroy के बीच मनोरंजन के दौरान गतिविधि

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

गतिविधि हमेशा एक दिलचस्प onRetainNonConfigurationInstance विधि होती है। गतिविधि वर्ग में, उन्होंने अनिवार्य रूप से कुछ नहीं किया। सामान्य तौर पर:

  public Object onRetainNonConfigurationInstance() { return null; } 

दस्तावेज़ में विवरण आशाजनक है:

सिस्टम द्वारा कॉल किया जाता है, कॉन्फ़िगरेशन परिवर्तन के कारण किसी गतिविधि को नष्ट करने के भाग के रूप में, जब यह ज्ञात होता है कि नए कॉन्फ़िगरेशन के लिए तुरंत एक नया उदाहरण बनाया जाएगा। आप यहां पर अपनी पसंद की किसी भी वस्तु को वापस ले सकते हैं, जिसमें गतिविधि उदाहरण भी शामिल है, जिसे बाद में नई गतिविधि आवृत्ति में getLastNonConfigurationInstance () कहकर पुनर्प्राप्त किया जा सकता है।

यही है, वहाँ क्या नहीं करना है - यह गतिविधि पुनः प्राप्त करने के बाद getLastNonConfigurationInstance () में क्रॉल करेगा। वास्तु घटकों के डेवलपर्स ने इसका लाभ उठाया। मिनीसस में से - 4 तक एंड्रॉइड काम नहीं करता है, इसे पुराने ज़माने के तरीके से बनाए रखना होगा।

ViewModel की स्पष्ट () विधि को बहुत सरलता से कहा गया था - onDestroy FragmentActivity विधि में।

  protected void onDestroy() { super.onDestroy(); if (this.mViewModelStore != null && !this.isChangingConfigurations()) { this.mViewModelStore.clear(); } this.mFragments.dispatchDestroy(); } 

वास्तव में, Androidx के साथ लगभग सब कुछ समान है, केवल अंतर यह है कि getViewModelStore () विधि अब FragmentActivity में नहीं है, लेकिन ComponentActivity में , जहां से FragmentActivity AndroidX में विरासत में मिली है। केवल कॉल टू क्लियर () विधि बदल गई है; इसे ऑनडेस्ट्रो से एक स्वतंत्र कॉलबैक में हटा दिया गया है, जो कि कंपोनेंटएक्टिविटी कंस्ट्रक्टर में बनाया गया है:

  getLifecycle().addObserver(new GenericLifecycleObserver() { @Override public void onStateChanged(LifecycleOwner source, Lifecycle.Event event) { if (event == Lifecycle.Event.ON_DESTROY) { if (!isChangingConfigurations()) { getViewModelStore().clear(); } } } }); 

प्रोटोकॉल के लिए - लेख के निर्माण के दौरान निम्नलिखित का उपयोग किया गया था:

समर्थन पुस्तकालय 27.0.0, 28.0.0
androidx.lifecycle: lifecycle-viewmodel: 2.0.0
androidx.lifecycle: जीवनचक्र-विस्तार: 2.0.0
android.arch.lifecycle: एक्सटेंशन: 1.1.1
android.arch.lifecycle: viewmodel: 1.1.1

निष्कर्ष:

फरवरी 2018 में दिखाई देने वाले समर्थन पुस्तकालय 27.1.0 तक ViewModel वास्तव में बरकरार टुकड़े में गतिविधि के मनोरंजन से बच गया।
- समर्थन पुस्तकालय संस्करण 27.1.0 से, साथ ही साथ AndroidX ViewModel में, मैं FragmentActivity.NonConfigurationInstances ( ComponentActivity.NonConfigurationInstances in AndroidX) के लिए गतिविधि को फिर से बनाने के लिए प्रतीक्षा करने के लिए गया था, वास्तव में उसी तंत्र के माध्यम से, जो खंडों को बनाए रखता है। , सभी ViewModel को टुकड़ों को बनाए रखने के साथ "बगल में" भेजा जाता है।
- ViewModel का तंत्र AndroidX और समर्थन लाइब्रेरी में लगभग समान है
- अगर आपको अचानक जरूरत पड़े ( हाँ मैं कल्पना नहीं कर सकता कि क्यों) डेटा को खींचें जो गतिविधि के रहते हुए जीना चाहिए, लेकिन मनोरंजन को ध्यान में रखना चाहिए - आप onRetainNonConfigurationInstance () / getLastononConfigurationInstance () का उपयोग कर सकते हैं
- क्या पुराना फैसला, क्या नया एक दस्तावेज हैक और बैसाखी के बीच कुछ की तरह लग रहे हो