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

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

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

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

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

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

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

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

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

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

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

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

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

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

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