עבודות שרשור

‫WorkManager מאפשר ליצור ולהוסיף לתור שרשרת של עבודות שמציינת כמה משימות תלויות ומגדירה את הסדר שבו הן צריכות לפעול. הפונקציונליות הזו שימושית במיוחד כשצריך להריץ כמה משימות בסדר מסוים.

כדי ליצור שרשרת של עבודות, אפשר להשתמש ב-WorkManager.beginWith(OneTimeWorkRequest) או ב-WorkManager.beginWith(List<OneTimeWorkRequest>), שכל אחת מהן מחזירה מופע של WorkContinuation.

אחר כך אפשר להשתמש ב-WorkContinuation כדי להוסיף מופעים של OneTimeWorkRequest שתלויים ב-WorkContinuation באמצעות then(OneTimeWorkRequest) או then(List<OneTimeWorkRequest>).

כל הפעלה של WorkContinuation.then(...) מחזירה מופע חדש של WorkContinuation. אם מוסיפים List מופעים של OneTimeWorkRequest, הבקשות האלה יכולות לפעול במקביל.

לבסוף, אפשר להשתמש בשיטה WorkContinuation.enqueue() כדי enqueue() את השרשרת של WorkContinuation.

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

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

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

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

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

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

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

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

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