काम से जुड़े अनुरोधों के बारे में बताना

शुरू करने से जुड़ी गाइड में, आसान WorkRequest बनाने और उसे सूची में जोड़ने का तरीका बताया गया है.

इस गाइड में, आपको WorkRequest ऑब्जेक्ट तय करने और उन्हें पसंद के मुताबिक बनाने का तरीका बताया जाएगा. इससे, इस्तेमाल के सामान्य उदाहरणों को मैनेज करने में मदद मिलेगी. जैसे:

• एक बार और बार-बार होने वाले काम शेड्यूल करना
• काम से जुड़ी पाबंदियां सेट करना, जैसे कि वाई-फ़ाई या चार्जिंग की ज़रूरत होना
• काम पूरा होने में कम से कम देरी की गारंटी
• फिर से कोशिश करने और बैक-ऑफ़ की रणनीतियां सेट करना
• इनपुट डेटा को फ़ंक्शन में पास करना
• टैग का इस्तेमाल करके, मिलते-जुलते कामों को एक साथ ग्रुप करना

खास जानकारी

WorkManager में, WorkRequest की मदद से काम तय किया जाता है. WorkManager की मदद से कोई भी काम शेड्यूल करने के लिए, आपको पहले एक WorkRequest ऑब्जेक्ट बनाना होगा और फिर उसे सूची में जोड़ना होगा.

val myWorkRequest = ...
WorkManager.getInstance(myContext).enqueue(myWorkRequest)

WorkRequest myWorkRequest = ...
WorkManager.getInstance(myContext).enqueue(myWorkRequest);

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

WorkRequest खुद एक ऐब्स्ट्रैक्ट बेस क्लास है. इस क्लास के दो टाइप हैं, जिनका इस्तेमाल अनुरोध बनाने के लिए किया जा सकता है. ये टाइप हैं, OneTimeWorkRequest और PeriodicWorkRequest. इनके नाम से पता चलता है कि OneTimeWorkRequest, बार-बार नहीं होने वाले काम को शेड्यूल करने के लिए काम आता है. वहीं, PeriodicWorkRequest, किसी इंटरवल पर बार-बार होने वाले काम को शेड्यूल करने के लिए ज़्यादा सही है.

एक बार होने वाला काम शेड्यूल करना

आसान काम के लिए, स्टैटिक तरीका from का इस्तेमाल करें. इसके लिए, किसी और कॉन्फ़िगरेशन की ज़रूरत नहीं होती है:

val myWorkRequest = OneTimeWorkRequest.from(MyWork::class.java)

WorkRequest myWorkRequest = OneTimeWorkRequest.from(MyWork.class);

ज़्यादा जटिल काम के लिए, बिल्डर का इस्तेमाल किया जा सकता है:

val uploadWorkRequest: WorkRequest =
   OneTimeWorkRequestBuilder<MyWork>()
       // Additional configuration
       .build()

WorkRequest uploadWorkRequest =
   new OneTimeWorkRequest.Builder(MyWork.class)
       // Additional configuration
       .build();

हाई-प्रायाॅरिटी वाला काम शेड्यूल करना

WorkManager 2.7.0 में, हाई-प्रायाॅरिटी वाले काम का कॉन्सेप्ट जोड़ा गया है. इससे, WorkManager को ज़रूरी काम करने में मदद मिलती है. साथ ही, सिस्टम को संसाधनों के ऐक्सेस पर बेहतर कंट्रोल मिलता है.

हाई-प्रायाॅरिटी वाले काम की ये खास बातें हैं:

• ज़रूरी होने की वजह: जल्दी पूरा किए जाने वाले टास्क, उपयोगकर्ता के लिए ज़रूरी होते हैं या उपयोगकर्ता ने उन्हें शुरू किया होता है.
• तेज़ी से: तेज़ी से काम करने की सुविधा, तुरंत शुरू होने वाले और कुछ ही मिनटों में पूरे होने वाले छोटे टास्क के लिए सबसे सही है.
• कोटा: सिस्टम-लेवल का कोटा, फ़ोरग्राउंड में प्रोसेस करने में लगने वाले समय को सीमित करता है. इससे यह तय होता है कि जल्दी से प्रोसेस होने वाला कोई जॉब शुरू किया जा सकता है या नहीं.
• पावर मैनेजमेंट: पावर मैनेजमेंट से जुड़ी पाबंदियों, जैसे कि बैटरी सेवर और डॉज़ मोड से, तेज़ी से काम करने की सुविधा पर कम असर पड़ता है.
• देरी: सिस्टम, जल्दी किए जाने वाले काम को तुरंत पूरा करता है. हालांकि, ऐसा तब ही होता है, जब सिस्टम का मौजूदा वर्कलोड उसे ऐसा करने की अनुमति देता हो. इसका मतलब है कि ये काम, देरी के प्रति संवेदनशील होते हैं और इन्हें बाद में करने के लिए शेड्यूल नहीं किया जा सकता.

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

कोटा

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

किसी ऐप्लिकेशन को प्रोसेस करने में लगने वाला समय, स्टैंडबाय बकेट और प्रोसेस की अहमियत पर निर्भर करता है.

यह तय किया जा सकता है कि जब टास्क पूरा करने के कोटे की वजह से, तेज़ी से पूरी होने वाली किसी टास्क को तुरंत पूरा करने की अनुमति न मिले, तो क्या होगा. ज़्यादा जानकारी के लिए, नीचे दिए गए स्निपेट देखें.

तेज़ी से काम करना

WorkManager 2.7 से, आपका ऐप्लिकेशन setExpedited() को कॉल करके यह एलान कर सकता है कि किसी WorkRequest को तेज़ी से काम करने वाले जॉब का इस्तेमाल करके, जल्द से जल्द चलाया जाना चाहिए. यहां दिए गए कोड स्निपेट में, setExpedited() का इस्तेमाल करने का उदाहरण दिया गया है:

val request = OneTimeWorkRequestBuilder<SyncWorker>()
    .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)
    .build()

WorkManager.getInstance(context)
    .enqueue(request)

OneTimeWorkRequest request = new OneTimeWorkRequestBuilder<T>()
    .setInputData(inputData)
    .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)
    .build();

इस उदाहरण में, हम OneTimeWorkRequest के एक इंस्टेंस को शुरू करते हैं और उस पर setExpedited() को कॉल करते हैं. इसके बाद, इस अनुरोध को जल्दी पूरा किया जाता है. अगर कोटा की अनुमति है, तो यह बैकग्राउंड में तुरंत चलने लगेगा. अगर कोटा का इस्तेमाल किया गया है, तो OutOfQuotaPolicy पैरामीटर से पता चलता है कि अनुरोध को सामान्य तौर पर चलाया जाना चाहिए, न कि जल्दी.

पुराने सिस्टम के साथ काम करने की सुविधा और फ़ोरग्राउंड सेवाएं

जल्दी से होने वाली प्रोसेस के लिए, पुराने सिस्टम के साथ काम करने की सुविधा बनाए रखने के लिए, WorkManager, Android 12 से पहले के प्लैटफ़ॉर्म वर्शन पर फ़ोरग्राउंड सेवा चला सकता है. फ़ोरग्राउंड सेवाएं, उपयोगकर्ता को सूचना दिखा सकती हैं.

आपके Worker में मौजूद getForegroundInfoAsync() और getForegroundInfo() तरीके, Android 12 से पहले setExpedited() को कॉल करने पर, WorkManager को सूचना दिखाने की सुविधा देते हैं.

अगर आपको किसी टास्क को तेज़ी से पूरा करने के लिए अनुरोध करना है, तो ListenableWorker को getForegroundInfo तरीका लागू करना होगा.

Android 12 या उसके बाद के वर्शन को टारगेट करने पर, फ़ोरग्राउंड सेवाएं आपके लिए उपलब्ध रहती हैं. इसके लिए, आपको setForeground का तरीका अपनाना होगा.

वर्कर

कर्मचारियों को यह नहीं पता कि वे जिस काम को कर रहे हैं उसे जल्दी पूरा करना है या नहीं. हालांकि, जब किसी WorkRequest को जल्दी भेजा जाता है, तो वर्कर्स को Android के कुछ वर्शन पर सूचना दिख सकती है.

इसे चालू करने के लिए, WorkManager getForegroundInfoAsync() तरीका उपलब्ध कराता है. इसे लागू करना ज़रूरी है, ताकि WorkManager ज़रूरत पड़ने पर आपके लिए ForegroundService शुरू करने के लिए सूचना दिखा सके.

CoroutineWorker

