زنجیر کاری

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 مراجعه کنید.

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

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

،

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 مراجعه کنید.

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

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

،

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 مراجعه کنید.

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

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