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

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

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

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

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

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

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

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

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,
       OneTimeWorkRequest.MIN_BACKOFF_MILLIS,
       TimeUnit.MILLISECONDS)
   .build()

Java

WorkRequest myWorkRequest =
       new OneTimeWorkRequest.Builder(MyWork.class)
               .setBackoffCriteria(
                       BackoffPolicy.LINEAR,
                       OneTimeWorkRequest.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 क्लास का इस्तेमाल किया जा सकता है.

अगले चरण

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