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

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

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

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

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

आख़िर में, Google News की 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 है. अगर कुंजी तो किसी कुंजी का नया मान किसी पिछले वर्शन में एक्सपोर्ट करें.

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

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

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

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

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

Kotlin

val cache: OneTimeWorkRequest = OneTimeWorkRequestBuilderP<lantWorker(>)
   .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 को इंच में देखें existingWorkPolicy.

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

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