in last Seven Peaks Speaks android webinar: How to code effectively with MAD, Fedor talked about Background Processing with Work Manager, where we will learn about the best practices for scheduling one-time and periodic background work with Jetpack Work Manager.

1. Background Processing With WorkManager
Schedule background work easily
17.02.2022

2. BENEFITS
Pros of using WorkManager

3. Benefits
What’s good about WorkManager?
● Guaranteed. The work is guaranteed to execute.
● Work constraints. Specify best conditions for work. For example:
○ When the device is using Wi-FI.
○ The device is charging.
○ The device is idle.
○ Etc.
● Flexible scheduling. One-time and repeated work:
○ Can be delayed.
○ Minimum period between repeated work - 15 minutes.
● Retry policies. Provide retry policies in case there are some errors during execution.
● Work chaining. Chain multiple works in specific order with specific constraints.
● Works with RxJava and Coroutines.
● Built-in functionality for long work. Run in foreground and show notifications while the worker does the work.
● Integration with Hilt. Easily inject dependencies using only 3 annotations:
○ @HiltWorker, @AssistedInject, @Assisted

4. DISADVANTAGES
Cons of using WorkManager

5. Disadvantages
What’s not so good?
● Not precise. Repeated work is executed depending on various conditions and can be delayed by some time.
● Fast work doesn’t show notifications. The built-in functionality for notifications automatically removes the notification
once the job is done. If your work is quick there is a big chance the notification will not appear at all (possible to use
regular notification in this case).

6. INTRODUCTION
When to use WorkManager

7. When to use?
Types of Work and how to choose them
Note: Expedited work is available only in WorkManager 2.7.0+!

8. BASICS
Basics of WorkManager

9. Setup
Dependencies

10. Create Worker
Basic Worker
Extend Worker
Override doWork() and
return Result

11. Result
Types of Result
Result
retry
success
failure
The Work failed. It will not be restarted.
The Work failed. It will be restarted after
sometime.
The Work succeeded. If it’s periodic work,
it will be scheduled for next time.

12. Create Worker
Other types - Coroutine Worker
Extend
CoroutineWorker
Override suspend
doWork() and return
Result

13. Create Worker
Other types - RxWorker
Extend RxWorker
Override createWork()
and return
Single<Result>

14. Types of work requests
OneTimeWorkRequest | PeriodicWorkRequest

15. CREATING ONE TIME WORK
And specific features

16. One time work features
Specific features
● Chaining. Execute various works depending on different constraints.
● Expedited work. In case of a very important work that must be performed, possible to use expedited work. Features:
○ Importance: Expedited work suits tasks which are important to the user or are user-initiated.
○ Speed: Expedited work best fits short tasks that start immediately and complete within a few minutes.
○ Quotas: A system-level quota that limits foreground execution time determines whether an expedited job can
start.
○ Power Management: Power management restrictions ,such as Battery Saver and Doze, are less likely to affect
expedited work.
○ Latency: The system immediately executes expedited work, provided that the system's current workload
enables it to do so. This means they are latency sensitive and can't be scheduled for later execution.

17. Create OneTimeWorkRequest

18. Enqueue one work

19. Enqueue multiple works
Chaining
Add as much work as
you need!

20. Chaining - multiple one-time work
Work passed to WorkManager

21. Multiple one-time work
First Work succeeded | Second Work enqueued

22. Multiple one-time work
In case Result is retry(), the child works will wait until parent is success()!

23. Multiple one-time work
In case parent Work is failed all child Works are failed too!

24. Multiple one-time work
In case parent Work is cancelled all child Works are cancelled too!

25. Make work expedited
In case it’s very important!

26. Out of quotas?!
Choose what to in case there are no more quotas for your expedited work
OutOfQuotaPolicy
DROP_WORK_REQUEST
RUN_AS_NON_EXPEDITED_WORK_REQUEST
Run like non-expedited
Cancel the work

27. CREATING PERIODIC WORK
And specific features

28. Periodic work features
Specific features
● Additional parameters for the builder:
○ repeatInterval – The repeat interval in repeatIntervalTimeUnit units
○ repeatIntervalTimeUnit – The TimeUnit for repeatInterval
● Handling existing work with ExistingPeriodicWorkPolicy.
○ REPLACE - If there is existing pending (uncompleted) work with the same unique name, cancel and delete it.
Then, insert the newly-specified work.
○ KEEP - If there is existing pending (uncompleted) work with the same unique name, do nothing. Otherwise,
insert the newly-specified work.

29. Create PeriodicWorkRequest

30. Enqueue periodic work

31. CONSTRAINTS
Set the best conditions for work with work constraints

32. Constraints
Set the best time for work run
Note: DeviceIdle constraint requires min SDK version 23 (M)

33. WORK SCHEDULING
Set time and delay for work execution

34. Schedule work
Set delay and period time for your request
● One time work. For one time work you can specify initial delay:
○ .setInitialDelay(15L, TimeUnit.SECONDS)
● Periodic work. For periodic work you can specify initial delay and interval:
○ .setInitialDelay(15L, TimeUnit.SECONDS)
○ PeriodicWorkRequest.Builder(MyWorker::class.java,15L, TimeUnit.MINUTES)

35. ERROR HANDLING
Handle errors with retry policies

36. Handle errors
With BackOffCriteria

37. PASSING DATA
Pass data between multiple works

38. Pass data between your Work
Using Data
Note: You can pass only primitive types!

39. Pass data between your Work
Using InputMergers
InputMergers
ArrayCreatingInputMerger
OverwritingInputMerger
In case output from two works has same
name the last work will override the
value!
Works that have same output will be
stored in an array!

40. Pass data to the next Work
Pass output in our
Result.success(...)

41. Receive data in the next Work

42. NOTIFYING USER
Show foreground information to user

43. Notify user using ForegroundInfo
setForeground(...) makes the CoroutineWorker run in the context of a foreground android.app.Service
Call setForeground(...)
and pass
ForegroundInfo with
notification ID and
notification. Worker will
take care of the rest!
Note: If the Work is too fast there will be no notification! You can use regular way of showing notification in this case.

44. TRACKING WORK
Track the state of your work

45. Add tags
Tag your WorkRequest to track or even cancel Work later

46. Check work state
With WorkInfo
Contains lots of useful
information: Id, State,
Data, Tags, etc.
Various ways to get it!

47. HILT INTEGRATION
Integrate it with the recommended dependency injection library

48. Hilt set-up
In 3 steps
● Set-up Manifest.
● Set-up Application class.
● Use the following annotations to inject dependencies:
○ @HiltWorker - in Worker class.
○ @AssistedInject - instead of regular @Inject.
○ @Assisted - to inject Application Context and WorkerParameters
● Ready!

49. Manifest set-up
Disable automatic WorkManager initialization

50. Application class set-up
Extend Configuration.Provider and override getWorkManagerConfiguration()
Implement interface
Configuration.Provider
Inject
HiltWorkerFactory
Override
getWorkManagerConfi
guration() and set
HiltWorkerFactory

51. Worker set-up
@HiltWorker | @AssistedInject | @Assisted

52. UPCOMING MEETUP
Check out our event page
Stay tuned for what’s coming next!