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

शुरुआती निर्देश में, 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>()
    <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 से पुराने वर्शन वाले प्लैटफ़ॉर्म पर फ़ोरग्राउंड सेवा चला सकता है. फ़ोरग्राउंड सेवाएं, उपयोगकर्ता को सूचना दिखा सकती हैं.

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

अगर आपको टास्क को हाई-प्रायाॅरिटी वाले टास्क के तौर पर चलाने का अनुरोध करना है, तो किसी भी ListenableWorker को getForegroundInfo तरीके को लागू करना होगा.

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

वर्कर

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

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

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

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 ऑब्जेक्ट की एक सूची दिखाता है. इसका इस्तेमाल, मौजूदा वर्क स्टेट का पता लगाने के लिए किया जा सकता है.

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

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

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

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

ListenableWorker.getTags() का इस्तेमाल करके, Worker क्लास से टैग का सेट वापस पाया जा सकता है.

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

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

इनपुट वैल्यू, 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 क्लास का इस्तेमाल किया जा सकता है.

अगले चरण

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