चेन बनाने का काम

WorkManager की मदद से, एक-दूसरे पर निर्भर कई टास्क की चेन बनाई जा सकती है और उन्हें सूची में जोड़ा जा सकता है. साथ ही, यह तय किया जा सकता है कि उन्हें किस क्रम में चलाया जाए. यह सुविधा खास तौर पर तब काम आती है, जब आपको किसी खास क्रम में कई टास्क चलाने हों.

काम की चेन बनाने के लिए, WorkManager.beginWith(OneTimeWorkRequest) या WorkManager.beginWith(List<OneTimeWorkRequest>) का इस्तेमाल किया जा सकता है. इनमें से हर एक, WorkContinuation का एक इंस्टेंस दिखाता है.

इसके बाद, WorkContinuation का इस्तेमाल करके, then(OneTimeWorkRequest) या then(List<OneTimeWorkRequest>) की मदद से, डिपेंडेंट OneTimeWorkRequest इंस्टेंस जोड़े जा सकते हैं.

WorkContinuation.then(...) को हर बार शुरू करने पर, WorkContinuation का एक नया इंस्टेंस मिलता है. अगर OneTimeWorkRequest इंस्टेंस का List जोड़ा जाता है, तो ये अनुरोध एक साथ चल सकते हैं.

आखिर में, WorkContinuation.enqueue() तरीके का इस्तेमाल करके, WorkContinuation की चेन को enqueue() किया जा सकता है.

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

WorkManager.getInstance(myContext)
   // Candidates to run in parallel
   .beginWith(listOf(plantName1, plantName2, plantName3))
   // Dependent work (only runs after all previous work in chain)
   .then(cache)
   .then(upload)
   // Call enqueue to kick things off
   .enqueue()

WorkManager.getInstance(myContext)
   // Candidates to run in parallel
   .beginWith(Arrays.asList(plantName1, plantName2, plantName3))
   // Dependent work (only runs after all previous work in chain)
   .then(cache)
   .then(upload)
   // Call enqueue to kick things off
   .enqueue();

इनपुट मर्जर्स

OneTimeWorkRequest इंस्टेंस को चेन करने पर, पैरंट वर्क रिक्वेस्ट का आउटपुट, चिल्ड्रन वर्क रिक्वेस्ट के इनपुट के तौर पर पास किया जाता है. इसलिए, ऊपर दिए गए उदाहरण में, plantName1, plantName2, और plantName3 के आउटपुट, cache अनुरोध के इनपुट के तौर पर पास किए जाएंगे.

एक से ज़्यादा पैरंट वर्क रिक्वेस्ट से मिले इनपुट को मैनेज करने के लिए, WorkManager InputMerger का इस्तेमाल करता है.

WorkManager दो तरह के InputMerger उपलब्ध कराता है:

• OverwritingInputMerger सभी इनपुट की सभी कुंजियों को आउटपुट में जोड़ने की कोशिश करता है. अगर कोई समस्या आती है, तो यह पहले से सेट की गई कुंजियों को ओवरराइट कर देता है.

• ArrayCreatingInputMerger इनपुट को मर्ज करने की कोशिश करता है. साथ ही, ज़रूरत पड़ने पर अरे बनाता है.

अगर आपके पास इस्तेमाल का कोई खास उदाहरण है, तो InputMerger की सब-क्लास बनाकर, अपना कोड लिखा जा सकता है.

OverwritingInputMerger

OverwritingInputMerger, मर्ज करने का डिफ़ॉल्ट तरीका है. अगर मर्ज करने के दौरान, कुंजियों में कोई अंतर होता है, तो आउटपुट डेटा में किसी कुंजी की सबसे नई वैल्यू, पिछले सभी वर्शन को ओवरराइट कर देगी.

उदाहरण के लिए, अगर प्लांट के हर इनपुट में एक ऐसी कुंजी है जो उनके संबंधित वैरिएबल के नामों ("plantName1", "plantName2", और "plantName3") से मेल खाती है, तो cache वर्कर को पास किए गए डेटा में तीन कुंजी-वैल्यू पेयर होंगे.

अगर कोई समस्या आती है, तो सबसे आखिर में काम पूरा करने वाला वर्कर “जीतता है” और उसकी वैल्यू cache को पास कर दी जाती है.

आपके काम के अनुरोध एक साथ चलते हैं. इसलिए, इस बात की कोई गारंटी नहीं है कि वे किस क्रम में चलेंगे. ऊपर दिए गए उदाहरण में, plantName1 में "tulip" या "elm" में से कोई एक वैल्यू हो सकती है. यह इस बात पर निर्भर करता है कि कौनसी वैल्यू आखिर में लिखी गई है. अगर आपको लगता है कि की (कुंजी) में कोई गड़बड़ी हो सकती है और आपको मर्ज किए गए डेटा में सभी आउटपुट डेटा को सुरक्षित रखना है, तो ArrayCreatingInputMerger एक बेहतर विकल्प हो सकता है.