अगर CoroutineWorker का इस्तेमाल किया जाता है, तो आपको getForegroundInfo() लागू करना होगा. इसके बाद, इसे doWork() के अंदर setForeground() को भेजें. ऐसा करने से, Android 12 से पहले के वर्शन में सूचना बन जाएगी.

नीचे दिया गया उदाहरण देखें:

  class ExpeditedWorker(appContext: Context, workerParams: WorkerParameters):
   CoroutineWorker(appContext, workerParams) {

   override suspend fun getForegroundInfo(): ForegroundInfo {
       return ForegroundInfo(
           NOTIFICATION_ID, createNotification()
       )
   }

   override suspend fun doWork(): Result {
       TODO()
   }

    private fun createNotification() : Notification {
       TODO()
    }

}

कोटा से जुड़ी नीतियां

आपके पास यह कंट्रोल करने का विकल्प होता है कि जब आपका ऐप्लिकेशन, टास्क को पूरा करने के लिए तय किए गए कोटे तक पहुंच जाए, तो तेज़ी से किए जाने वाले काम का क्या होगा. जारी रखने के लिए, setExpedited() को पास किया जा सकता है:

• OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST, जिसकी वजह से नौकरी, सामान्य काम के अनुरोध के तौर पर चलती है. ऊपर दिए गए स्निपेट में इसकी जानकारी दी गई है.
• OutOfQuotaPolicy.DROP_WORK_REQUEST, जिसकी वजह से ज़रूरत के मुताबिक कोटा न होने पर अनुरोध रद्द हो जाता है.

हाई-प्रायाॅरिटी वाला काम, जिसे बाद में किया जाना है

जॉब शुरू होने के बाद, सिस्टम उसे जल्द से जल्द पूरा करने की कोशिश करता है. हालांकि, अन्य तरह के जॉब की तरह ही, सिस्टम के लिए यह मुमकिन है कि वह जल्द से जल्द किए जाने वाले नए जॉब को शुरू करने में देरी करे. जैसे:

• लोड: सिस्टम पर बहुत ज़्यादा लोड है. ऐसा तब हो सकता है, जब पहले से ही बहुत सारी जॉब चल रही हों या सिस्टम में ज़रूरत के मुताबिक मेमोरी न हो.
• कोटा: जल्दी प्रोसेस किए जाने वाले जॉब के कोटे की सीमा पार हो गई है. जल्दी काम करने की सुविधा, ऐप्लिकेशन स्टैंडबाय बकेट के आधार पर तय किए गए कोटा सिस्टम का इस्तेमाल करती है. साथ ही, यह रोलिंग टाइम विंडो में, प्रोसेस पूरी होने में लगने वाले ज़्यादा से ज़्यादा समय को सीमित करती है. जल्दी किए जाने वाले काम के लिए इस्तेमाल किए जाने वाले कोटा, बैकग्राउंड में चलने वाले अन्य तरह के कामों के लिए इस्तेमाल किए जाने वाले कोटे से ज़्यादा पाबंदी वाले होते हैं.

बार-बार होने वाले काम को शेड्यूल करना

आपके ऐप्लिकेशन को समय-समय पर कुछ काम करने की ज़रूरत पड़ सकती है. उदाहरण के लिए, हो सकता है कि आप समय-समय पर अपने डेटा का बैकअप लें, अपने ऐप्लिकेशन में नया कॉन्टेंट डाउनलोड करें या किसी सर्वर पर लॉग अपलोड करें.

समय-समय पर काम करने वाला WorkRequest ऑब्जेक्ट बनाने के लिए, PeriodicWorkRequest का इस्तेमाल करने का तरीका यहां बताया गया है:

val saveRequest =
       PeriodicWorkRequestBuilder<SaveImageToFileWorker>(1, TimeUnit.HOURS)
    // Additional configuration
           .build()

PeriodicWorkRequest saveRequest =
       new PeriodicWorkRequest.Builder(SaveImageToFileWorker.class, 1, TimeUnit.HOURS)
           // Constraints
           .build();

इस उदाहरण में, काम को एक घंटे के इंटरवल के साथ शेड्यूल किया गया है.

इंटरवल पीरियड को, दोहराव के बीच के कम से कम समय के तौर पर जाना जाता है. वर्कर को एक्ज़ीक्यूट किए जाने का सटीक समय, WorkRequest ऑब्जेक्ट में इस्तेमाल की जा रही पाबंदियों और सिस्टम के किए ऑप्टिमाइज़ेशन पर निर्भर करता है.

