คู่มือเริ่มต้นใช้งานได้กล่าวถึงวิธีสร้าง WorkRequest
แบบง่าย
และจัดคิวใหม่
ในคู่มือนี้ คุณจะได้ทราบวิธีกำหนดและปรับแต่งออบเจ็กต์ WorkRequest
จัดการกรณีการใช้งานทั่วไป เช่น วิธีทำสิ่งต่อไปนี้
- กำหนดเวลาการทำงานแบบครั้งเดียวและแบบตามรอบ
- ตั้งค่าข้อจำกัดในการทำงาน เช่น ต้องใช้ Wi-Fi หรือการชาร์จ
- รับประกันความล่าช้าขั้นต่ำในการดำเนินการ
- กำหนดกลยุทธ์การลองใหม่และย้อนกลับ
- ส่งผ่านข้อมูลอินพุตไปยังการทำงาน
- จัดกลุ่มงานที่เกี่ยวข้องเข้าด้วยกันโดยใช้แท็ก
ภาพรวม
Work กำหนดใน WorkManager ผ่าน WorkRequest
หากต้องการ
กำหนดเวลางานใดๆ กับ WorkManager คุณต้องสร้าง
WorkRequest
ของออบเจ็กต์ แล้วจัดคิวเลย
Kotlin
val myWorkRequest = ... WorkManager.getInstance(myContext).enqueue(myWorkRequest)
Java
WorkRequest myWorkRequest = ... WorkManager.getInstance(myContext).enqueue(myWorkRequest);
ออบเจ็กต์ WorkRequest มีข้อมูลทั้งหมดที่ WorkManager จำเป็นต้องใช้เพื่อ ตั้งเวลาและเรียกใช้งาน ซึ่งรวมถึงข้อจำกัดที่ต้องปฏิบัติตาม งานที่เรียกใช้ ข้อมูลการจัดตารางเวลา เช่น ความล่าช้าหรือช่วงเวลาที่เกิดซ้ำ ลองใหม่ การกำหนดค่าของคุณ และอาจรวมถึงข้อมูลอินพุตในกรณีที่งานของคุณต้องใช้ข้อมูลดังกล่าว
WorkRequest
เองก็เป็นคลาสฐานแบบนามธรรม มี 2 แบบ
การติดตั้งใช้งานที่ได้รับคลาสนี้ซึ่งคุณสามารถใช้เพื่อสร้างคำขอ
OneTimeWorkRequest
และ PeriodicWorkRequest
OneTimeWorkRequest
มีประโยชน์สำหรับการจัดตารางเวลาเพราะชื่อที่บอกเป็นนัย
ไม่ทำซ้ำ แต่ PeriodicWorkRequest
จะเหมาะสำหรับ
งานที่ต้องตั้งเวลาซึ่งเกิดซ้ำในแต่ละช่วง
กำหนดเวลาทำงานแบบครั้งเดียว
สำหรับงานง่ายๆ ซึ่งไม่ต้องมีการกำหนดค่าเพิ่มเติม ให้ใช้แท็ก
เมธอด from
:
Kotlin
val myWorkRequest = OneTimeWorkRequest.from(MyWork::class.java)
Java
WorkRequest myWorkRequest = OneTimeWorkRequest.from(MyWork.class);
สำหรับงานที่ซับซ้อนมากขึ้น คุณสามารถใช้เครื่องมือสร้างได้ ดังนี้
Kotlin
val uploadWorkRequest: WorkRequest = OneTimeWorkRequestBuilder<MyWork>() // Additional configuration .build()
Java
WorkRequest uploadWorkRequest = new OneTimeWorkRequest.Builder(MyWork.class) // Additional configuration .build();
กำหนดเวลางานด่วน
WorkManager 2.7.0 ได้นำเสนอแนวคิดของการทำงานเร่งด่วน วิธีนี้ช่วยให้ WorkManager เพื่อดำเนินการสำคัญในขณะเดียวกันก็ให้ระบบควบคุมได้ดียิ่งขึ้น การเข้าถึงทรัพยากร
งานแบบด่วนมีความโดดเด่นในด้านลักษณะต่อไปนี้
- ความสำคัญ: การทำงานที่รวดเร็วเหมาะกับงานที่สำคัญสำหรับผู้ใช้ หรือ เริ่มต้นโดยผู้ใช้
- ความเร็ว: งานด่วนจะเหมาะกับงานสั้นๆ ที่เริ่มทันทีและ เสร็จสมบูรณ์ภายในไม่กี่นาที
- โควต้า: โควต้าระดับระบบซึ่งจำกัดเวลาการดำเนินการในเบื้องหน้า จะกำหนดว่างานด่วนสามารถเริ่มต้นได้หรือไม่
- การจัดการพลังงาน: ข้อจํากัดการจัดการพลังงาน เช่น แบตเตอรี่ โหมดประหยัดและ Doze มีแนวโน้มที่จะส่งผลต่องานที่ต้องเร่งรีบน้อยกว่า
- เวลาในการตอบสนอง: ระบบจะทำงานด่วนทันที โดยมีเงื่อนไขดังนี้ ภาระงานปัจจุบันของระบบ ช่วยให้ทำเช่นนั้นได้ ซึ่งหมายความว่า ใช้เวลาในการตอบสนอง มีความละเอียดอ่อนและกำหนดเวลาสำหรับการดำเนินการในภายหลังไม่ได้
กรณีการใช้งานงานที่อาจเป็นงานด่วนอาจอยู่ในแอปแชทเมื่อผู้ใช้ ต้องการส่งข้อความหรือรูปภาพที่แนบ ในทำนองเดียวกัน แอปที่จัดการกับ ขั้นตอนการชำระเงินหรือการสมัครใช้บริการก็อาจต้องการใช้แบบเร่งด่วนด้วย นี่คือ เนื่องจากงานเหล่านั้นสำคัญกับผู้ใช้ ให้ดำเนินการได้อย่างรวดเร็วใน พื้นหลัง ต้องเริ่มต้นทันที และควรดำเนินการต่อไปแม้ว่า ผู้ใช้ปิดแอป
โควต้า
ระบบจะต้องจัดสรรเวลาปฏิบัติการให้กับงานที่ต้องเร่งดำเนินการก่อน สามารถทำงานได้ ไม่มีการจำกัดเวลาดำเนินการ แต่แต่ละแอปจะได้รับโควต้า ของระยะเวลาดำเนินการ เมื่อแอปใช้เวลาดำเนินการและเวลาถึง โควต้าที่จัดสรร คุณจะไม่สามารถทำงานด่วนได้อีกจนกว่าจะถึงโควต้า รีเฟรช วิธีนี้ทำให้ Android สามารถรักษาสมดุลระหว่างทรัพยากรระหว่าง แอปพลิเคชัน
ระยะเวลาในการดำเนินการที่แอปใช้ได้จะขึ้นอยู่กับ ที่เก็บข้อมูลสแตนด์บายและความสำคัญของกระบวนการ
คุณสามารถระบุสิ่งที่เกิดขึ้นเมื่อโควต้าการดำเนินการไม่อนุญาต งานที่เร่งรัดให้เรียกใช้ทันที ดูรายละเอียดจากข้อมูลโค้ดด้านล่าง
กำลังทำงานด่วน
ตั้งแต่ใน WorkManager 2.7 เป็นต้นไป แอปจะเรียกใช้ setExpedited()
เพื่อประกาศว่าดังกล่าวได้
WorkRequest
ควรทำงานโดยเร็วที่สุดโดยใช้งานแบบเร่งด่วน
ข้อมูลโค้ดต่อไปนี้แสดงตัวอย่างวิธีใช้ setExpedited()
Kotlin
val request = OneTimeWorkRequestBuilder<SyncWorker>() .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) .build() WorkManager.getInstance(context) .enqueue(request)
Java
OneTimeWorkRequest request = new OneTimeWorkRequestBuilder<T>() .setInputData(inputData) .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) .build();
ในตัวอย่างนี้ เราเริ่มต้นอินสแตนซ์ของ OneTimeWorkRequest
และเรียก
setExpedited()
ในนั้น หลังจากนั้นคําขอนี้จะเป็นการดำเนินการแบบเร่งด่วน หากโควต้า
โฆษณาจะเริ่มต้นทำงานในพื้นหลังทันที หากโควต้ามี
ใช้แล้ว พารามิเตอร์ OutOfQuotaPolicy
บ่งชี้ว่าคำขอ
ทำงานเป็นปกติโดยไม่ต้องเร่งด่วน
ความเข้ากันได้แบบย้อนหลังและบริการที่ทำงานอยู่เบื้องหน้า
WorkManager อาจเรียกใช้บริการที่ทำงานอยู่เบื้องหน้าในแพลตฟอร์มเวอร์ชันเก่ากว่า Android 12 เพื่อรักษาความเข้ากันได้แบบย้อนหลังสำหรับงานด่วน บริการที่ทำงานอยู่เบื้องหน้าแสดงการแจ้งเตือนแก่ผู้ใช้ได้
เมธอด getForegroundInfoAsync()
และ getForegroundInfo()
ใน Worker
เปิดใช้ WorkManager เพื่อแสดงการแจ้งเตือนเมื่อคุณเรียกใช้ setExpedited()
ก่อน Android 12
ListenableWorker
ต้องใช้เมธอด getForegroundInfo
หากคุณ
ต้องการขอให้เรียกใช้งานนี้เป็นงานด่วน
เมื่อกำหนดเป้าหมายเป็น Android 12 ขึ้นไป บริการที่ทำงานอยู่เบื้องหน้าจะยังคงใช้งานได้สำหรับ
ผ่านเมธอด setForeground
ที่เกี่ยวข้อง
ผู้ปฏิบัติงาน
ผู้ปฏิบัติงานไม่ทราบว่างานที่ตนทำนั้นเป็นงานที่เร่งด่วนหรือไม่ แต่
ผู้ปฏิบัติงานสามารถแสดงการแจ้งเตือนบน Android บางเวอร์ชันเมื่อ
เราได้เร่งดำเนินการ WorkRequest
แล้ว
หากต้องการเปิดใช้ WorkManager จะให้เมธอด getForegroundInfoAsync()
แก่คุณ
ซึ่งต้องติดตั้งใช้งานเพื่อให้ WorkManager แสดงการแจ้งเตือนเพื่อเริ่มต้น
ForegroundService
ให้ตามที่จำเป็น
พนักงาน Coroutine
หากใช้ CoroutineWorker
คุณต้องใช้ getForegroundInfo()
จากนั้น
ส่งไปยัง setForeground()
ภายใน doWork()
การทำเช่นนี้จะสร้าง
ใน Android เวอร์ชันก่อน 12
ลองดูตัวอย่างต่อไปนี้
class ExpeditedWorker(appContext: Context, workerParams: WorkerParameters):
CoroutineWorker(appContext, workerParams) {
override suspend fun getForegroundInfo(): ForegroundInfo {
return ForegroundInfo(
NOTIFICATION_ID, createNotification()
)
}
override suspend fun doWork(): Result {
TODO()
}
private fun createNotification() : Notification {
TODO()
}
}
นโยบายโควต้า
คุณควบคุมสิ่งที่จะเกิดขึ้นกับงานที่ต้องเร่งรีบได้เมื่อแอปทำงาน
โควต้าการใช้งาน หากต้องการดำเนินการต่อ คุณสามารถส่งผ่าน setExpedited()
:
OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST
ซึ่งทำให้งาน ทำงานเป็นคำขอทำงานทั่วไป ตัวอย่างข้อมูลข้างต้นแสดงให้เห็นสิ่งนี้OutOfQuotaPolicy.DROP_WORK_REQUEST
ซึ่งจะทำให้คำขอยกเลิกหาก มีโควต้าไม่เพียงพอ
แอปตัวอย่าง
หากต้องการดูตัวอย่างที่สมบูรณ์ของวิธีที่ WorkManager 2.7.0 ใช้การทำงานแบบเร่ง โปรดดูที่ ผ่าน WorkManagerSample ใน GitHub
งานด่วนที่มีการเลื่อนเวลา
ระบบจะพยายามทำงานด่วนที่ได้รับโดยเร็วที่สุดหลังจาก ถูกเรียกใช้ แต่เช่นเดียวกับงานประเภทอื่นๆ ระบบ อาจเลื่อนเวลาเริ่มงานใหม่ที่เร่งรัดออกไป ดังเช่นในกรณีต่อไปนี้
- โหลด: ภาระงานของระบบสูงเกินไป ซึ่งอาจเกิดขึ้นได้เมื่อมีงานมากเกินไป ทำงานอยู่แล้ว หรือเมื่อระบบมีหน่วยความจำไม่เพียงพอ
- โควต้า: เกินโควต้างานแบบเร่งด่วนแล้ว งานด่วน ใช้ระบบโควต้าที่อิงตามที่เก็บข้อมูลสแตนด์บายแอปและจำกัด เวลาดำเนินการสูงสุดภายในกรอบเวลาต่อเนื่อง โควต้าที่ใช้สำหรับ งานที่ต้องเร่งรัดจะมีความเข้มงวดมากกว่างานด่วนประเภทอื่นๆ งานในเบื้องหลัง
กำหนดเวลางานเป็นระยะ
บางครั้งแอปอาจกำหนดให้ทำงานบางอย่างเป็นระยะๆ ตัวอย่างเช่น คุณอาจต้องสำรองข้อมูลเป็นระยะๆ ดาวน์โหลดเนื้อหาใหม่ๆ ใน หรืออัปโหลดบันทึกไปยังเซิร์ฟเวอร์
ต่อไปนี้คือวิธีใช้ PeriodicWorkRequest
เพื่อสร้าง
WorkRequest
ออบเจ็กต์ที่จะทำงานเป็นระยะ:
Kotlin
val saveRequest = PeriodicWorkRequestBuilder<SaveImageToFileWorker>(1, TimeUnit.HOURS) // Additional configuration .build()
Java
PeriodicWorkRequest saveRequest = new PeriodicWorkRequest.Builder(SaveImageToFileWorker.class, 1, TimeUnit.HOURS) // Constraints .build();
ในตัวอย่างนี้ งานจะวางกำหนดเวลาไว้ที่ช่วงเวลา 1 ชั่วโมง
ช่วงการฝึกหมายถึงเวลาขั้นต่ำระหว่างการเกิดซ้ำ เวลาที่พนักงานจะทำงานจริงจะขึ้นอยู่กับข้อจำกัด ที่คุณใช้ในออบเจ็กต์ WorkRequest และในการเพิ่มประสิทธิภาพที่ดำเนินการ จากระบบ
ช่วงเวลาการทำงานที่ยืดหยุ่น
หากลักษณะของงานทำให้เวลาในการเรียกใช้มีความละเอียดอ่อน คุณก็กำหนดค่า
PeriodicWorkRequest
ของคุณให้ทำงานภายในแบบยืดหยุ่น
ระยะเวลา ในแต่ละช่วง ดังที่แสดงในรูปที่ 1
รูปที่ 1 แผนภาพแสดงช่วงการเกิดซ้ำซึ่งมีระยะเวลาที่ยืดหยุ่นใน ที่จะทำงานได้
หากต้องการกำหนดงานที่มีระยะเวลายืดหยุ่น คุณจะต้องส่ง flexInterval
พร้อมด้วย
repeatInterval
เมื่อสร้าง PeriodicWorkRequest
ระยะเวลาแบบยืดหยุ่น
เริ่มที่ repeatInterval - flexInterval
และไปยังจุดสิ้นสุดของช่วงเวลา
ตัวอย่างงานตามรอบระยะเวลาที่ทำได้ในช่วง 15 เดือนที่ผ่านมามีดังนี้ นาทีของทุก 1 ชั่วโมง
Kotlin
val myUploadWork = PeriodicWorkRequestBuilder<SaveImageToFileWorker>( 1, TimeUnit.HOURS, // repeatInterval (the period cycle) 15, TimeUnit.MINUTES) // flexInterval .build()
Java
WorkRequest saveRequest = new PeriodicWorkRequest.Builder(SaveImageToFileWorker.class, 1, TimeUnit.HOURS, 15, TimeUnit.MINUTES) .build();
ช่วงเวลาการทำซ้ำต้องมากกว่าหรือเท่ากับ
PeriodicWorkRequest.MIN_PERIODIC_INTERVAL_MILLIS
กับเบ่งกล้าม
ช่วงเวลาต้องมากกว่าหรือเท่ากับ
PeriodicWorkRequest.MIN_PERIODIC_FLEX_MILLIS
ผลกระทบของข้อจำกัดต่องานตามระยะเวลา
คุณอาจใช้ข้อจำกัดกับงานเป็นระยะได้ เช่น คุณอาจเพิ่ม
ในคำของานของคุณ เพื่อให้งานทำงานเฉพาะเมื่อผู้ใช้
กำลังชาร์จอุปกรณ์อยู่ ในกรณีนี้ แม้ว่าช่วงเวลาการทำซ้ำที่กำหนดไว้จะผ่านไปแล้ว
PeriodicWorkRequest
จะไม่ทำงานจนกว่าจะเป็นไปตามเงื่อนไขนี้ การดำเนินการนี้อาจ
ทำให้การทำงานของคุณล่าช้า หรือแม้กระทั่งข้าม
ไม่ตรงตามเงื่อนไขภายในช่วงการเรียกใช้
ข้อจำกัดในการทำงาน
ข้อจำกัดจะเลื่อนงานจนกว่าจะเป็นไปตามเงื่อนไขที่ดีที่สุด ข้อจำกัดต่อไปนี้พร้อมใช้งานใน WorkManager
ประเภทเครือข่าย | จำกัดประเภทเครือข่ายที่จำเป็นต่อการทำงาน
เช่น Wi-Fi (UNMETERED )
|
แบตเตอรี่ไม่ต่ำ | เมื่อตั้งค่าเป็น "จริง" งานจะไม่ทำงานหากอุปกรณ์อยู่ในโหมดแบตเตอรี่ต่ำ |
ต้องชาร์จ | เมื่อตั้งค่าเป็น "จริง" งานของคุณจะทำงานเมื่ออุปกรณ์ชาร์จอยู่เท่านั้น |
ไม่มีการใช้งานอุปกรณ์ | เมื่อตั้งค่าเป็น "จริง" การดำเนินการนี้กำหนดให้ผู้ใช้ต้องไม่มีการใช้งานอุปกรณ์ของผู้ใช้ก่อนที่จะทำงาน ซึ่งจะมีประโยชน์สำหรับการเรียกใช้การดำเนินการแบบกลุ่ม ซึ่งอาจส่งผลเสียต่อประสิทธิภาพการทำงานของแอปอื่นๆ ที่ทำงานอยู่ในอุปกรณ์ของผู้ใช้ |
พื้นที่เก็บข้อมูลไม่ต่ำ | เมื่อตั้งค่าเป็น "จริง" งานของคุณจะไม่ทำงานหากพื้นที่เก็บข้อมูลของผู้ใช้ในอุปกรณ์ต่ำเกินไป |
หากต้องการสร้างชุดข้อจำกัดและเชื่อมโยงกับงานบางงาน ให้สร้าง
Constraints
ที่ใช้ Contraints.Builder()
และมอบหมายให้กับอินสแตนซ์
WorkRequest.Builder()
ตัวอย่างเช่น โค้ดต่อไปนี้สร้างคำของานซึ่งเรียกใช้เมื่อ อุปกรณ์ของผู้ใช้กำลังชาร์จและเชื่อมต่อ Wi-Fi อยู่
Kotlin
val constraints = Constraints.Builder() .setRequiredNetworkType(NetworkType.UNMETERED) .setRequiresCharging(true) .build() val myWorkRequest: WorkRequest = OneTimeWorkRequestBuilder<MyWork>() .setConstraints(constraints) .build()
Java
Constraints constraints = new Constraints.Builder() .setRequiredNetworkType(NetworkType.UNMETERED) .setRequiresCharging(true) .build(); WorkRequest myWorkRequest = new OneTimeWorkRequest.Builder(MyWork.class) .setConstraints(constraints) .build();
เมื่อระบุข้อจำกัดหลายข้อ งานของคุณจะทำงานเฉพาะเมื่อ เป็นไปตามเงื่อนไขที่กำหนด
ในกรณีที่ไม่มีข้อจำกัดขณะที่งานกำลังทำงาน WorkManager จะหยุดผู้ปฏิบัติงานของคุณ จากนั้นงานจะถูกลองใหม่เมื่อ เป็นไปตามเงื่อนไขที่กำหนด
งานที่ล่าช้า
ในกรณีที่งานของคุณไม่มีข้อจำกัด หรือมีข้อจำกัดทั้งหมด เมื่องานของคุณได้รับการจัดคิว ระบบอาจเลือกที่จะเรียกใช้งานนั้น ทันที หากคุณไม่ต้องการให้งานถูกเรียกใช้ทันที คุณสามารถระบุ งานจะเริ่มต้นหลังจากความล่าช้าเริ่มต้นขั้นต่ำ
ตัวอย่างวิธีตั้งค่างานให้ทํางานหลังจากงานดังกล่าวอย่างน้อย 10 นาทีมีดังนี้ อยู่ในคิวแล้ว
Kotlin
val myWorkRequest = OneTimeWorkRequestBuilder<MyWork>() .setInitialDelay(10, TimeUnit.MINUTES) .build()
Java
WorkRequest myWorkRequest = new OneTimeWorkRequest.Builder(MyWork.class) .setInitialDelay(10, TimeUnit.MINUTES) .build();
ขณะที่ตัวอย่างจะแสดงวิธีตั้งค่าการหน่วงเวลาขั้นต้นสำหรับ
OneTimeWorkRequest
คุณยังตั้งการหน่วงเวลาขั้นต้นสำหรับ
PeriodicWorkRequest
ในกรณีดังกล่าว เฉพาะการเรียกใช้งานตามรอบครั้งแรกเท่านั้น
อาจล่าช้า
นโยบายการลองใหม่และย้อนกลับ
หากต้องการให้ WorkManager ลองทำงานอีกครั้ง คุณจะส่งคืนได้
Result.retry()
จากผู้ปฏิบัติงาน ตอนนี้
กําหนดเวลาใหม่ตามความล่าช้าของการย้อนกลับและนโยบายย้อนกลับ
การหน่วงเวลาแบ็กออฟระบุระยะเวลาขั้นต่ำที่จะรอก่อนที่จะลองอีกครั้ง งานของคุณหลังจากความพยายามครั้งแรก ค่านี้ต้องไม่น้อยกว่า 10 วินาที (หรือ MIN_BACKOFF_MILLIS)
นโยบาย Backoff กำหนดว่าจะให้การหน่วงเวลา Backoff เพิ่มขึ้นอย่างไรเมื่อเวลาผ่านไป ความพยายามซ้ำในครั้งต่อๆ ไป WorkManager รองรับนโยบาย Backoff 2 นโยบาย
LINEAR
และEXPONENTIAL
คำของานทุกรายการมีนโยบาย Backoff และ Backoff Delay นโยบายเริ่มต้น
คือ EXPONENTIAL
โดยมีความล่าช้า 30 วินาที แต่คุณสามารถลบล้างค่านี้ได้ใน
การกำหนดค่าคำขอทำงาน
ตัวอย่างการปรับการหน่วงเวลา Backoff และนโยบายมีดังนี้
Kotlin
val myWorkRequest = OneTimeWorkRequestBuilder<MyWork>() .setBackoffCriteria( BackoffPolicy.LINEAR, OneTimeWorkRequest.MIN_BACKOFF_MILLIS, TimeUnit.MILLISECONDS) .build()
Java
WorkRequest myWorkRequest = new OneTimeWorkRequest.Builder(MyWork.class) .setBackoffCriteria( BackoffPolicy.LINEAR, OneTimeWorkRequest.MIN_BACKOFF_MILLIS, TimeUnit.MILLISECONDS) .build();
ในตัวอย่างนี้ การหน่วงเวลา Backoff ขั้นต่ำจะตั้งเป็นค่าขั้นต่ำที่อนุญาต
10 วินาที เนื่องจากนโยบายคือ LINEAR
ช่วงการลองใหม่จะเพิ่มขึ้น
ประมาณ 10 วินาทีเมื่อมีการพยายามใหม่แต่ละครั้ง ตัวอย่างเช่น การเรียกใช้ครั้งแรก
การพยายามดำเนินการให้เสร็จสิ้นด้วย Result.retry()
อีกครั้งหลังจาก 10 วินาที
ตามด้วย 20, 30, 40 และต่อไปเรื่อยๆ หากงานยังคงส่งคืน
Result.retry()
หลังจากความพยายามครั้งต่อๆ ไป หากตั้งค่านโยบาย Backoff เป็น
EXPONENTIAL
ลําดับของระยะเวลาการลองอีกครั้งจะใกล้เคียงกับ 20, 40, 80 เป็นต้น
เปิดอยู่
แท็กงาน
คำของานทุกรายการจะมีตัวระบุที่ไม่ซ้ำกันซึ่งใช้เพื่อระบุ ที่ทํางานในภายหลังเพื่อยกเลิกงานหรือสังเกตความคืบหน้า
หากคุณมีกลุ่มของงานที่เกี่ยวข้องเชิงตรรกะ อาจเป็นประโยชน์ในการ แท็กรายการงานเหล่านั้น การติดแท็กช่วยให้คุณดำเนินการกับกลุ่มงานได้ คำขอไว้ด้วยกัน
เช่น WorkManager.cancelAllWorkByTag(String)
ยกเลิก
คำของานทั้งหมดที่มีแท็กหนึ่งๆ และ
WorkManager.getWorkInfosByTag(String)
แสดงรายการของ
ออบเจ็กต์ WorkInfo ที่ใช้ระบุสถานะการทำงานปัจจุบันได้
โค้ดต่อไปนี้แสดงวิธีการเพิ่ม "การล้าง" แท็กไปที่งานของคุณ:
Kotlin
val myWorkRequest = OneTimeWorkRequestBuilder<MyWork>() .addTag("cleanup") .build()
Java
WorkRequest myWorkRequest = new OneTimeWorkRequest.Builder(MyWork.class) .addTag("cleanup") .build();
ในข้อสุดท้าย คุณจะเพิ่มแท็กหลายรายการในคำของานรายการเดียวได้ เป็นการภายใน
แท็กจะจัดเก็บเป็นชุดสตริง วิธีรับชุดแท็กที่เชื่อมโยงกับ
WorkRequest
คุณจะใช้ WorkInfo.getTags() ได้
จากคลาส Worker
คุณเรียกข้อมูลชุดแท็กของแท็กได้ผ่านทาง
ListenableWorker.getTags()
กำหนดข้อมูลอินพุต
งานของคุณอาจต้องป้อนข้อมูลจึงจะทำงานได้ ตัวอย่างเช่น งานที่ แฮนเดิลที่อัปโหลดรูปภาพอาจต้องใช้ URI ของรูปภาพที่ต้องอัปโหลดเป็น อินพุต
ค่าที่ป้อนจะจัดเก็บเป็นคู่คีย์-ค่าในออบเจ็กต์ Data
และสามารถตั้งค่าในคำของาน WorkManager จะส่งอินพุต Data
ไปยัง
ของคุณในขณะทำงาน ชั้นเรียน Worker
สามารถเข้าถึงได้
อาร์กิวเมนต์อินพุตโดยเรียกใช้ Worker.getInputData()
โค้ดด้านล่างแสดงวิธีสร้างอินสแตนซ์ Worker
ซึ่ง
ซึ่งต้องใช้ข้อมูลที่ป้อนและวิธีส่งในคำของาน
Kotlin
// Define the Worker requiring input class UploadWork(appContext: Context, workerParams: WorkerParameters) : Worker(appContext, workerParams) { override fun doWork(): Result { val imageUriInput = inputData.getString("IMAGE_URI") ?: return Result.failure() uploadFile(imageUriInput) return Result.success() } ... } // Create a WorkRequest for your Worker and sending it input val myUploadWork = OneTimeWorkRequestBuilder<UploadWork>() .setInputData(workDataOf( "IMAGE_URI" to "http://..." )) .build()
Java
// Define the Worker requiring input public class UploadWork extends Worker { public UploadWork(Context appContext, WorkerParameters workerParams) { super(appContext, workerParams); } @NonNull @Override public Result doWork() { String imageUriInput = getInputData().getString("IMAGE_URI"); if(imageUriInput == null) { return Result.failure(); } uploadFile(imageUriInput); return Result.success(); } ... } // Create a WorkRequest for your Worker and sending it input WorkRequest myUploadWork = new OneTimeWorkRequest.Builder(UploadWork.class) .setInputData( new Data.Builder() .putString("IMAGE_URI", "http://...") .build() ) .build();
ในทำนองเดียวกัน คุณสามารถใช้คลาส Data
เพื่อเอาต์พุตค่าผลลัพธ์ อินพุตและ
ข้อมูลเอาต์พุตครอบคลุมรายละเอียดเพิ่มเติมในส่วนพารามิเตอร์อินพุตและ
ผลลัพธ์
ขั้นตอนถัดไป
ดูข้อมูลเพิ่มเติมเกี่ยวกับสถานะงานได้ในหน้ารัฐและการสังเกตการณ์ และวิธีตรวจสอบความคืบหน้าของงาน