Assigned
Status Update
No update yet.
Comments
gg...@google.com
Not at the moment. But we have been asked this before, so I will treat this as a feature request.
gg...@google.com
OK thanks. At the moment I am just adding the name to the Data for the work request and retrieving it in startWork(), which works well enough.
ar...@gmail.com
Sorry, not answered because I've nothing to say.
While using WorkManager I realized that I do not have the power to influence Works schedule in any way.
I mean, reorder them or give priority.
I do not have a suggestion, because I think Google architects can design it better than me.
I can only descript one use case that I had:
The name of the method "enqueue" suggest to me that scheduling is FIFO, in some case I can have the need to add a new Work that would be scheduled before than others.
So, as first implementation, I canceled all old Works, added the new one, and restarted the old ones. Doing that I had two issues:
- The only way I found to get old works is using SynchronousWorkManager, that needs to be called in a @WorkerThread. If I get LiveData<List<WorkStatus>>, I can only observe it, if I get directly the value of the WorkStatus (it return null)
- At the same way the only way to beginUniqueWork is using WorkManager that is requested to be called in the main thread
- So, remove a Work, and add it again cannot be an atomic operation.
So, finally, I decided to do not use unique-work, and I managed elsewhere to avoid duplication of the work.
While using WorkManager I realized that I do not have the power to influence Works schedule in any way.
I mean, reorder them or give priority.
I do not have a suggestion, because I think Google architects can design it better than me.
I can only descript one use case that I had:
The name of the method "enqueue" suggest to me that scheduling is FIFO, in some case I can have the need to add a new Work that would be scheduled before than others.
So, as first implementation, I canceled all old Works, added the new one, and restarted the old ones. Doing that I had two issues:
- The only way I found to get old works is using SynchronousWorkManager, that needs to be called in a @WorkerThread. If I get LiveData<List<WorkStatus>>, I can only observe it, if I get directly the value of the WorkStatus (it return null)
- At the same way the only way to beginUniqueWork is using WorkManager that is requested to be called in the main thread
- So, remove a Work, and add it again cannot be an atomic operation.
So, finally, I decided to do not use unique-work, and I managed elsewhere to avoid duplication of the work.
gg...@google.com
yb...@google.com
su...@google.com
Just FYI, you can use beginUniqueWork()...enqueueSync() if you want to enqueue it synchronously on a background thread.
ar...@gmail.com
Thanks, I didn't see the existence of the SynchronousWorkContinuation.
cr...@shou.tv
Yes, priority cool, we need this
Description
Version used: 1.0.0-alpha1
This is not a bug, but a feature request.
Would be really usefull to have a way to give priority to different Works, and maybe to have a way to change schedule order even after having enqued them.
The only way to add a WorkRequest now is to use the enque() method. A bit more flexibility would be appreciated.