คู่มือเริ่มต้นใช้งานอธิบายวิธีสร้าง WorkRequest
แบบง่ายและจัดคิว
ในคู่มือนี้ คุณจะได้เรียนรู้วิธีกําหนดและปรับแต่งออบเจ็กต์ WorkRequest
เพื่อจัดการกรณีการใช้งานที่พบบ่อย เช่น วิธีต่อไปนี้
- กำหนดเวลางานแบบครั้งเดียวและแบบที่เกิดซ้ำ
- กำหนดข้อจำกัดของงาน เช่น ต้องมี Wi-Fi หรือการชาร์จ
- รับประกันความล่าช้าขั้นต่ำในการดําเนินการ
- ตั้งค่ากลยุทธ์การลองอีกครั้งและการหยุด
- ส่งข้อมูลอินพุตให้ทํางาน
- จัดกลุ่มงานที่เกี่ยวข้องไว้ด้วยกันโดยใช้แท็ก
ภาพรวม
งานจะกำหนดไว้ใน 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 ทำงานที่สำคัญได้ ขณะที่ให้ระบบควบคุมการเข้าถึงทรัพยากรได้ดียิ่งขึ้น
งานด่วนมีลักษณะดังต่อไปนี้
- ความสำคัญ: งานเร่งด่วนเหมาะกับงานที่มีความสำคัญต่อผู้ใช้หรือผู้ใช้เป็นผู้เริ่ม
- ความเร็ว: เหมาะสำหรับงานสั้นๆ ที่เริ่มต้นทันทีและเสร็จสมบูรณ์ภายในไม่กี่นาที
- โควต้า: โควต้าระดับระบบที่จำกัดเวลาการเรียกใช้เบื้องหน้าเพื่อพิจารณาว่างานเร่งด่วนจะเริ่มได้หรือไม่
- การจัดการพลังงาน: ข้อจำกัดด้านการจัดการพลังงาน เช่น โหมดประหยัดแบตเตอรี่และโหมดสลีป มีแนวโน้มที่จะส่งผลต่อการทำงานแบบเร่งด่วนน้อยลง
- เวลาในการตอบสนอง: ระบบจะดําเนินการงานเร่งด่วนทันที หากภาระงานปัจจุบันของระบบทําให้ดําเนินการดังกล่าวได้ ซึ่งหมายความว่างานเหล่านี้จะมีความไวต่อเวลาในการตอบสนองและไม่สามารถกําหนดเวลาให้ดําเนินการในภายหลังได้
Use Case ที่เป็นไปได้สําหรับงานที่เร่งด่วนอาจอยู่ภายในแอปรับส่งข้อความเมื่อผู้ใช้ต้องการส่งข้อความหรือรูปภาพที่แนบมา ในทำนองเดียวกัน แอปที่จัดการขั้นตอนการชําระเงินหรือการสมัครใช้บริการก็อาจต้องการใช้การทํางานแบบเร่งด่วนด้วย เนื่องจากงานเหล่านั้นสำคัญต่อผู้ใช้ ทำงานได้อย่างรวดเร็วในเบื้องหลัง ต้องเริ่มต้นทันที และควรทำงานต่อไปแม้ว่าผู้ใช้จะปิดแอปแล้วก็ตาม
โควต้า
ระบบต้องจัดสรรเวลาดำเนินการให้กับงานที่เร่งด่วนก่อนจึงจะทำงานได้ เวลาดำเนินการมีขีดจํากัด แต่แอปแต่ละแอปจะได้รับโควต้าของเวลาดำเนินการ เมื่อแอปใช้เวลาในการดำเนินการและถึงโควต้าที่กําหนดแล้ว คุณจะดําเนินการแบบเร่งด่วนไม่ได้อีกจนกว่าโควต้าจะรีเฟรช ซึ่งจะช่วยให้ 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
ให้คุณได้เมื่อจำเป็น
CoroutineWorker
หากใช้ 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 ชั่วโมง
ระยะเวลาของช่วงเวลาหมายถึงเวลาขั้นต่ำระหว่างการทําซ้ำ เวลาที่แน่นอนที่ระบบจะเรียกใช้ Executor ขึ้นอยู่กับข้อจำกัดที่คุณใช้อยู่ในออบเจ็กต์ 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
NetworkType | จำกัดประเภทเครือข่ายที่จําเป็นสําหรับให้งานทํางาน
เช่น Wi-Fi (UNMETERED )
|
BatteryNotLow | เมื่อตั้งค่าเป็น "จริง" งานจะไม่ทำงานหากอุปกรณ์อยู่ในโหมดแบตเตอรี่เหลือน้อย |
RequiresCharging | เมื่อตั้งค่าเป็น "จริง" งานจะทำงานเฉพาะเมื่ออุปกรณ์กำลังชาร์จเท่านั้น |
DeviceIdle | เมื่อตั้งค่าเป็น "จริง" อุปกรณ์ของผู้ใช้จะต้องไม่มีการใช้งานก่อนงานจะทำงาน ซึ่งอาจมีประโยชน์สำหรับการเรียกใช้การดำเนินการแบบเป็นกลุ่มที่อาจส่งผลเสียต่อประสิทธิภาพของแอปอื่นๆ ที่ทำงานอยู่ในอุปกรณ์ของผู้ใช้ |
StorageNotLow | เมื่อตั้งค่าเป็น "จริง" งานจะไม่ทํางานหากพื้นที่เก็บข้อมูลของผู้ใช้บนอุปกรณ์เหลือน้อยเกินไป |
หากต้องการสร้างชุดข้อจำกัดและเชื่อมโยงกับงานบางอย่าง ให้สร้างอินสแตนซ์ 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
ได้ด้วย ในกรณีนี้ เฉพาะการเรียกใช้งานตามรอบครั้งแรกเท่านั้นที่จะล่าช้า
นโยบายการลองใหม่และ Backoff
หากต้องการให้ WorkManager พยายามทำงานอีกครั้ง คุณสามารถส่งกลับ Result.retry()
จาก Executor จากนั้นระบบจะกำหนดเวลางานใหม่ตามระยะเวลาเลื่อนเวลาและนโยบายการเลื่อนเวลา
ระยะเวลาหน่วงเวลาจะระบุระยะเวลาขั้นต่ำที่ต้องรอก่อนที่จะลองดำเนินการอีกครั้งหลังจากพยายามครั้งแรก ค่านี้ต้องไม่น้อยกว่า 10 วินาที (หรือ MIN_BACKOFF_MILLIS)
นโยบายการหยุดพักจะกำหนดระยะเวลาที่เพิ่มขึ้นของการหยุดพักระหว่างการพยายามติดต่อครั้งต่อๆ ไป WorkManager รองรับนโยบายการหยุดทำงานชั่วคราว 2 รายการ ได้แก่
LINEAR
และEXPONENTIAL
คำของานทุกรายการมีนโยบายการลดจำนวนและเวลาในการลดจำนวน นโยบายเริ่มต้นคือ EXPONENTIAL
โดยมีความล่าช้า 30 วินาที แต่คุณสามารถลบล้างการตั้งค่านี้ได้ในการกําหนดค่าคําขอทํางาน
ต่อไปนี้คือตัวอย่างการปรับแต่งระยะเวลารอและนโยบายการลดจำนวน
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()
หลังจากพยายามเรียกใช้ครั้งต่อๆ ไป หากตั้งค่านโยบายการหยุดชั่วคราวเป็น EXPONENTIAL
ลำดับระยะเวลาการลองใหม่จะใกล้เคียงกับ 20, 40, 80 และอื่นๆ
ติดแท็กงาน
คำของานทุกรายการมีตัวระบุที่ไม่ซ้ำกัน ซึ่งสามารถใช้เพื่อระบุงานในภายหลังเพื่อยกเลิกงานหรือดูความคืบหน้า
หากมีงานกลุ่มหนึ่งที่เชื่อมโยงกันตามตรรกะ คุณอาจพบว่าการติดแท็กงานเหล่านั้นมีประโยชน์ การติดแท็กช่วยให้คุณดำเนินการกับคําของานกลุ่มหนึ่งๆ ได้
เช่น WorkManager.cancelAllWorkByTag(String)
จะยกเลิกคำของานทั้งหมดที่มีแท็กหนึ่งๆ และWorkManager.getWorkInfosByTag(String)
จะแสดงรายการออบเจ็กต์ WorkInfo ซึ่งสามารถใช้เพื่อระบุสถานะงานปัจจุบัน
โค้ดต่อไปนี้แสดงวิธีเพิ่มแท็ก "cleanup" ในงาน
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
เพื่อแสดงผลค่าที่แสดงผล ข้อมูลอินพุตและเอาต์พุตจะอธิบายไว้อย่างละเอียดในส่วนพารามิเตอร์อินพุตและค่าที่แสดงผล
ขั้นตอนถัดไป
ในหน้าสถานะและการสังเกตการณ์ คุณจะเห็นข้อมูลเพิ่มเติมเกี่ยวกับสถานะงานและวิธีตรวจสอบความคืบหน้าของงาน