Fixed
Status Update
No update yet.
Comments
pm...@google.com
su...@google.com
ap...@google.com
In SystemJobService, it can expect null, and able to tolerance null from WorkManagerImpl.getInstance, due to auto-backup reason.
@Override
public void onCreate() {
super.onCreate();
mWorkManagerImpl = WorkManagerImpl.getInstance(getApplicationContext());
if (mWorkManagerImpl == null) {
// This can occur if...
// 1. The app is performing an auto-backup. Prior to O, JobScheduler could erroneously
// try to send commands to JobService in this state (
// Application#onCreate nor ContentProviders have run, WorkManager won't be
// initialized. In this case, we should ignore all JobScheduler commands and tell it
// to retry.
But, current WorkManagerImpl.getInstance(Context context) implementation is that, it will never return null but throw IllegalStateException.
Isn't there's conflict among these 2 SystemJobService.onCreate logic, and WorkManagerImpl.getInstance logic?
@Override
public void onCreate() {
super.onCreate();
mWorkManagerImpl = WorkManagerImpl.getInstance(getApplicationContext());
if (mWorkManagerImpl == null) {
// This can occur if...
// 1. The app is performing an auto-backup. Prior to O, JobScheduler could erroneously
// try to send commands to JobService in this state (
// Application#onCreate nor ContentProviders have run, WorkManager won't be
// initialized. In this case, we should ignore all JobScheduler commands and tell it
// to retry.
But, current WorkManagerImpl.getInstance(Context context) implementation is that, it will never return null but throw IllegalStateException.
Isn't there's conflict among these 2 SystemJobService.onCreate logic, and WorkManagerImpl.getInstance logic?
Description
Version used: any
Devices/Android versions reproduced on: N/A
The documentation for WorkManager is currently a bit unclear about how work requests are retained. Can I be sure that a work I scheduled will be retained until it is either completed or cancelled? Since this is unclear, we will probably rely on a secondary persistence of the data we want to send.
I suggest updating the documentation so that this detail is super clear to avoid developers inventing the wheel once again.
A real life use case for the WorkManager would be sending events that must be sent, even if the user logs out of the app. WorkManager would be perfect for this by itself, but currently we had another database for these events because we were unsure about how this worked.