दौड़ने के लिए फ़्लेक्सिबल इंटरवल

अगर आपका काम, चलने के समय (रन टाइमिंग) को लेकर संवेदनशील है, तो आपके पास अपने PeriodicWorkRequest को कॉन्फ़िगर करने का विकल्प होता है, ताकि वह हर इंटरवल में फ़्लेक्सिबल इंटरवल के अंदर चल सके, जैसा कि फ़िगर 1 में दिखाया गया है.

पहली इमेज. डायग्राम में, फ़्लेक्सिबल पीरियड के साथ दोहराने वाले ऐसे इंटरवल दिखाए गए हैं जिनमें काम चालू हो सकता है.

फ़्लेक्सिबल अवधि के साथ बार-बार होने वाले काम के बारे में बताने के लिए, PeriodicWorkRequest बनाते समय repeatInterval के साथ flexInterval पास करें. फ़्लेक्सिबल अवधि की शुरुआत repeatInterval - flexInterval से होती है और यह इंटरवल के आखिर तक चलती है.

यहां, हर एक घंटे की अवधि के आखिरी 15 मिनट के दौरान चलने वाले, समय-समय पर होने वाले काम का उदाहरण दिया गया है.

val myUploadWork = PeriodicWorkRequestBuilder<SaveImageToFileWorker>(
       1, TimeUnit.HOURS, // repeatInterval (the period cycle)
       15, TimeUnit.MINUTES) // flexInterval
    .build()

WorkRequest saveRequest =
       new PeriodicWorkRequest.Builder(SaveImageToFileWorker.class,
               1, TimeUnit.HOURS,
               15, TimeUnit.MINUTES)
           .build();

दोहराव वाले इंटरवल की वैल्यू, PeriodicWorkRequest.MIN_PERIODIC_INTERVAL_MILLIS से ज़्यादा या उसके बराबर होनी चाहिए. साथ ही, फ़्लेक्सिबल इंटरवल की वैल्यू, PeriodicWorkRequest.MIN_PERIODIC_FLEX_MILLIS से ज़्यादा या उसके बराबर होनी चाहिए.

बार-बार होने वाले काम पर कंस्ट्रेंट का असर

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

काम से जुड़े कंस्ट्रेंट

सीमाएं यह पक्का करती हैं कि काम तब तक न किया जाए, जब तक सही शर्तें पूरी न हो जाएं. WorkManager के लिए ये कंस्ट्रेंट उपलब्ध हैं.

पाबंदियों का सेट बनाने और उसे किसी काम से जोड़ने के लिए, Contraints.Builder() का इस्तेमाल करके Constraints इंस्टेंस बनाएं और उसे अपने WorkRequest.Builder() को असाइन करें.

उदाहरण के लिए, यह कोड एक ऐसा वर्क रिक्वेस्ट बनाता है जो सिर्फ़ तब चलता है, जब उपयोगकर्ता का डिवाइस चार्ज हो रहा हो और वाई-फ़ाई से कनेक्ट हो:

val constraints = Constraints.Builder()
   .setRequiredNetworkType(NetworkType.UNMETERED)
   .setRequiresCharging(true)
   .build()

val myWorkRequest: WorkRequest =
   OneTimeWorkRequestBuilder<MyWork>()
       .setConstraints(constraints)
       .build()

Constraints constraints = new Constraints.Builder()
       .setRequiredNetworkType(NetworkType.UNMETERED)
       .setRequiresCharging(true)
       .build();

WorkRequest myWorkRequest =
       new OneTimeWorkRequest.Builder(MyWork.class)
               .setConstraints(constraints)
               .build();

एक से ज़्यादा कंस्ट्रेंट तय करने पर, आपका फ़ंक्शन सिर्फ़ तब चलेगा, जब सभी कंस्ट्रेंट पूरे हो जाएंगे.

अगर आपका काम चलने के दौरान कोई शर्त पूरी नहीं होती है, तो WorkManager आपके वर्कर को बंद कर देगा. सभी कंस्ट्रेंट पूरा होने पर, फिर से कोशिश की जाएगी.

देरी से हुआ काम

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

यहां एक उदाहरण दिया गया है, जिसमें यह बताया गया है कि किसी टास्क को सूची में शामिल करने के कम से कम 10 मिनट बाद उसे कैसे चलाया जा सकता है.

