زنجیر کاری

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 = OneTimeWorkRequestBuilder<PlantWorker>()
   .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 مراجعه کنید.

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

برای اطلاعات بیشتر، لغو و توقف کار را ببینید.