Android WorkManager vs JobScheduler

Why do we need the new Android WorkManager if we already have a JobScheduler along with a few nifty backports (AndroidJob and FirebaseJobDispatcher) with the same functionality? Does it have any killer-features or something? Because I don't see anything that makes me want to migrate to the yet another scheduler.

"WorkManager has a lot of nice features but its main goal is to use the JobScheduler's API on older devices"... Wait, but we already have some backports. What's wrong with them? To cut it short:

1. FireaseJobDispatcher is fine but it requires Google Play to schedule jobs which isn't good if we're targeting China, for example.

2. Evernote's AndroidJob is an excellent backport with a lot of functionality. Imho, it was the best choice for scheduling any work. But now the latest version of the library uses the aforementioned WorkManager under the hood. And, unfortunately, sooner or later the library will be deprecated:

If you start a new project, you should be using WorkManager instead of this library. You should also start migrating your code from this library to WorkManager. At some point in the future this library will be deprecated.

They suggest to switch to the WorkManager because it provides more features and they also give us a short comparison:

|   Feature          | android-job | WorkManager |
| ------------------ | ----------- | ----------- |
| Exact jobs         | Yes         | No          |
| Transient jobs     | Yes         | No          |
| Daily jobs         | Yes         | No          |
| Custom Logger      | Yes         | No          |
| Observe job status | No          | Yes         |
| Chained jobs       | No          | Yes         |
| Work sequences     | No          | Yes         |

Imo, the the last 3 features are very useful and supported only by the WorkManager. So the answer to my last question is yes, it does have some killer-features:

• No Google Play required
• Queryable
• Chainable
• Opportunistic

To learn more about WorkManager one should definitely watch this talk by Sumir Kataria

P.S. If anyone knows why FirebaseJobDispatcher is actively supported by Google engineers instead of being deprecated write in the comments below :)

WorkManager uses JobScheduler service to schedule the jobs. If JobScheduler is not supported by the device, then it uses Firebase JobDispatcher service. If Firebase JobDispatcher is not available on the device, it will use AlarmManager and BroadcastReceiver.

So with WorkManager, you don't need to worry about backward compatibility. In addition to this, it allows for defining constraints, which need to be met in order for the job to be run, such as defining network constraints, battery level, charging state and storage level.

It allows task chaining and passing of argument to the job.

http://www.zoftino.com/scheduling-tasks-with-workmanager-in-android

WorkManager just seems like Google's answer to Evernote's Android-Job library, but with a few improvements. It uses JobScheduler, Firebase JobDispatcher and AlarmManager just like Android-Job depending on the device's API level. Their usage of tags looks pretty much the same and assigning constraints to jobs/work are similar enough.

The two features that I am excited about are: being able to chain work and the ability to be opportunistic on work with constraints. The first will allow work (jobs) to be broken up and more modular for me. And with more modular work, each piece of work may have fewer constraints improving the chance they will complete earlier (opportunistic). For example, the majority of processing work can complete before the work with a network constraint needs to be met.

So if you're happy with your current scheduler implementation and the two features I mentioned don't add value, I don't see a huge benefit to making the switch just yet. But if you're writing something new, it'll probably be worth it to use WorkManager.

First, WorkManager is used for work that can be deferrable and require guarantee execution. With backward compatibility in mind JobScheduler only works on API 23+. To avoid having to work on backward compatibility WorkManager does that for you:-

Features of work manager

• Guaranteed, constraint aware execution
• Respect system background restriction
• Quarreable, you can check status i.e. failed, success, etc
• Chainable, eg work-A depend on work-B -> Work graph
• Opportunistic, try best to execute as soon as constraints are met, without actually need job scheduler to intervene i.e wakeup the app or wait for JobSheduler to batch your work if your process is up and running
• Backward compatible, with or without google play service

WorkManager offers compatibility back to API level 14. WorkManager chooses an appropriate way to schedule a background task, depending on the device API level. It might use JobScheduler (on API 23 and higher) or a combination of AlarmManager and BroadcastReceiver

The extended under the hood architecture

WorkManager sits on top of JobScheduler and AlarmManager. WorkManager picks the right APIs to use, based on conditions like the user's device API level

WorkManager is a simple, but incredibly flexible library that has many additional benefits. These include:

 -Support for both asynchronous one-off and periodic tasks.
 -Support for constraints such as network conditions, storage space, and charging -status 
 -Chaining of complex work requests, including running work in parallel.
 -Output from one work request used as input for the next.
 -Handles API level compatibility back to API level 14.
 -Works with or without Google Play services.
 -Follows system health best practices.
 -LiveData support to easily display work request state in UI.