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

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

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

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

खास जानकारी

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

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>()
    <b>.setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)</b>
    .build()

WorkManager.getInstance(context)
    .enqueue(request)

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

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

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

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

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

अगर आपको टास्क को तेज़ी से पूरा करने का अनुरोध करना है, तो किसी भी 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, जिसकी वजह से कोटा पूरा न होने पर अनुरोध रद्द हो जाता है.

स्थगित किया गया हाई-प्रायाॅरिटी वाला काम

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

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

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

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

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

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

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

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

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

दौड़ने के इंटरवल में बदलाव करने की सुविधा

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

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

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

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

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

बाध्यताओं का सेट बनाने और उसे किसी काम से जोड़ने के लिए, Constraints.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,
       WorkRequest.MIN_BACKOFF_MILLIS,
       TimeUnit.MILLISECONDS)
   .build()

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

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

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

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

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

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

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

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 क्लास का इस्तेमाल किया जा सकता है.

अगले चरण

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