يسمح لك 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 مهام مختلفة للعامل مهيأ للتشغيل (من المحتمل أن يكون ذلك بالتوازي). وتكون نتائج هؤلاء العمال ثم انضمت ونقلت إلى وظيفة عامل التخزين المؤقت. أخيرًا، يمكن أن يكون ناتج ذلك وظيفة يتم تمريرها إلى عامل تحميل، وهو المسؤول عن تحميل النتائج إلى جهاز تحكم عن بُعد الخادم.
Kotlin
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()
Java
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
هي طريقة الدمج التلقائية. إذا كان هناك مفتاح
التعارضات في عملية الدمج، فإن أحدث قيمة للمفتاح ستستبدل أي
الإصدارات السابقة في بيانات الإخراج الناتجة.
على سبيل المثال، إذا كان لكل إدخال من إدخالات النباتات مفتاح يطابق كل منها
أسماء المتغيرات ("plantName1"
و"plantName2"
و"plantName3"
)، ثم
بحيث تتضمّن البيانات التي يتم تمريرها إلى عامل cache
ثلاثة أزواج من المفاتيح والقيم.
إذا كان هناك تعارض، فإن العامل الأخير الذي أكمل "الفوز" وقيمته
يتم تمريره إلى cache
.
نظرًا لأنه يتم تنفيذ طلبات العمل بالتوازي، فليس لديك ضمانات
بالترتيب الذي يتم تشغيله به. في المثال أعلاه، يمكن أن تتضمن السمة plantName1
قيمة إما "tulip"
أو "elm"
، بناءً على القيمة المكتوبة
الأخير. إذا كان هناك فرصة لحدوث تعارض رئيسي وتحتاج إلى الاحتفاظ بجميع النتائج
عند إجراء عملية دمج، قد تكون القيمة ArrayCreatingInputMerger
خيارًا أفضل.
إنشاء خوارزمية دمج البيانات
بالنسبة للمثال أعلاه، نظرًا لأننا نريد الحفاظ على المخرجات من جميع النباتات
باسم العمال، ينبغي لنا استخدام ArrayCreatingInputMerger
.
Kotlin
val cache: OneTimeWorkRequest = OneTimeWorkRequestBuilder<PlantWorker>() .setInputMerger(ArrayCreatingInputMerger::class) .setConstraints(constraints) .build()
Java
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.
عند إنشاء سلاسل من طلبات العمل، يجب أن تحدد طلبات العمل التابعة إعادة محاولة تنفيذ السياسات لضمان إنجاز العمل دائمًا في الوقت المناسب. يمكن أن تؤدي طلبات العمل الفاشلة إلى سلاسل غير مكتملة و/أو حالة غير متوقعة.
لمزيد من المعلومات، يُرجى الاطّلاع على الإلغاء والإيقاف. العمل: