Fixed
Status Update
No update yet.
Comments
ra...@google.com
ra...@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
`workManager.getWorkInfosForUniqueWorkLiveData(TAG)`
The pain point with this is that this gives you all the completed workers' workInfos as well. If the intention is only to observe the status of the currently running workers, it requires a call to pruneWork() which seems like an anti-pattern. A work around with the current apis would be to create unique tags for each work but then again that's a pain to maintain if you have a complicated use case.
What I propose is a builder method along with this api to be able to put in simple filters like status of the worker(BLOCKED, ENQUEUED, RUNNING, SUCCEEDED) to begin with. Have got a thumbs-up from Rahul Ravikumar from the Toolkit team on this.