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

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

ऊपर दिए गए उदाहरण के लिए, अगर हमें 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 को इंच में देखें existingWorkPolicy.

वर्क अनुरोधों की चेन बनाते समय, डिपेंडेंट वर्क अनुरोधों को नीतियों को फिर से कोशिश करें, ताकि यह पक्का किया जा सके कि काम हमेशा समय पर पूरा हो. काम के अनुरोध पूरा न होने की वजह से, चेन अधूरी रह सकती है और/या स्थिति अनचाही हो सकती है.

अधिक जानकारी के लिए, रद्द करना और रोकना ऑफ़िस का पता.