تسلسل الأعمال

يسمح لك WorkManager بإنشاء سلسلة عمل وإدراجها في قائمة الانتظار تحدد مهام تابعة متعددة وتحدد الترتيب الذي يجب تشغيلها به. هذا النمط تكون الوظائف مفيدة بشكل خاص عندما تحتاج إلى تشغيل عدة مهام في بترتيب معين.

لإنشاء سلسلة عمل، يمكنك استخدام WorkManager.beginWith(OneTimeWorkRequest) أو WorkManager.beginWith(List<OneTimeWorkRequest>) ، والتي يُرجع كل منها مثيلاً WorkContinuation

ويمكن بعد ذلك استخدام WorkContinuation لإضافة OneTimeWorkRequest تابع. الحالات التي تستخدم فيها then(OneTimeWorkRequest) أو then(List<OneTimeWorkRequest>) .

يؤدي كل استدعاء للسمة WorkContinuation.then(...) إلى عرض مثيل جديد من WorkContinuation. إذا أضفت List من إجمالي OneTimeWorkRequest حالة، من المحتمل أن يتم تنفيذ هذه الطلبات بالتوازي.

أخيرًا، يمكنك استخدام WorkContinuation.enqueue() إلى enqueue() لسلسلة WorkContinuations.

لنلقِ نظرة على مثال ما. في هذا المثال، هناك 3 مهام مختلفة للعامل مهيأ للتشغيل (من المحتمل أن يكون ذلك بالتوازي). وتكون نتائج هؤلاء العمال ثم انضمت ونقلت إلى وظيفة عامل التخزين المؤقت. أخيرًا، يمكن أن يكون ناتج ذلك وظيفة يتم تمريرها إلى عامل تحميل، وهو المسؤول عن تحميل النتائج إلى جهاز تحكم عن بُعد الخادم.

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 هي طريقة الدمج التلقائية. إذا كان هناك مفتاح التعارضات في عملية الدمج، فإن أحدث قيمة للمفتاح ستستبدل أي الإصدارات السابقة في بيانات الإخراج الناتجة.

على سبيل المثال، إذا كان لكل إدخال من إدخالات النباتات مفتاح يطابق كل منها أسماء المتغيرات ("plantName1" و"plantName2" و"plantName3")، ثم بحيث تتضمّن البيانات التي يتم تمريرها إلى عامل cache ثلاثة أزواج من المفاتيح والقيم.

إذا كان هناك تعارض، فإن العامل الأخير الذي أكمل "الفوز" وقيمته يتم تمريره إلى cache.

نظرًا لأنه يتم تنفيذ طلبات العمل بالتوازي، فليس لديك ضمانات بالترتيب الذي يتم تشغيله به. في المثال أعلاه، يمكن أن تتضمن السمة plantName1 قيمة إما "tulip" أو "elm"، بناءً على القيمة المكتوبة الأخير. إذا كان هناك فرصة لحدوث تعارض رئيسي وتحتاج إلى الاحتفاظ بجميع النتائج عند إجراء عملية دمج، قد تكون القيمة ArrayCreatingInputMerger خيارًا أفضل.

إنشاء خوارزمية دمج البيانات

بالنسبة للمثال أعلاه، نظرًا لأننا نريد الحفاظ على المخرجات من جميع النباتات باسم العمال، ينبغي لنا استخدام 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.

عند إنشاء سلاسل من طلبات العمل، يجب أن تحدد طلبات العمل التابعة إعادة محاولة تنفيذ السياسات لضمان إنجاز العمل دائمًا في الوقت المناسب. يمكن أن تؤدي طلبات العمل الفاشلة إلى سلاسل غير مكتملة و/أو حالة غير متوقعة.

لمزيد من المعلومات، يُرجى الاطّلاع على الإلغاء والإيقاف. العمل: