Fixed
Status Update
No update yet.
Comments
su...@google.com
Thanks, we're looking at ways to address this. Currently, we're having some internal debates about who can see work - if we make it possible for a library or module to cancel another library or module's work, that isn't desirable. However, there are times where the app wants to clear everything.
As far as your last question, I'm not sure how you can end up in a situation where you *change* a tag name. You're always enqueuing a new work at that point, with a separate ID.
As far as your last question, I'm not sure how you can end up in a situation where you *change* a tag name. You're always enqueuing a new work at that point, with a separate ID.
ro...@gmail.com
Thank you for your answer. Regarding the last question, it was again my fault. I used as tag name the simple name of the worker class (MyWorker.class.getSimpleName()). A couple of days later I decided to refactor the class names of my workers and make them more descriptive. Obviously the tag named changed, and new workers where enqueued, but I suspect the old ones are even alive (I see a lot of activity in my backend logs).
I could write code to cancel the old workers based on the old tag names, before enqueue the new ones, but in my modest opinion, this is a lot of work and could be avoided with a "cancelAll" method.
On the other hand, the possibility to change by mistake or inadvertently a tag name is always there. We are only humans.
Another scenario to allow clearing everything: for example, if I have 5 workers that are executed periodically, but in a future release of the app I decide to group them in only one worker because of reasons (more performance, easier to maintain... whatever). In this scenario I have to write code to cancel the old 5 ones (if I know the tag or id's!), and enqueue the new one. Again a lot of boilerplate code.
Thanks you for your attention and your efforts with this amazing library.
Regards.
I could write code to cancel the old workers based on the old tag names, before enqueue the new ones, but in my modest opinion, this is a lot of work and could be avoided with a "cancelAll" method.
On the other hand, the possibility to change by mistake or inadvertently a tag name is always there. We are only humans.
Another scenario to allow clearing everything: for example, if I have 5 workers that are executed periodically, but in a future release of the app I decide to group them in only one worker because of reasons (more performance, easier to maintain... whatever). In this scenario I have to write code to cancel the old 5 ones (if I know the tag or id's!), and enqueue the new one. Again a lot of boilerplate code.
Thanks you for your attention and your efforts with this amazing library.
Regards.
su...@google.com
A cancelAll method is planned for alpha03.
As far as the general problem, I would say that you should think of WorkManager as you would your database in terms of upgrades/downgrades/migrations. We can provide more functionality, and sometimes it makes sense (like cancelAll), but you should treat renames of tags and worker class names as migrations and write update steps for them.
As far as the general problem, I would say that you should think of WorkManager as you would your database in terms of upgrades/downgrades/migrations. We can provide more functionality, and sometimes it makes sense (like cancelAll), but you should treat renames of tags and worker class names as migrations and write update steps for them.
Description
Version used:1.0.0-alpha02
Devices/Android versions reproduced on: all
Hi,
maybe I'm missing something in the documentation.
My intention was to create a periodic work that should run once a day (each 24 hours). I did two mistakes: I forgot to give the job a tag, and I forgot to check if the job was already in the queue before enqueueing it.
As result of error n2, each time that a user opens the app, a new job is enqueued. Only one job should be fired a day per user, but in my backend logs I can see that this happens multiple times per user.
As result of the error n1, I can not cancel those jobs (because they do not have a tag). I suppose the only solution is to uninstall the app and install it again.
Maybe it would be a nice feature to have a method to cancel all scheduled works, with or without tags. Or a method to get all current works, without tags, an then cancel them by Id.
Or at least to make the tag for a job mandatory, to be able to cancel the task in the future.
Another question that I did not find answer for is: what happens to current scheduled works, if the tag name is changed? Are the new one enqueued, and the old ones remains alive or what?
Thank and apologizes about my English.