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

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

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

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

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

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