android-priority-jobqueue | Job Queue specifically written for Android | Job Scheduling library

Android Priority Job Queue (Job Manager).
[Why ?](#why-)
[The Problem](#the-problem)
[Our Solution](#our-solution)
[Show me the code](#show-me-the-code)
[Priority Job Queue vs Job Scheduler vs GCMNetworkManager vs ?](#priority-job-queue-vs-job-scheduler-vs-gcmnetworkmanager-vs-)
[What’s happening under the hood?](#under-the-hood)
[Advantages](#advantages)
[Getting Started](#getting-started)
[Version History](#version-history)
[Running Tests](#running-tests)
[wiki][9]
[Dependencies](#dependencies)
[License](#license)
Async Task: Using an async task is the simplest approach, but it is tightly coupled with the activity lifecycle. If the activity dies (or is re-created), any ongoing async task will become wasted cycles or otherwise create unexpected behavior upon returning to the main thread. In addition, it is a terrible idea to drop a response from a network request just because a user rotated his/her phone.
Loaders: Loaders are a better option, as they recover themselves after a configuration change. On the other hand, they are designed to load data from disk and are not well suited for long-running network requests.
Service with a Thread Pool: Using a service is a much better solution, as it de-couples business logic from your UI. However, you will need a thread pool (e.g. ThreadPoolExecutor) to process requests in parallel, broadcast events to update the UI, and write additional code to persist queued requests to disk. As your application grows, the number of background operations grows, which force you to consider task prioritization and often-complicated concurrency problems.
Job Queue was inspired by a [Google I/O 2010 talk on REST client applications][8].
No network calls in activity-bound async tasks
No serialization mess for important requests
No "manual" implementation of network connectivity checks or retry logic
Right after PostTweetJob is synchronized to disk, Job Queue calls DependencyInjector (if provided) which will [inject fields](http://en.wikipedia.org/wiki/Dependency_injection) into our job instance. At PostTweetJob.onAdded() callback, we saved PostTweetJob to disk. Since there has been no network access up to this point, the time between clicking the send button and reaching onAdded() is within fractions of a second. This allows the implementation of onAdded() to inform UI to display the newly sent tweet almost instantly, creating a "fast" user experience. In V1, onAdded() is called on the thread job was added. In V2, onAdded() is called in JobManager’s own thread.
When it’s time for PostTweetJob to run, Job Queue will call onRun() (and it will only be called if there is an active network connection, as dictated at the job’s constructor). By default, Job Queue uses a simple connection utility that checks ConnectivityManager (ensure you have ACCESS_NETWORK_STATE permission in your manifest). You can provide a [custom implementation][1] which can add additional checks (e.g. your server stability). You should also provide a [NetworkUtil][1] which can notify Job Queue when network is recovered so that Job Queue will avoid a busy loop and decrease # of consumers(default configuration does it for you).
Job Queue will keep calling onRun() until it succeeds (or reaches a retry limit). If onRun() throws an exception, Job Queue will call shouldReRunOnThrowable() to allow you to handle the exception and decide whether to retry job execution or abort.
If all retry attempts fail (or when shouldReRunOnThrowable() returns false), Job Queue will call onCancel() to allow you to clean your database, inform the user, etc.
Clone the repo
> cd jobqueue
> ./gradlew clean assembleDebug assembleDebugUnitTest test * This will create a jar file under release folder.