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

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

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

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

खास जानकारी

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

Kotlin

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

Java

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

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

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

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

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

Kotlin

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

Java

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

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

Kotlin

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

Java

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

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

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

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

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

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

कोटा

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

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

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

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

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

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

Kotlin

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

WorkManager.getInstance(context)
    .enqueue(request)

Java

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 तरीके को लागू करना होगा.

चेतावनी: getForegroundInfo तरीके को लागू न करने पर, प्लैटफ़ॉर्म के पुराने वर्शन पर setExpedited को कॉल करते समय रनटाइम क्रैश हो सकते हैं.

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

चेतावनी: setForeground(), Android 12 पर रनटाइम अपवाद दे सकता है. साथ ही, अगर लॉन्च करने पर पाबंदी लगाई गई थी, तो यह अपवाद दे सकता है.

वर्कर

कर्मचारियों को यह नहीं पता होता कि वे जो काम कर रहे हैं उसे प्राथमिकता दी गई है या नहीं. हालांकि, 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()
    }

}

ध्यान दें: आपको setForeground() को try/catch ब्लॉक में रैप करना चाहिए, ताकि संभावित IllegalStateException को पकड़ा जा सके. ऐसा तब हो सकता है, जब आपका ऐप्लिकेशन इस समय फ़ोरग्राउंड में न चल रहा हो. Android 12 और इसके बाद के वर्शन में, ज़्यादा जानकारी देने वाले ForegroundServiceStartNotAllowedException का इस्तेमाल किया जा सकता है.

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

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

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

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

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

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

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

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

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

Kotlin

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

Java

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

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

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

ध्यान दें: दोहराए जाने वाले इंटरवल को कम से कम 15 मिनट पर सेट किया जा सकता है. यह JobScheduler API के बराबर है.

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

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

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

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

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

Kotlin

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

Java

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 के लिए, ये पाबंदियां उपलब्ध हैं:

NetworkType	इससे यह तय होता है कि आपके काम के लिए किस तरह के नेटवर्क की ज़रूरत है. उदाहरण के लिए, वाई-फ़ाई (UNMETERED).
BatteryNotLow	इस सेटिंग को 'सही है' पर सेट करने पर, डिवाइस के बैटरी सेवर मोड में होने पर आपका काम नहीं होगा.
RequiresCharging	इस नीति को 'सही है' पर सेट करने पर, आपका काम सिर्फ़ तब चलेगा, जब डिवाइस चार्ज हो रहा हो.
DeviceIdle	इस विकल्प को 'सही है' पर सेट करने पर, काम शुरू होने से पहले उपयोगकर्ता के डिवाइस का इस्तेमाल नहीं किया जाना चाहिए. यह उन बैच्ड कार्रवाइयों को चलाने के लिए फ़ायदेमंद हो सकता है जिनका परफ़ॉर्मेंस पर बुरा असर पड़ सकता है. ऐसा तब होता है, जब उपयोगकर्ता के डिवाइस पर अन्य ऐप्लिकेशन चालू हों.
StorageNotLow	इस विकल्प को'सही है' पर सेट करने पर, अगर उपयोगकर्ता के डिवाइस पर स्टोरेज के लिए बहुत कम जगह बची है, तो आपका काम नहीं चलेगा.

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

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

Kotlin

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

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

Java

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

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

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

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

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

अगर आपके काम में कोई कंस्ट्रेंट नहीं है या कतार में रखे जाने पर सभी कंस्ट्रेंट पूरे हो जाते हैं, तो सिस्टम काम को तुरंत शुरू कर सकता है. अगर आपको काम तुरंत शुरू नहीं करना है, तो काम शुरू होने से पहले कम से कम शुरुआती डीले सेट किया जा सकता है.

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

Kotlin

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

Java

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

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

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

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

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

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

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

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

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

Kotlin

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

Java

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" टैग कैसे जोड़ा जा सकता है:

Kotlin

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

Java

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

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

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

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

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

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

Kotlin

// 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()

Java

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

अगले चरण

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