val myWorkRequest = OneTimeWorkRequestBuilder<MyWork>()
   .setInitialDelay(10, TimeUnit.MINUTES)
   .build()

WorkRequest myWorkRequest =
      new OneTimeWorkRequest.Builder(MyWork.class)
               .setInitialDelay(10, TimeUnit.MINUTES)
               .build();

इस उदाहरण में, OneTimeWorkRequest के लिए शुरुआती देरी सेट करने का तरीका बताया गया है. हालांकि, PeriodicWorkRequest के लिए भी शुरुआती देरी सेट की जा सकती है. ऐसे में, समय-समय पर होने वाले आपके काम के पहले रन में ही देरी होगी.

दोबारा कोशिश करने और बैकऑफ़ की नीति

अगर आपको WorkManager से अपने काम को फिर से शुरू करने के लिए कहना है, तो अपने वर्कर से Result.retry() दिखाएं. इसके बाद, आपके काम को बैकऑफ़ में लगने वाले समय और बैकऑफ़ की नीति के हिसाब से फिर से शेड्यूल किया जाता है.

• बैकऑफ़ डिले से पता चलता है कि पहले प्रयास के बाद, फिर से कोशिश करने से पहले, कम से कम कितने समय तक इंतज़ार करना होगा. यह वैल्यू 10 सेकंड (या MIN_BACKOFF_MILLIS) से कम नहीं हो सकती.

• बैकऑफ़ नीति से यह तय होता है कि बार-बार कोशिश करने पर, समय के साथ बैकऑफ़ में कितनी देरी होनी चाहिए. WorkManager में, बैकऑफ़ की दो नीतियां काम करती हैं: LINEAR और EXPONENTIAL.

हर वर्क रिक्वेस्ट के लिए, बैकऑफ़ नीति और बैकऑफ़ में लगने वाला समय तय होता है. डिफ़ॉल्ट नीति EXPONENTIAL है, जिसमें 30 सेकंड की देरी होती है. हालांकि, इसे अपने काम के अनुरोध के कॉन्फ़िगरेशन में बदला जा सकता है.

यहां बैकऑफ़ में लगने वाले समय और नीति को पसंद के मुताबिक बनाने का उदाहरण दिया गया है.

val myWorkRequest = OneTimeWorkRequestBuilder<MyWork>()
   .setBackoffCriteria(
       BackoffPolicy.LINEAR,
       OneTimeWorkRequest.MIN_BACKOFF_MILLIS,
       TimeUnit.MILLISECONDS)
   .build()

WorkRequest myWorkRequest =
       new OneTimeWorkRequest.Builder(MyWork.class)
               .setBackoffCriteria(
                       BackoffPolicy.LINEAR,
                       OneTimeWorkRequest.MIN_BACKOFF_MILLIS,
                       TimeUnit.MILLISECONDS)
               .build();

इस उदाहरण में, कम से कम बैकऑफ़ देरी को कम से कम अनुमति वाली वैल्यू, 10 सेकंड पर सेट किया गया है. नीति LINEAR होने की वजह से, हर बार फिर से कोशिश करने पर, रिトライ इंटरवल करीब 10 सेकंड बढ़ जाएगा. उदाहरण के लिए, अगर Result.retry() पर फ़िनिश होने वाले पहले रन के बाद भी Result.retry() दिखता है, तो 10 सेकंड के बाद फिर से कोशिश की जाएगी. इसके बाद, 20, 30, 40 सेकंड के बाद भी कोशिश की जाएगी. अगर बैकऑफ़ नीति को EXPONENTIAL पर सेट किया गया था, तो फिर से कोशिश करने की अवधि का क्रम 20, 40, 80 वगैरह होगा.

काम को टैग करना

हर टास्क के अनुरोध में एक यूनीक आइडेंटिफ़ायर होता है. इसका इस्तेमाल, बाद में उस टास्क की पहचान करने के लिए किया जा सकता है, ताकि टास्क को रद्द किया जा सके या उसकी प्रोग्रेस देखी जा सके.

अगर आपके पास एक साथ किए जाने वाले कामों का ग्रुप है, तो उन काम के आइटम को टैग करना भी मददगार हो सकता है. टैग करने की सुविधा की मदद से, एक साथ कई काम के अनुरोधों को मैनेज किया जा सकता है.

