On Google I/O of 2017, They announced many background task restrictions for SDK 27. Many of the developers migrated their code to support new background restrictions using the new Job APIs and along with Firebase’s Job Dispatcher API for backward compatibility for the same. This resulted in many confusions among developers to choose appropriate API and implement them also. But in this year’s Google I/O, They have announced WorkManager API which is a part of Android Jetpack which acts as a one-stop solution for all background tasks.
Main advantages of this API is listed here,
-> It can act as both asynchronous as well as periodic one.
-> It has support for device constraints such as network conditions, storage space, and charging status as like in Job API.
-> Chaining and parallel working of jobs possible.
-> All the way backward support to API 14!
-> Chooses appropriate Job API according to device constraints.
-> Works on non-Google Play services installed devices.
WorkManager is built on top of a few APIs such as JobScheduler, FirebaseJobDispatcher and AlarmManager etc., Simply, WorkManager is wrapper class for all APIs with some cool extra features.
Let’s start! Add dependency for WorkManager on your app level build.gradle file.
You can create your WorkManager class by extending Worker.class. The overridden method doWork() is the function you have to implement your logic. You can make use of this API if your work needs more time to process or your work should be carried on another thread. The method should return any of the WorkerResult public variables. If you return WorkerResult.RETRY, The work will be retried again. SUCCESS is used for indicating the work is completed.
A work can be a periodic or single time in terms of its execution. As I have mentioned earlier, WorkManager API has the capability for maintaining it. You can start your work by using a OneTimeWorkRequest instance for single time execution.Or, You can start your work by using PeriodicWorkRequestinstance for periodically recurring tasks.
Same as like in Job APIs, We can set the device constraints using Constraints instance.
As I have mentioned earlier, You can chain works together in a sequential order. Let’s say, we have work1,work2,work3 instances. We can start them in sequence just like below code.
Passing multiple works in beginWith() will result in those works to run parallel also. You can view the code in the above snippet.
More flexible right? You can refer official doc for more things.