“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:
-
FireaseJobDispatcher is fine but it requires Google Play to schedule jobs which isn’t good if we’re targeting China, for example.
-
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 🙂