उदाहरण के लिए, WorkManager.cancelAllWorkByTag(String) किसी खास टैग वाले सभी काम के अनुरोध रद्द करता है और WorkManager.getWorkInfosByTag(String), WorkInfo ऑब्जेक्ट की सूची दिखाता है. इस सूची का इस्तेमाल, काम की मौजूदा स्थिति का पता लगाने के लिए किया जा सकता है.

नीचे दिए गए कोड से पता चलता है कि अपने काम में "क्लीनअप" टैग कैसे जोड़ा जा सकता है:

val myWorkRequest = OneTimeWorkRequestBuilder<MyWork>()
   .addTag("cleanup")
   .build()

WorkRequest myWorkRequest =
       new OneTimeWorkRequest.Builder(MyWork.class)
       .addTag("cleanup")
       .build();

आखिर में, एक ही काम के अनुरोध में कई टैग जोड़े जा सकते हैं. अंदरूनी तौर पर, इन टैग को स्ट्रिंग के सेट के तौर पर सेव किया जाता है. WorkRequest से जुड़े टैग का सेट पाने के लिए, WorkInfo.getTags() का इस्तेमाल किया जा सकता है.

अपनी Worker क्लास से, ListenableWorker.getTags() के ज़रिए टैग का सेट वापस पाया जा सकता है.

इनपुट डेटा असाइन करना

आपके काम को पूरा होने के लिए इनपुट डेटा की ज़रूरत हो सकती है. उदाहरण के लिए, किसी इमेज को अपलोड करने के लिए, उस इमेज के यूआरआई को इनपुट के तौर पर अपलोड करना पड़ सकता है.

इनपुट वैल्यू, किसी भी Data ऑब्जेक्ट में की-वैल्यू पेयर के तौर पर स्टोर की जाती हैं और उन्हें काम के अनुरोध पर सेट किया जा सकता है. काम को एक्ज़ीक्यूट करते समय, WorkManager आपके काम के लिए इनपुट Data डिलीवर करेगा. Worker क्लास, Worker.getInputData() को कॉल करके इनपुट आर्ग्युमेंट ऐक्सेस कर सकती है. यहां दिए गए कोड में, Worker इंस्टेंस बनाने का तरीका बताया गया है. इस इंस्टेंस के लिए इनपुट डेटा की ज़रूरत होती है. साथ ही, यह भी बताया गया है कि अपने काम के अनुरोध में, इनपुट डेटा को कैसे भेजा जा सकता है.

// Define the Worker requiring input
class UploadWork(appContext: Context, workerParams: WorkerParameters)
   : Worker(appContext, workerParams) {

   override fun doWork(): Result {
       val imageUriInput =
           inputData.getString("IMAGE_URI") ?: return Result.failure()

       uploadFile(imageUriInput)
       return Result.success()
   }
   ...
}

// Create a WorkRequest for your Worker and sending it input
val myUploadWork = OneTimeWorkRequestBuilder<UploadWork>()
   .setInputData(workDataOf(
       "IMAGE_URI" to "http://..."
   ))
   .build()

// Define the Worker requiring input
public class UploadWork extends Worker {

   public UploadWork(Context appContext, WorkerParameters workerParams) {
       super(appContext, workerParams);
   }

   @NonNull
   @Override
   public Result doWork() {
       String imageUriInput = getInputData().getString("IMAGE_URI");
       if(imageUriInput == null) {
           return Result.failure();
       }

       uploadFile(imageUriInput);
       return Result.success();
   }
   ...
}

// Create a WorkRequest for your Worker and sending it input
WorkRequest myUploadWork =
      new OneTimeWorkRequest.Builder(UploadWork.class)
           .setInputData(
               new Data.Builder()
                   .putString("IMAGE_URI", "http://...")
                   .build()
           )
           .build();

इसी तरह, रिटर्न वैल्यू दिखाने के लिए Data क्लास का इस्तेमाल किया जा सकता है. इनपुट पैरामीटर और दिखाई गई वैल्यू सेक्शन में, इनपुट और आउटपुट डेटा के बारे में ज़्यादा जानकारी दी गई है.

अगले चरण

स्टेटस और निगरानी पेज पर, आपको काम की स्थितियों और अपने काम की प्रोग्रेस को मॉनिटर करने के तरीके के बारे में ज़्यादा जानकारी मिलेगी.