עבודות שרשור

‫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.

נבחן עכשיו דוגמה. בדוגמה הזו, מוגדרות 3 משימות שונות של Worker להפעלה (יכול להיות שהן יפעלו במקביל). התוצאות של ה-Workers האלה מצורפות ומועברות למשימת 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 מתווספת לתור בשרשרת של בקשות עבודה, כל בקשות העבודה הבאות נחסמות עד שהעבודה של בקשת העבודה הראשונה מסתיימת.

אחרי שהבקשה מתווספת לתור וכל אילוצי העבודה מתקיימים, בקשת העבודה הראשונה מתחילה לפעול. אם העבודה הושלמה בהצלחה ב-root OneTimeWorkRequest או List<OneTimeWorkRequest> (כלומר, היא מחזירה Result.success()), אז קבוצת הבקשות הבאה של עבודות תלויות תתווסף לתור.

כל עוד כל בקשה לעבודה מסתיימת בהצלחה, אותה תבנית מועברת דרך שאר הבקשות בשרשרת עד שכל העבודה בשרשרת מסתיימת. זהו התרחיש הפשוט והמועדף, אבל חשוב באותה מידה לטפל במצבי שגיאה.

אם מתרחשת שגיאה בזמן שעובד מעבד את בקשת העבודה שלכם, אתם יכולים לנסות שוב את הבקשה בהתאם למדיניות ההשהיה לפני ניסיון חוזר (backoff) שהגדרתם. ניסיון חוזר לשליחת בקשה שהיא חלק משרשרת, פירושו שניסיון חוזר ייעשה רק לבקשה הזו עם נתוני הקלט שסופקו לה. העבודה שמתבצעת במקביל לא תיפגע.

מידע נוסף על הגדרת אסטרטגיות מותאמות אישית לניסיון חוזר זמין במאמר מדיניות בנושא ניסיון חוזר והשהיה.

אם מדיניות הניסיון החוזר לא מוגדרת או שהניסיונות החוזרים מוצו, או אם מגיעים למצב שבו OneTimeWorkRequest מחזירה Result.failure(), בקשת העבודה הזו וכל בקשות העבודה שתלויות בה מסומנות כ-FAILED.

אותה לוגיקה חלה גם כשמבטלים OneTimeWorkRequest. גם בקשות עבודה תלויות מסומנות בסימן CANCELLED והעבודה שלהן לא תבוצע.

חשוב לדעת: אם תוסיפו בקשות עבודה נוספות לשרשרת שנכשלה או שבוטלו בה בקשות עבודה, בקשת העבודה החדשה שתוסיפו תסומן גם היא בסימן FAILED או CANCELLED, בהתאם. אם רוצים להרחיב את העבודה של שרשרת קיימת, אפשר לעיין בAPPEND_OR_REPLACE בExistingWorkPolicy.

כשיוצרים שרשרות של בקשות עבודה, בקשות עבודה תלויות צריכות להגדיר מדיניות ניסיון חוזר כדי להבטיח שהעבודה תמיד תושלם בזמן. בקשות עבודה שנכשלו עלולות לגרום לשרשרות לא שלמות או למצב לא צפוי.

מידע נוסף זמין במאמר ביטול והפסקה של עבודה.