คู่มือเริ่มต้นใช้งานอธิบายวิธีสร้าง 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>()
<b>.setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)</b>
.build()
WorkManager.getInstance(context)
.enqueue(request)
Java
OneTimeWorkRequest request = new OneTimeWorkRequestBuilder<T>()
.setInputData(inputData)
<b>.setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)</b>
.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
ซึ่งจะทำให้คำขอถูกยกเลิกหากมีโควต้าไม่เพียงพอ
งานด่วนที่เลื่อนเวลา
ระบบจะพยายามเรียกใช้งานที่เร่งด่วนโดยเร็วที่สุดหลังจากเรียกใช้งาน อย่างไรก็ตาม ระบบอาจเลื่อนการเริ่มงานเร่งด่วนใหม่ออกไปก่อน เช่น ในกรณีต่อไปนี้ ซึ่งเหมือนกับงานประเภทอื่นๆ
- การโหลด: การโหลดของระบบสูงเกินไป ซึ่งอาจเกิดขึ้นเมื่อมีงานทำงานอยู่มากเกินไป หรือเมื่อระบบมีหน่วยความจําไม่เพียงพอ
- โควต้า: มีงานเกินโควต้างานด่วน การทำงานแบบเร่งด่วนใช้ระบบโควต้าที่อิงตามที่เก็บข้อมูลสแตนด์บายของแอปและจำกัดเวลาดำเนินการสูงสุดภายในกรอบเวลาแบบต่อเนื่อง โควต้าที่ใช้สำหรับงานด่วนจะเข้มงวดกว่าโควต้าที่ใช้สำหรับงานอื่นๆ ที่ทำอยู่เบื้องหลัง
ตั้งเวลางานเป็นระยะ
บางครั้งแอปอาจกำหนดให้ต้องทำงานบางอย่างเป็นระยะๆ เช่น คุณอาจต้องสำรองข้อมูลเป็นระยะๆ ดาวน์โหลดเนื้อหาใหม่ในแอป หรืออัปโหลดบันทึกไปยังเซิร์ฟเวอร์
วิธีใช้ 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
จะไม่ทำงานจนกว่าจะเป็นไปตามเงื่อนไขนี้ ซึ่งอาจทําให้งานบางรายการทำงานล่าช้าหรือข้ามไปหากไม่เป็นไปตามเงื่อนไขภายในช่วงเวลาการทํางาน
ข้อจำกัดของงาน
Constraints
ตรวจสอบว่างานถูกเลื่อนออกไปจนกว่าจะมีเงื่อนไขที่เหมาะสม ข้อจำกัดต่อไปนี้ใช้ได้กับ WorkManager
NetworkType | จำกัดประเภทเครือข่ายที่จําเป็นสําหรับให้งานทํางาน
เช่น Wi-Fi (UNMETERED )
|
BatteryNotLow | เมื่อตั้งค่าเป็น "จริง" งานจะไม่ทำงานหากอุปกรณ์อยู่ในโหมดแบตเตอรี่เหลือน้อย |
RequiresCharging | เมื่อตั้งค่าเป็น "จริง" งานจะทำงานเฉพาะเมื่ออุปกรณ์กำลังชาร์จเท่านั้น |
DeviceIdle | เมื่อตั้งค่าเป็น "จริง" อุปกรณ์ของผู้ใช้จะต้องไม่มีการใช้งานก่อนงานจะทำงาน ซึ่งจะมีประโยชน์สำหรับการเรียกใช้การดำเนินการแบบเป็นกลุ่มที่อาจส่งผลเสียต่อประสิทธิภาพของแอปอื่นๆ ที่ทำงานอยู่ในอุปกรณ์ของผู้ใช้ |
StorageNotLow | เมื่อตั้งค่าเป็น "จริง" งานจะไม่ทํางานหากพื้นที่เก็บข้อมูลของผู้ใช้บนอุปกรณ์มีน้อยเกินไป |
หากต้องการสร้างชุดข้อจำกัดและเชื่อมโยงกับงานบางอย่าง ให้สร้างอินสแตนซ์ Constraints
โดยใช้ Constraints.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()
จาก 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
เพื่อแสดงผลค่าที่แสดงผล ข้อมูลอินพุตและเอาต์พุตจะอธิบายไว้อย่างละเอียดในส่วนพารามิเตอร์อินพุตและค่าที่แสดงผล
ขั้นตอนถัดไป
ในหน้าสถานะและการสังเกตการณ์ คุณจะได้ดูข้อมูลเพิ่มเติมเกี่ยวกับสถานะงานและวิธีตรวจสอบความคืบหน้าของงาน