تعریف درخواست‌های کار

راهنمای شروع به کار نحوه ایجاد WorkRequest و قرار دادن آن در صف را پوشش می‌دهد.

در این راهنما، با نحوه تعریف و سفارشی‌سازی کردن اشیای WorkRequest برای مدیریت موارد استفاده رایج آشنا خواهید شد، ازجمله نحوه:

  • زمان‌بندی کارهای یک‌باره و تکرارشونده
  • تنظیم محدودیت‌های کاری مانند نیاز به Wi-Fi یا شارژ
  • تضمین حداقل تأخیر در اجرای کار
  • تنظیم استراتژی‌های تلاش مجدد و عقب‌نشینی
  • داده‌های ورودی را برای کار ارسال کنید
  • کارهای مرتبط را بااستفاده از برچسب‌ها گروه‌بندی کنید

نمای کلی

کار در 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 اجازه می‌دهد کارهای مهم را اجرا کند و درعین‌حال به سیستم کنترل بهتری بر دسترسی به منابع می‌دهد.

کار تسریع‌شده به‌خاطر ویژگی‌های زیر قابل‌توجه است:

  • اهمیت: کار تسریع‌شده برای کارهایی مناسب است که برای کاربر مهم هستند یا توسط کاربر شروع شده‌اند.
  • سرعت: کار تسریع‌شده برای کارهای کوتاهی که بلافاصله شروع می‌شوند و ظرف چند دقیقه تکمیل می‌شوند بهترین گزینه است.
  • سهمیه‌ها: سهمیه سطح سیستم که زمان اجرای پیش‌زمینه را محدود می‌کند تعیین می‌کند که آیا کار تسریع‌شده می‌تواند شروع شود یا نه.
  • مدیریت مصرف: محدودیت‌های مدیریت مصرف، مانند «بهینه‌سازی باتری» و Doze، کمتر بر وظیفه تسریع‌شده تأثیر می‌گذارند.
  • تأخیر: سیستم بلافاصله وظیفه تسریع‌شده را اجرا می‌کند، مشروط بر اینکه بار کاری فعلی سیستم این امکان را فراهم کند. این یعنی این وظایف به تأخیر حساس هستند و نمی‌توان آن‌ها را برای اجرا در زمان دیگری زمان‌بندی کرد.

یک مورد استفاده بالقوه برای کار تسریع‌شده ممکن است در یک برنامه گپ باشد، زمانی که کاربر می‌خواهد پیامی یا تصویری پیوست‌شده ارسال کند. به‌طور مشابه، برنامه‌ای که جریان پرداخت یا اشتراک را مدیریت می‌کند نیز ممکن است بخواهد از وظیفه تسریع‌شده استفاده کند. دلیلش این است که این تکالیف برای کاربر مهم هستند، به‌سرعت در پس‌زمینه اجرا می‌شوند، باید فوراً شروع شوند، و حتی اگر کاربر برنامه را ببندد باید به اجرا ادامه دهند

سهمیه‌ها

سیستم باید زمان اجرا را به کار تسریع‌شده اختصاص دهد تا بتواند اجرا شود. زمان اجرا نامحدود نیست. بلکه هر برنامه سهمیه‌ای از زمان اجرا دریافت می‌کند. وقتی برنامه‌تان از زمان اجرای خود استفاده می‌کند و به سهمیه اختصاص‌داده‌شده خود می‌رسد، دیگر نمی‌توانید وظیفه تسریع‌شده را اجرا کنید تا زمانی که سهمیه بازآوری شود. این کار به 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() در Worker شما به WorkManager امکان می‌دهد وقتی setExpedited() را فراخوانی می‌کنید، در نسخه‌های قدیمی‌تر از Android 12 اعلان نمایش دهد.

اگر می‌خواهید درخواست کنید که تکلیف به‌عنوان کار تسریع‌شده اجرا شود، هر ListenableWorker باید روش getForegroundInfo را پیاده‌سازی کند.

هنگام هدف‌یابی Android 12 یا بالاتر، سرویس‌های پیش‌زمینه‌ای ازطریق روش setForeground مربوطه همچنان برای شما دردسترس خواهند بود.

عامل

کارگران نمی‌دانند کاری که انجام می‌دهند تسریع شده است یا نه. اما کارگران می‌توانند در برخی‌از نسخه‌های Android، وقتی WorkRequest تسریع شده است، اعلانی را نمایش دهند.

برای فعال کردن این ویژگی، WorkManager روش getForegroundInfoAsync() را ارائه می‌دهد که باید آن را پیاده‌سازی کنید تا WorkManager بتواند درصورت لزوم اعلانی برای شروع ForegroundService برای شما نمایش دهد.

CoroutineWorker

اگر از CoroutineWorker استفاده می‌کنید، باید getForegroundInfo() را پیاده‌سازی کنید. سپس آن را ظرف doWork() به setForeground() منتقل می‌کنید. با این کار، اعلان در نسخه‌های Android قبل‌از ۱۲ ایجاد می‌شود.

مثال زیر را درنظر بگیرید:

  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 خود را به‌گونه‌ای پیکربندی کنید که در یک دوره انعطاف‌پذیر در هر دوره فاصله اجرا شود، همان‌طور که در شکل ۱ نشان داده شده است.

می‌توانید برای کار دوره‌ای، فاصله زمانی انعطاف‌پذیر تنظیم کنید. شما یک فاصله تکرار تعریف می‌کنید، و یک فاصله انعطاف‌پذیر که مقدار مشخصی از زمان را در پایان فاصله تکرار مشخص می‌کند. ‫WorkManager تلاش می‌کند کارتان را در نقطه‌ای از فاصله زمانی انعطاف‌پذیر در هر چرخه اجرا کند.

شکل ۱. نمودار فواصل تکرارشونده را با دوره انعطاف‌پذیری که کار می‌تواند در آن اجرا شود نشان می‌دهد.

برای تعریف کار دوره‌ای با دوره انعطاف‌پذیر، هنگام ایجاد PeriodicWorkRequest، یک flexInterval را به‌همراه repeatInterval ارسال می‌کنید. دوره انعطاف‌پذیر از repeatInterval - flexInterval شروع می‌شود و تا پایان فاصله زمانی ادامه دارد.

در زیر نمونه‌ای از کار دوره‌ای آورده شده است که می‌تواند درطول ۱۵ دقیقه آخر هر دوره یک ساعته اجرا شود.

کاتلین

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 دردسترس است:

NetworkType نوع شبکه موردنیاز برای اجرای کارتان را محدود می‌کند. برای مثال، Wi-Fi (UNMETERED).
BatteryNotLow وقتی روی «درست» تنظیم شود، اگر دستگاه در حالت شارژ کم باتری باشد، کارتان اجرا نخواهد شد.
RequiresCharging وقتی روی true تنظیم شود، کارتان فقط زمانی اجرا می‌شود که دستگاه درحال شارژ باشد.
DeviceIdle وقتی روی «درست» تنظیم شود، این گزینه ایجاب می‌کند که دستگاه کاربر قبل‌از اجرای کار، در حالت غیرفعال باشد. این کار می‌تواند برای اجرای عملیات دسته‌ای مفید باشد که درغیراین‌صورت ممکن است تأثیر منفی بر عملکرد سایر برنامه‌هایی داشته باشد که به‌طور فعال در دستگاه کاربر اجرا می‌شوند.
StorageNotLow وقتی روی «درست» تنظیم شود، اگر فضای ذخیره‌سازی کاربر در دستگاه خیلی کم باشد، کارتان اجرا نخواهد شد.

برای ایجاد مجموعه‌ای از محدودیت‌ها و مرتبط کردن آن با برخی‌از کارها، بااستفاده از Constraints.Builder() یک نمونه Constraints ایجاد کنید و آن را به WorkRequest.Builder() خود اختصاص دهید.

برای مثال، کد زیر درخواست کاری را می‌سازد که فقط وقتی اجرا می‌شود که دستگاه کاربر هم درحال شارژ باشد و هم به Wi-Fi متصل باشد:

کاتلین

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 کارگر شما را متوقف خواهد کرد. سپس وقتی همه محدودیت‌ها برآورده شد، کار دوباره امتحان می‌شود.

کار با تأخیر

درصورتی‌که کارتان هیچ محدودیتی نداشته باشد یا همه محدودیت‌ها هنگام قرار گرفتن کارتان در صف برآورده شود، سیستم ممکن است تصمیم بگیرد کار را فوراً اجرا کند. اگر نمی‌خواهید کار فوراً اجرا شود، می‌توانید مشخص کنید کارتان پس‌از حداقل تأخیر اولیه شروع شود.

در اینجا مثالی از نحوه تنظیم کار برای اجرا حداقل ۱۰ دقیقه پس‌از قرار گرفتن در صف آورده شده است.

کاتلین

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() را از کارگرتان برگردانید. سپس کارتان طبق تأخیر عقب‌نشینی و خط‌مشی عقب‌نشینی دوباره زمان‌بندی می‌شود.

  • تأخیر عقب‌نشینی حداقل مدت زمانی را که باید قبل‌از امتحان مجدد کارتان پس‌از اولین تلاش صبر کنید مشخص می‌کند. این مقدار نمی‌تواند کمتر از ۱۰ ثانیه باشد (یا MIN_BACKOFF_MILLIS).

  • خط‌مشی عقب‌نشینی مشخص می‌کند که تأخیر عقب‌نشینی چگونه باید درطول زمان برای تلاش‌های مجدد بعدی افزایش یابد. WorkManager از ۲ خط‌مشی عقب‌نشینی پشتیبانی می‌کند، LINEAR و EXPONENTIAL.

هر درخواست کار دارای خط‌مشی عقب‌گرد و تأخیر عقب‌گرد است. خط‌مشی پیش‌فرض EXPONENTIAL با تأخیر ۳۰ ثانیه‌ای است، اما می‌توانید این مورد را در پیکربندی درخواست کار لغو کنید.

در اینجا نمونه‌ای از سفارشی‌سازی تأخیر و خط‌مشی عقب‌نشینی آورده شده است.

کاتلین

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

در این مثال، حداقل تأخیر عقب‌نشینی روی حداقل مقدار مجاز تنظیم شده است، ۱۰ ثانیه. ازآنجایی‌که خط‌مشی LINEAR است، فاصله زمانی امتحان مجدد با هر تلاش جدید تقریباً ۱۰ ثانیه افزایش می‌یابد. برای مثال، اولین اجرا که با Result.retry() تمام می‌شود، پس‌از ۱۰ ثانیه دوباره امتحان می‌شود و اگر کار همچنان پس‌از تلاش‌های بعدی Result.retry() را برگرداند، تلاش‌های بعدی پس‌از ۲۰، ۳۰، ۴۰ ثانیه و غیره انجام می‌شود. اگر خط‌مشی عقب‌نشینی روی EXPONENTIAL تنظیم شده باشد، توالی مدت‌زمان تلاش مجدد به ۲۰، ۴۰، و ۸۰ نزدیک‌تر خواهد بود.

برچسب‌گذاری کار

هر درخواست کار دارای یک شناسه یکتا است که می‌توان از آن برای شناسایی آن کار در آینده به‌منظور لغو کار یا مشاهده پیشرفت آن استفاده کرد.

اگر گروهی از کارهای مرتبط منطقی دارید، ممکن است برچسب‌گذاری آن موارد کاری نیز برایتان مفید باشد. برچسب‌گذاری به شما امکان می‌دهد با گروهی از درخواست‌های کاری به‌طور هم‌زمان کار کنید.

برای مثال، 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() استفاده کنید.

از کلاس 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 برای خروجی دادن مقدار برگشتی استفاده کنید.

مراحل بعدی

در صفحه وضعیت‌ها و مشاهده، درباره وضعیت‌های کار و نحوه پایش پیشرفت کارتان بیشتر خواهید آموخت.