WorkManager به شما امکان میدهد زنجیرهای از کارها را ایجاد کرده و در صف قرار دهید که چندین کار وابسته را مشخص میکند و مشخص میکند که با چه ترتیبی باید اجرا شوند. این عملکرد به ویژه زمانی مفید است که شما نیاز دارید چندین کار را با یک ترتیب خاص اجرا کنید.
برای ایجاد زنجیره ای از کار، می توانید از WorkManager.beginWith(OneTimeWorkRequest)
یا WorkManager.beginWith(List<OneTimeWorkRequest>)
استفاده کنید که هر کدام یک نمونه از WorkContinuation
را برمی گرداند.
سپس میتوان از WorkContinuation
برای افزودن نمونههای وابسته OneTimeWorkRequest
با استفاده از then(OneTimeWorkRequest)
یا then(List<OneTimeWorkRequest>)
استفاده کرد.
هر فراخوانی WorkContinuation.then(...)
یک نمونه جدید از WorkContinuation
را برمی گرداند. اگر List
از نمونه های OneTimeWorkRequest
اضافه کنید، این درخواست ها به طور بالقوه می توانند به صورت موازی اجرا شوند.
در نهایت، می توانید از متد WorkContinuation.enqueue()
برای enqueue()
زنجیره WorkContinuation
s خود استفاده کنید.
بیایید به یک مثال نگاه کنیم. در این مثال، 3 کار مختلف برای اجرا (به طور بالقوه به صورت موازی) پیکربندی شده اند. نتایج این Workers سپس به یکدیگر ملحق میشوند و به یک کار در حافظه پنهان منتقل میشوند. در نهایت، خروجی آن کار به یک Upload Worker ارسال میشود که نتایج را در یک سرور راه دور آپلود میکند.
کاتلین
WorkManager.getInstance(myContext) // Candidates to run in parallel .beginWith(listOf(plantName1, plantName2, plantName3)) // Dependent work (only runs after all previous work in chain) .then(cache) .then(upload) // Call enqueue to kick things off .enqueue()
جاوا
WorkManager.getInstance(myContext) // Candidates to run in parallel .beginWith(Arrays.asList(plantName1, plantName2, plantName3)) // Dependent work (only runs after all previous work in chain) .then(cache) .then(upload) // Call enqueue to kick things off .enqueue();
ادغام ورودی
وقتی نمونههای OneTimeWorkRequest
را زنجیرهای میکنید، خروجی درخواستهای کار والدین به عنوان ورودی به فرزندان ارسال میشود. بنابراین در مثال بالا، خروجی های plantName1
، plantName2
و plantName3
به عنوان ورودی به درخواست cache
ارسال می شوند.
برای مدیریت ورودیهای چندین درخواست کار والدین، WorkManager از InputMerger
استفاده میکند.
دو نوع مختلف از InputMerger
ارائه شده توسط WorkManager وجود دارد:
OverwritingInputMerger
سعی می کند همه کلیدها را از همه ورودی ها به خروجی اضافه کند. در صورت تداخل، کلیدهای تنظیم شده قبلی را بازنویسی می کند.ArrayCreatingInputMerger
سعی می کند ورودی ها را ادغام کند و در صورت لزوم آرایه هایی ایجاد کند.
اگر مورد خاص تری دارید، می توانید مورد خود را با زیر کلاس بندی InputMerger
بنویسید.
OverwritingInputMerger
OverwritingInputMerger
روش ادغام پیش فرض است. اگر تداخل کلیدی در ادغام وجود داشته باشد، آخرین مقدار برای یک کلید، نسخههای قبلی را در دادههای خروجی بازنویسی میکند.
برای مثال، اگر ورودیهای کارخانه دارای کلیدی باشند که با نامهای متغیر مربوطه مطابقت دارد ( "plantName1"
، "plantName2"
و "plantName3"
)، آنگاه دادههای ارسال شده به cache
دارای سه جفت کلید-مقدار خواهند بود.
اگر تضاد وجود داشته باشد، آخرین کارگری که «برنده» را تکمیل میکند، و مقدار آن به cache
منتقل میشود.
از آنجایی که درخواستهای کاری شما به صورت موازی اجرا میشوند، تضمینی برای ترتیب اجرای آن ندارید. در مثال بالا، plantName1
میتواند مقدار "tulip"
یا "elm"
را داشته باشد، بسته به اینکه کدام مقدار آخرین نوشته شده باشد. اگر شانس تداخل کلید را دارید و باید تمام داده های خروجی را در یک ادغام حفظ کنید، ممکن است ArrayCreatingInputMerger
گزینه بهتری باشد.
ArrayCreatingInputMerger
برای مثال بالا، با توجه به اینکه میخواهیم خروجیهای نام کارخانه Workers را حفظ کنیم، باید از ArrayCreatingInputMerger
استفاده کنیم.
کاتلین
val cache: OneTimeWorkRequest = OneTimeWorkRequestBuilderP<lantWorker(>) .setInputMerger(ArrayCreatingInputMerger::class) .setConstraints(constraints) .build()
جاوا
OneTimeWorkRequest cache = new OneTimeWorkRequest.Builder(PlantWorker.class) .setInputMerger(ArrayCreatingInputMerger.class) .setConstraints(constraints) .build();
ArrayCreatingInputMerger
هر کلید را با یک آرایه جفت می کند. اگر هر یک از کلیدها منحصر به فرد است، نتیجه شما مجموعه ای از آرایه های تک عنصری است.
اگر هر گونه برخورد کلیدی وجود داشته باشد، هر مقدار مربوطه در یک آرایه با هم گروه بندی می شود.
زنجیر زنی و وضعیت کار
زنجیرههای OneTimeWorkRequest
تا زمانی که کارشان با موفقیت به پایان برسد بهطور متوالی اجرا میشوند (یعنی یک Result.success()
برمیگردانند). درخواستهای کاری ممکن است در حین اجرا با شکست مواجه شوند یا لغو شوند، که تأثیرات پاییندستی بر درخواستهای کاری وابسته دارد.
هنگامی که اولین OneTimeWorkRequest
در زنجیره ای از درخواست های کاری در صف قرار می گیرد، تمام درخواست های کاری بعدی مسدود می شوند تا زمانی که کار اولین درخواست کاری تکمیل شود.
هنگامی که در نوبت قرار گرفت و تمام محدودیت های کاری برآورده شد، اولین درخواست کاری شروع به اجرا می کند. اگر کار با موفقیت در ریشه OneTimeWorkRequest
یا List<OneTimeWorkRequest>
تکمیل شود (یعنی یک Result.success()
را برمی گرداند، سپس مجموعه بعدی درخواست های کاری وابسته در صف قرار می گیرند.
تا زمانی که هر درخواست کاری با موفقیت تکمیل شود، همین الگو در بقیه زنجیره درخواست های کاری شما منتشر می شود تا زمانی که تمام کارهای زنجیره تکمیل شود. در حالی که این ساده ترین و اغلب ترجیح داده شده است، حالات خطا به همان اندازه مهم هستند که رسیدگی شوند.
هنگامی که یک کارگر در حال پردازش درخواست کاری شما است، خطایی رخ می دهد، می توانید آن درخواست را طبق خط مشی عقب نشینی که تعریف کرده اید دوباره امتحان کنید. تلاش مجدد درخواستی که بخشی از یک زنجیره است به این معنی است که فقط آن درخواست با داده های ورودی ارائه شده به آن دوباره امتحان می شود. هر کاری که به صورت موازی اجرا شود بیتأثیر خواهد بود.
برای اطلاعات بیشتر در مورد تعریف استراتژیهای تکرار سفارشی، سعی مجدد و سیاست عقبنشینی را ببینید.
اگر خط مشی امتحان مجدد تعریف نشده یا تمام شده باشد، یا به حالتی برسید که در آن OneTimeWorkRequest
Result.failure()
را برمی گرداند، آن درخواست کاری و همه درخواست های کاری وابسته به عنوان FAILED.
همین منطق در هنگام لغو OneTimeWorkRequest
اعمال می شود. هر درخواست کاری وابسته نیز به CANCELLED
علامت گذاری شده است و کار آنها اجرا نمی شود.
توجه داشته باشید که اگر میخواهید درخواستهای کاری بیشتری را به زنجیرهای اضافه کنید که شکست خورده یا درخواستهای کاری را لغو کرده است، در این صورت درخواست کاری شما که به تازگی اضافه شده است نیز به ترتیب علامتگذاری FAILED
یا CANCELLED
میشود. اگر میخواهید کار یک زنجیره موجود را گسترش دهید، به APPEND_OR_REPLACE
در ExistingWorkPolicy مراجعه کنید.
هنگام ایجاد زنجیرهای از درخواستهای کاری، درخواستهای کاری وابسته باید سیاستهای تلاش مجدد را تعریف کنند تا اطمینان حاصل شود که کار همیشه بهموقع تکمیل میشود. درخواستهای کاری ناموفق میتواند منجر به زنجیره ناقص و/یا حالت غیرمنتظره شود.
برای اطلاعات بیشتر، لغو و توقف کار را ببینید.