ArrayCreatingInputMerger

ऊपर दिए गए उदाहरण के लिए, मान लें कि हमें पौधे के नाम वाले सभी वर्कर के आउटपुट को सुरक्षित रखना है. इसके लिए, हमें ArrayCreatingInputMerger का इस्तेमाल करना चाहिए.

val cache: OneTimeWorkRequest = OneTimeWorkRequestBuilder<PlantWorker>()
   .setInputMerger(ArrayCreatingInputMerger::class)
   .setConstraints(constraints)
   .build()

OneTimeWorkRequest cache = new OneTimeWorkRequest.Builder(PlantWorker.class)
       .setInputMerger(ArrayCreatingInputMerger.class)
       .setConstraints(constraints)
       .build();

ArrayCreatingInputMerger, हर कुंजी को एक कलेक्शन के साथ जोड़ता है. अगर हर कुंजी यूनीक है, तो आपका नतीजा एक एलिमेंट वाले कलेक्शन की सीरीज़ होगा.

अगर कोई की (कुंजी) आपस में टकराती है, तो उससे जुड़ी वैल्यू को एक कलेक्शन में ग्रुप किया जाता है.

चेनिंग और काम की स्थितियां

OneTimeWorkRequest की चेन, क्रम से तब तक चलती हैं, जब तक उनका काम पूरा नहीं हो जाता. यानी, जब तक वे Result.success() नहीं दिखातीं. काम के अनुरोध, चलने के दौरान फ़ेल हो सकते हैं या रद्द किए जा सकते हैं. इससे, उन पर निर्भर काम के अनुरोधों पर असर पड़ता है.

जब काम के अनुरोधों की चेन में पहला OneTimeWorkRequest सूची में शामिल किया जाता है, तो काम के बाद के सभी अनुरोध तब तक ब्लॉक रहते हैं, जब तक कि काम का पहला अनुरोध पूरा नहीं हो जाता.

सूची में शामिल होने और काम से जुड़ी सभी शर्तें पूरी होने के बाद, काम का पहला अनुरोध शुरू हो जाता है. अगर रूट OneTimeWorkRequest या List<OneTimeWorkRequest> में काम पूरा हो जाता है (यानी कि यह Result.success() दिखाता है), तो डिपेंडेंट वर्क रिक्वेस्ट के अगले सेट को सूची में जोड़ दिया जाएगा.

जब तक हर वर्क रिक्वेस्ट पूरी नहीं हो जाती, तब तक यह पैटर्न आपकी बाकी वर्क रिक्वेस्ट की चेन में चलता रहता है. ऐसा तब तक होता है, जब तक चेन में मौजूद सभी काम पूरे नहीं हो जाते. हालांकि, यह सबसे आसान और अक्सर इस्तेमाल किया जाने वाला तरीका है, लेकिन गड़बड़ी वाले पेज की स्थिति को मैनेज करना भी उतना ही ज़रूरी है.

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

फिर से कोशिश करने की कस्टम रणनीतियों को तय करने के बारे में ज़्यादा जानने के लिए, फिर से कोशिश करने और बैकऑफ़ करने की नीति देखें.

अगर फिर से कोशिश करने की नीति तय नहीं की गई है या खत्म हो गई है या फिर किसी वजह से OneTimeWorkRequest, Result.failure() दिखाता है, तो उस टास्क के अनुरोध और उस पर निर्भर सभी टास्क के अनुरोधों को FAILED. के तौर पर मार्क कर दिया जाता है

OneTimeWorkRequest रद्द होने पर भी यही लॉजिक लागू होता है. इस पर निर्भर काम के किसी भी अनुरोध को भी CANCELLED के तौर पर मार्क किया जाता है और उसे पूरा नहीं किया जाता.

ध्यान दें कि अगर आपने किसी ऐसी चेन में और वर्क रिक्वेस्ट जोड़ी हैं जिसमें वर्क रिक्वेस्ट पूरी नहीं हो पाई हैं या रद्द हो गई हैं, तो आपकी नई जोड़ी गई वर्क रिक्वेस्ट को भी क्रमशः FAILED या CANCELLED के तौर पर मार्क किया जाएगा. अगर आपको किसी मौजूदा चेन के काम को आगे बढ़ाना है, तो ExistingWorkPolicy में APPEND_OR_REPLACE देखें.

काम के अनुरोधों की चेन बनाते समय, एक-दूसरे पर निर्भर काम के अनुरोधों के लिए, फिर से कोशिश करने की नीतियां तय की जानी चाहिए. इससे यह पक्का किया जा सकता है कि काम हमेशा समय पर पूरा हो. काम के अनुरोध पूरे न होने पर, चेन अधूरी रह सकती हैं और/या अनचाही स्थिति पैदा हो सकती है.

ज़्यादा जानकारी के लिए, काम को रद्द करना और रोकना लेख पढ़ें.