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

शुरुआती गाइड में, 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 क्लास का इस्तेमाल किया जा सकता है.

अगले चरण

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