Job Configuration

Jobs have a couple of properties which define their behavior on different cases.

• Priority Higher is better. Next available job consumer will get the highest priority job first. (if it is ready to run). By design, memory only jobs are higher priority than persistent jobs. If two jobs have the same priority, the jobs which is enqueued first runs first. (assuming both are ready to run)

• Network Requirement If you mark the job as requires network, Job Manager will not run the job until the device has network connection. This won't block other jobs from running if they don't require network, even if they have lower priority.

• Persistence Sometimes, it is very important to ensure a job runs, no matter what happens to the app. (crash etc :) ). In this case, you can mark the job as persistent and Job Manager will take care of it. If your app crashed for some reason or gets killed by the OS, next time it re-opens, Job Manager will try to re-run it. This is very helpful for any app where user creates content to ensure your application eventually syncs user's content to server.

• Grouping It is a common use case where you don't want to run certain jobs in parallel. For example, when multiple jobs edit the same object. For such cases, you can assign same groupId to these jobs and Job Manager will ensure they run sequentially (fyi different job classes may have the same id. it depends on the job instance, not the class). A great example for this is a messaging client. If user has a bunch of messages waiting to be sent to different conversations, you need to ensure that messages going to the same conversation are in order. Meanwhile, you can send messages to different conversations in parallel. It is very easy to solve with Job Manager by setting SendMessageJob's groupId to conversation id. Within the group, priority rules still apply.

• Delaying Jobs Sometimes you want to run a job after some time passes. For instance, you want to acquire GCM tokens and send it to your server when app starts but you don't want it to fight for network with your more important requests. In this case, you can enqueue related job with a delay and Job Manager will wait until it should run. When it is ready to run, other rules still apply (network requirement etc) IMPORTANT: This delay parameter is not suitable for running jobs in hours or days later. It is controlled by an in session timer and if job is persistent and application restarts, all delayed persistent jobs are set to current. related issue

• Retry Logic If a job throws an exception while running, Job Manager calls shouldReRunOnThrowable method to decide if the job should be re-tried or cancelled. If job reaches retry limit (by default 20), Job Manager will automatically cancel it without calling shouldReRunOnThrowable but will call onCancel method. You can override retry count per job by overriding getRetryLimit method.