शुरू करने से जुड़ी गाइड में, आसान WorkRequest
बनाने और उसे सूची में जोड़ने का तरीका बताया गया है.
इस गाइड में, आपको WorkRequest
ऑब्जेक्ट तय करने और उन्हें पसंद के मुताबिक बनाने का तरीका बताया जाएगा. इससे, इस्तेमाल के सामान्य उदाहरणों को मैनेज करने में मदद मिलेगी. जैसे:
- एक बार और बार-बार होने वाले काम शेड्यूल करना
- काम से जुड़ी पाबंदियां सेट करना, जैसे कि वाई-फ़ाई या चार्जिंग की ज़रूरत होना
- काम पूरा होने में कम से कम देरी की गारंटी
- फिर से कोशिश करने और बैक-ऑफ़ की रणनीतियां सेट करना
- इनपुट डेटा को फ़ंक्शन में पास करना
- टैग का इस्तेमाल करके, मिलते-जुलते कामों को एक साथ ग्रुप करना
खास जानकारी
WorkManager में, WorkRequest
की मदद से काम तय किया जाता है. WorkManager की मदद से कोई भी काम शेड्यूल करने के लिए, आपको पहले एक WorkRequest
ऑब्जेक्ट बनाना होगा और फिर उसे सूची में जोड़ना होगा.
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, ऐप्लिकेशन के बीच संसाधनों को ज़्यादा असरदार तरीके से बांट पाता है.
किसी ऐप्लिकेशन को प्रोसेस करने में लगने वाला समय, स्टैंडबाय बकेट और प्रोसेस की अहमियत पर निर्भर करता है.
यह तय किया जा सकता है कि जब टास्क पूरा करने के कोटे की वजह से, तेज़ी से पूरी की जाने वाली कोई टास्क तुरंत न चल पाए, तो क्या होगा. ज़्यादा जानकारी के लिए, नीचे दिए गए स्निपेट देखें.
तेज़ी से काम करना
WorkManager 2.7 से, आपका ऐप्लिकेशन setExpedited()
को कॉल करके यह एलान कर सकता है कि किसी WorkRequest
को तेज़ी से काम करने वाले जॉब का इस्तेमाल करके, जल्द से जल्द चलाया जाना चाहिए. यहां दिए गए कोड स्निपेट में, setExpedited()
को इस्तेमाल करने का उदाहरण दिया गया है:
Kotlin
val request = OneTimeWorkRequestBuilder<SyncWorker>() .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) .build() WorkManager.getInstance(context) .enqueue(request)
Java
OneTimeWorkRequest request = new OneTimeWorkRequestBuilder<T>() .setInputData(inputData) .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) .build();
इस उदाहरण में, हम OneTimeWorkRequest
के एक इंस्टेंस को शुरू करते हैं और उस पर
setExpedited()
को कॉल करते हैं. इसके बाद, इस अनुरोध को जल्दी पूरा किया जाता है. अगर कोटा की अनुमति है, तो यह बैकग्राउंड में तुरंत चलने लगेगा. अगर कोटा का इस्तेमाल कर लिया गया है, तो OutOfQuotaPolicy
पैरामीटर से पता चलता है कि अनुरोध को सामान्य तरीके से किया जाना चाहिए. हालांकि, इसमें अनुरोध को जल्दी पूरा किया जाना चाहिए.
पुराने सिस्टम के साथ काम करने की सुविधा और फ़ोरग्राउंड सेवाएं
जल्द से जल्द जॉब के लिए, पुराने सिस्टम के साथ काम करने की सुविधा को बनाए रखने के लिए, WorkManager Android 12 से पुराने प्लैटफ़ॉर्म के वर्शन पर फ़ोरग्राउंड सेवा चला सकता है. फ़ोरग्राउंड सेवाएं, उपयोगकर्ता को सूचना दिखा सकती हैं.
आपके Worker में मौजूद getForegroundInfoAsync()
और getForegroundInfo()
तरीके, Android 12 से पहले setExpedited()
को कॉल करने पर, WorkManager को सूचना दिखाने की सुविधा देते हैं.
अगर आपको किसी टास्क को तेज़ी से पूरा करने के लिए अनुरोध करना है, तो 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
, जिसकी वजह से ज़रूरत के मुताबिक कोटा न होने पर अनुरोध रद्द हो जाता है.
सैंपल ऐप्लिकेशन
WorkManager 2.7.0 में, तेज़ी से काम करने की सुविधा का इस्तेमाल कैसे किया जाता है, इसका पूरा उदाहरण देखने के लिए, GitHub पर WorkManagerSample देखें.
रुका हुआ काम
जॉब शुरू होने के बाद, सिस्टम उसे जल्द से जल्द पूरा करने की कोशिश करता है. हालांकि, अन्य तरह के जॉब की तरह ही, सिस्टम के पास यह तय करने का विकल्प होता है कि जल्द से जल्द पूरा किए जाने वाले नए जॉब को कब शुरू किया जाए. जैसे:
- लोड: सिस्टम पर बहुत ज़्यादा लोड है. ऐसा तब हो सकता है, जब पहले से ही बहुत सारी जॉब चल रही हों या सिस्टम में ज़रूरत के मुताबिक मेमोरी न हो.
- कोटा: जल्दी प्रोसेस किए जाने वाले जॉब के कोटे की सीमा पार हो गई है. जल्दी काम करने की सुविधा, ऐप्लिकेशन स्टैंडबाय बकेट के आधार पर तय किए गए कोटा सिस्टम का इस्तेमाल करती है. साथ ही, यह रोलिंग टाइम विंडो में, प्रोसेस पूरी होने में लगने वाले ज़्यादा से ज़्यादा समय को सीमित करती है. जल्दी किए जाने वाले काम के लिए इस्तेमाल किए जाने वाले कोटा, बैकग्राउंड में चलने वाले अन्य टास्क के लिए इस्तेमाल किए जाने वाले कोटे से ज़्यादा पाबंदी वाले होते हैं.
बार-बार होने वाले काम को शेड्यूल करना
आपके ऐप्लिकेशन को समय-समय पर कुछ काम करने की ज़रूरत पड़ सकती है. उदाहरण के लिए, हो सकता है कि आप समय-समय पर अपने डेटा का बैकअप लें, अपने ऐप्लिकेशन में नया कॉन्टेंट डाउनलोड करें या किसी सर्वर पर लॉग अपलोड करें.
समय-समय पर काम करने वाला 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 ऑब्जेक्ट में इस्तेमाल किए गए कंस्ट्रेंट और सिस्टम की ओर से किए गए ऑप्टिमाइज़ेशन पर निर्भर करता है.
दौड़ने के लिए फ़्लेक्सिबल इंटरवल
अगर आपके काम की वजह से, रन टाइम को समझना मुश्किल होता है, तो आपके PeriodicWorkRequest
को हर इंटरवल पीरियड में, फ़्लेक्सिबल पीरियड में चलने के लिए कॉन्फ़िगर किया जा सकता है, जैसा कि पहली इमेज में दिखाया गया है.
पहली इमेज. डायग्राम में बार-बार आने वाले इंटरवल को दिखाने के लिए, सुविधाजनक पीरियड के बारे में बताया गया है. इस समयावधि में, काम चल सकता है.
फ़्लेक्सिबल पीरियड के साथ, समय-समय पर होने वाले काम को तय करने के लिए, आपको PeriodicWorkRequest
बनाते समय repeatInterval
के साथ flexInterval
पास करना होता है. फ़्लेक्सिबल अवधि की शुरुआत 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
तब तक नहीं चलेगा, जब तक यह शर्त पूरी नहीं हो जाती. इसकी वजह से, आपके काम की एक खास प्रोसेस में देरी हो सकती है. इसके अलावा, रन इंटरवल के अंदर शर्तें पूरी न होने पर, प्रोसेस को स्किप भी किया जा सकता है.
काम से जुड़े कंस्ट्रेंट
सीमाएं यह पक्का करती हैं कि काम तब तक न किया जाए, जब तक सही शर्तें पूरी न हो जाएं. WorkManager के लिए ये पाबंदियां उपलब्ध हैं.
NetworkType | यह आपके काम के लिए ज़रूरी नेटवर्क टाइप पर पाबंदी लगाता है.
उदाहरण के लिए, वाई-फ़ाई (UNMETERED ).
|
BatteryNotLow | अगर इस विकल्प को 'सही है' पर सेट किया जाता है, तो डिवाइस के बैटरी लेवल कम होने पर, आपका काम नहीं चलेगा. |
RequiresCharging | अगर नीति को 'सही है' पर सेट किया जाता है, तो आपका काम सिर्फ़ तब चलेगा, जब डिवाइस चार्ज हो रहा होगा. |
डिवाइस आइडल | 'सही' पर सेट होने पर, कोई टास्क तब ही पूरा होगा, जब उपयोगकर्ता का डिवाइस कुछ समय से इस्तेमाल में न हो. यह बैच में ऑपरेशन चलाने के लिए फ़ायदेमंद हो सकता है. ऐसा न करने पर, उपयोगकर्ता के डिवाइस पर चल रहे अन्य ऐप्लिकेशन की परफ़ॉर्मेंस पर बुरा असर पड़ सकता है. |
StorageNotLow | अगर इस विकल्प को 'सही' पर सेट किया जाता है, तो उपयोगकर्ता के डिवाइस में स्टोरेज की जगह बहुत कम होने पर, आपका काम नहीं चलेगा. |
कंस्ट्रेंट का सेट बनाने और इसे कुछ काम से जोड़ने के लिए, Contraints.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 आपके काम को फिर से करे, तो आपके पास अपने वर्कर से 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 सेकंड बाद फिर से शुरू किया जाएगा, उसके बाद 20, 30, 40, और इसी तरह आगे भी काम शुरू किया जाएगा, तो ऐसा होता है.Result.retry()
अगर बैकऑफ़ नीति को EXPONENTIAL
पर सेट किया गया था, तो फिर से कोशिश करने की अवधि 20, 40, 80 वगैरह के आस-पास होगी.
काम को टैग करना
काम के हर अनुरोध का एक यूनीक आइडेंटिफ़ायर होता है, जिसका इस्तेमाल बाद में काम को रद्द करने या उसकी प्रोग्रेस को देखने के लिए किया जा सकता है.
अगर आपके पास एक साथ किए जाने वाले कामों का ग्रुप है, तो उन काम के आइटम को टैग करना भी मददगार हो सकता है. टैगिंग से आपको काम से जुड़े अनुरोधों के एक ग्रुप को एक साथ ऑपरेट करने में मदद मिलती है.
उदाहरण के लिए, WorkManager.cancelAllWorkByTag(String)
किसी खास टैग वाले सभी काम के अनुरोधों को रद्द करता है और WorkManager.getWorkInfosByTag(String)
, WorkInfo ऑब्जेक्ट की सूची दिखाता है जिसका इस्तेमाल काम की मौजूदा स्थिति तय करने के लिए किया जा सकता है.
नीचे दिए गए कोड से पता चलता है कि अपने काम में "क्लीनअप" टैग कैसे जोड़ा जा सकता है:
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
क्लास का इस्तेमाल रिटर्न वैल्यू पाने के लिए किया जा सकता है. इनपुट पैरामीटर और दिखाई गई वैल्यू सेक्शन में, इनपुट और आउटपुट डेटा के बारे में ज़्यादा जानकारी दी गई है.
अगले चरण
स्टेटस और निगरानी पेज पर, आपको काम की स्थितियों और अपने काम की प्रोग्रेस को मॉनिटर करने के तरीके के बारे में ज़्यादा जानकारी मिलेगी.