add ability to cancel jobs about android-priority-jobqueue HOT 35 CLOSED

I've been thinking about this recently. Being able to cancel jobs with ID looks like the most obvious choice but in that case, we enforce user to keep track of job ids and when they are persistent, this will get messy.

In addition to that, it may make sense to let user cancel jobs with group. That would help a bit.

A third options to also let user tag jobs. This might be very useful (of course, will add a small load on the job manager to keep track of tag -> job index)

For example, user can create a dynamic uniq tag for each activity and any job related to that activity can be created with that tag. This way, onDestroy method can call jobManager.cancelJobsWithTags to cancel all jobs that are not handled.

here is the suggested changes to Params class:

class Params {
....
    private Set<String> tags;
    public Params withTags(String... tags) {
        this.tags.addAll(tags);
    }
...
}

In this scenario, Activity binded jobs can be implemented as follows:

class BaseActivity extends Activity {
....
    public final String jobTag = UUID.randomUUID().toString();
    @Override
    public void onDestroy() {
        super.onDestroy();
        jobManager.cancelJobsInBackgroundByTag(jobTag);
    }
}

class DummyActivity extends BaseActivity {
     ...
     private void doSth() {
         jobManager.addJob(new DummyJob(new Params().witTags(jobTag));
     }
}

These tags will give user more flexibility. For instance, if some jobs are related to a particular object, all those jobs can be tagged with object's uniq id and if object gets destroyed (e.g. deleted by user), all jobs related to that object can easily be cancelled.

JobManager would still call onCancel method on the cancelled jobs so that they can cleanup themselves.

Using these tags, we can even let user query jobs by tags, which is a commonly required feature.

Please comment on what you think about this suggestion.

from android-priority-jobqueue.

From @gaku on February 12, 2014 5:40

Yigit, for my use case the tag solution works perfectly. I like the capability of canceling all the jobs created by a specific activity with onDestroy() in the way you describe.

Only drawback I can see is that this is adding a bit of additional learning curve (one more concept to learn, job id / job group / and job tag). It could be okay as new users don't need to understand this until they want to cancel jobs in their applications.

from android-priority-jobqueue.

i actually 'kind of' regret giving the job id back. it is not global unique identifier (ids are per queue which can be customized in the configuration and Job Manager doesn't have any control on them).

You are right tags will add future complexity to an already complex library. Actually, the reason for naming them as tags is to use them for further querying requests (e.g. finding jobs by tag).

Any alternative suggestion ?

from android-priority-jobqueue.

From @gaku on February 14, 2014 7:54

I see. Is there anyway you can merge tags and groups? I know how job groups work, but manipulating jobs is going to be done via job tags. I could be cleaner/simpler if sequential processing could be done with a tag, and that'll let groups go. (correct?)

Regarding job id, I believe I haven't used it until I wanted to cancel jobs, so it can be gone. Alternatively, from what you mentioned, the job id issue was from the fact that Job Manager doesn't control it, so making it globally unique and assigned by job manager could be an option.

from android-priority-jobqueue.

From @mecid on April 10, 2014 12:2

@yigit When we can get this feature in stable release of library?

from android-priority-jobqueue.

From @beshkenadze on April 10, 2014 12:8

@mecid 👍, @yigit Yep we need this feature.

from android-priority-jobqueue.

From @upelsin on April 15, 2014 12:52

Would vote for this feature as well.

One might have a look into Google's Volley library as they have this feature implemented in a similar way (cancelling by tag).

from android-priority-jobqueue.

From @daj on May 23, 2014 15:32

I vote for this feature too! (I wish there was a lightweight way to do that in GitHub)

from android-priority-jobqueue.

From @aldoborrero on July 15, 2014 10:32

+1 to get this feature!

from android-priority-jobqueue.

From @KevinTCoughlin on July 18, 2014 3:12

👍 would be very helpful

from android-priority-jobqueue.

From @pnikosis on July 23, 2014 9:46

As a temporary solution, by forcing the job to throw a Throwable also would cancel the job, right?

from android-priority-jobqueue.

don't do that, it will cause job being re-tried until it reaches the retry limit.
if you have access to the just, just return from onRun method as if it succeeded

from android-priority-jobqueue.

From @jatago on July 29, 2014 18:18

+1 In this feature. @yigit for the meantime until the feature is ready (any timeline for this?) what exactly do you mean by "if you have access to the just, just return from onRun method as if it succeeded"?

from android-priority-jobqueue.

From @mufumbo on July 30, 2014 7:16

Yiğit,

I don't know if its relevant, but let me give you a real use case when
canceling jobs is important.

Yesterday in Allthecooks we were implementing a new feature that allows
recipes to be auto saved while the user is typing. Of course I just need
the latest version to be persisted to the queue, so I would be cleaning the
queue before adding any task.

It would be great to implement this with android-priority-jobqueue so I
know the job will be persisted even if the app crashes with OOM. Makes
sense?

Thanks
Rafa
On Jul 29, 2014 8:18 PM, "Javier Tarazaga" [email protected] wrote:

+1 In this feature. @yigit https://github.com/yigit for the meantime
until the feature ready (any timeline for this?) what exactly do you mean
by "f you have access to the just, just return from onRun method as if it
succeeded"?

—
Reply to this email directly or view it on GitHub
https://github.com/path/android-priority-jobqueue/issues/2#issuecomment-50516384
.

from android-priority-jobqueue.

From @aldoborrero on July 30, 2014 9:16

+1 to what Rafa has said!

Aldo Borrero
Ingeniero Técnico en Informática de Sistemas
www.aldoborrero.com

On Wed, Jul 30, 2014 at 9:16 AM, Rafael Sanches [email protected]
wrote:

Yiğit,

I don't know if its relevant, but let me give you a real use case when
canceling jobs is important.

Yesterday in Allthecooks we were implementing a new feature that allows
recipes to be auto saved while the user is typing. Of course I just need
the latest version to be persisted to the queue, so I would be cleaning
the
queue before adding any task.

It would be great to implement this with android-priority-jobqueue so I
know the job will be persisted even if the app crashes with OOM. Makes
sense?

Thanks
Rafa
On Jul 29, 2014 8:18 PM, "Javier Tarazaga" [email protected]
wrote:

+1 In this feature. @yigit https://github.com/yigit for the meantime
until the feature ready (any timeline for this?) what exactly do you
mean
by "f you have access to the just, just return from onRun method as if
it
succeeded"?

—
Reply to this email directly or view it on GitHub
<
https://github.com/path/android-priority-jobqueue/issues/2#issuecomment-50516384>

.

—
Reply to this email directly or view it on GitHub
https://github.com/path/android-priority-jobqueue/issues/2#issuecomment-50581709
.

from android-priority-jobqueue.

@jatago , sorry, i had a typo,
"if you have access to the job, just return from onRun method as if it succeeded".
I meant, if jobs are not persistent, just have a field "mCancelled" and set it to true if job is cancelled.
in on run method, check the field and just return w/o doing anything if it is true. This is not perfect but may work for some cases.

@mufumbo , your use case is perfect for this feature :).
If you are keeping the text inside the job, you are w/o options.

But if you are keeping the contents somewhere else (in db):
You can add a version column to your db and your jobs can have a group id based on the recipe id (or some unique string that can identify that recipe, so that they don't run in parallel).
Each job can be created with an incremental version id (from db) and if the version of the job is less than the version in db, it would just return silently.
To avoid concurrency problems, you should first save the job with new version, then clean db. If app crashes in between, two jobs would run,you would never lose data.

@jatago For ETA, i really really want to work on this but right now I'm hammered with Android L release, spending all of my free time w/ it. I already have a half-baked implementation of tagging (which i want to use to cancel jobs instead of ids). If anybody is interested in working on this, I'm happy to share the code and review implementations.

from android-priority-jobqueue.

From @UFOnaut on August 6, 2014 11:0

+1. It wold be very useful feature.

from android-priority-jobqueue.

From @jatago on August 8, 2014 9:5

Hi @yigit , sorry for the late response (busy this days). Please that would if you could share what you have so far with the tagging. We are really looking forward to have this func in place and would be great to collaborate back into the lib. Thanks

from android-priority-jobqueue.

@jatago , please send me an email at y b o y a r / gmail.
thanks.

from android-priority-jobqueue.

From @pankajbatra on January 19, 2015 9:45

+1, need it badly

from android-priority-jobqueue.

From @mseshachalam on March 5, 2015 5:38

@jatago @yigit

+1, need it badly

from android-priority-jobqueue.

From @rifatdover on March 5, 2015 16:8

+1

from android-priority-jobqueue.

Here as well, +1. Cancelling by tag definitely make sense. Even if it's a learning curve, it's only when you want to cancel. Seeing the cancelByTag method will make me realize that I need to add a tag somewhere. Not so bad.

from android-priority-jobqueue.

good to hear that 👍

from android-priority-jobqueue.

@yigit tag == group?

from android-priority-jobqueue.

nope. group is used for run control.
tagging is used for retrieving data back.
For instance you can cancel jobs by tag. It would be very useful because you can create a random UUID in your activity, attach it to each job you create in that context and if user leaves your activity, cancel all jobs which has that tag.

from android-priority-jobqueue.

I pushed a snapshot version to maven central which includes tagging and cancelation.

I need to add more tests to be more comfortable but wanted to share if you would like to try and give feedback before it is released.

compile 'com.birbit:android-priority-jobqueue:1.3-SNAPSHOT'

You can use JobManager#cancelJobsInBackground or JobManager#cancelJobs to cancel jobs using tags.

Jobs have a new assertNotCanceled method to conveniently cancel long running jobs (just calling it inside onRun, it will throw an exception if it is cancelled).

Canceled jobs still receive an onCancel callback.

from android-priority-jobqueue.

Awesome , will use it. Thanks

from android-priority-jobqueue.

Thanks a lot! FYI, there is a race condition while canceling persistent jobs where it may return cancel=success even though job was completed successfully (cancel request came while running).

I'm working on it.

Please lmk if API looks sufficient.

from android-priority-jobqueue.

nevermind. I locally broke Job.java's serialization while getting rid of BaseJob. So, there is no "known" race condition.

from android-priority-jobqueue.

FYI i just uploaded a new snapshot and also staged a v1.3 . I think it is good now for a release.

from android-priority-jobqueue.

@yigit Any plans for merging your v1.3 with Path's repo?
I see Path's repo has not been updated for a while...Is Path's repo no longer under developement?

from android-priority-jobqueue.

@harrybvp Have you not seen https://github.com/path/android-priority-jobqueue/issues/99

from android-priority-jobqueue.

@mseshachalam Thanks. I was not aware of it.. Good to know

from android-priority-jobqueue.

released w/ 1.3 .

from android-priority-jobqueue.