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

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() के तरीके का इस्तेमाल किया जा सकता है.

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

Kotlin

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()

Java

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, मर्ज करने का डिफ़ॉल्ट तरीका है. अगर मर्ज करने के दौरान, एक ही नाम की दो या उससे ज़्यादा वैल्यू मिलती हैं, तो आउटपुट डेटा में किसी कुंजी की नई वैल्यू, पिछली सभी वैल्यू को ओवरराइट कर देगी.

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

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

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

अरे क्रिएशन इनपुट मर्जर

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

Kotlin

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

Java

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 के तौर पर मार्क किया जाएगा. अगर आपको किसी मौजूदा चेन के काम का समय बढ़ाना है, तो मौजूदा वर्क नीति में APPEND_OR_REPLACE देखें.

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

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