Android Job works by first allowing you to define how you want your jobs to be created, by means of the Job Creator class. Then you can schedule requests using the Job Manager and have the confidence that they will be run when the requirements are met. In the image below you can see a representation of the various components involved with using Android Job in your application. Each Job is identified by a tag; this is just a simple String that is used to differentiate the various jobs in your application.
Let’s take a look at each piece!
Getting Setup
In order to use Android Job you just need to add the dependency to your build.gradle file. If you plan on taking advantage of GCM Network Manager for older devices, you will need to include that dependency as well.
Next, you would want to create your application’s Job Creator. This class is responsible for providing the correct Job class that corresponds to the tag it receives in its create() method. The Job Creator is a Singleton that uses Dagger’s Multibinding Support to house a Map that references Providers of Jobs. This allows you to add new Jobs to your application without having to modify the Creator class. Then on lines 15 and 16, you look in the Map for the correct Provider and return an instance of the appropriate Job.
I like to keep the definition of my Jobs in a separate Dagger module, named JobsModule. This helps to isolate those dependencies. Notice that I’m first defining my Job Manager which uses the Job Creator that we defined previously. Then by means of the following annotations: @Provides, @IntoMap, and @StringKey I’m defining how I want my Job to be created and injected. The combination of these annotations allows all of the Job Providers to be injected into the Map, with their associated tags, for later use when a Job Request is received.
Creating a Job
The heavy lifting is done by each Job class in its onRunJob() method. A simple example is queuing a Job that adds a new record to an API endpoint. Let’s assume you’re using Retrofit for your API needs. In the constructor of your Job you would annotate it with the @Inject annotation to get the needed dependencies, namely your API resource. Then you would perform the network operation inside of the onRunJob() method as usual. What’s unique is that you should return a Result from your method, so that the system knows whether to attempt to run your Job again at a later time.
Scheduling a Request
The final piece of the puzzle is building and then scheduling your requests. In order to send a request, you would simply use the schedule() method of the Job Manager class. This method takes a Job Request as its input.
The Job Request is built inside the containing Job class. You can send information regarding the desired network connections, device state, as well as extra data to be used when the request is executed. The below is a typical request that I use when scheduling jobs in my application.
I’ve really enjoyed working with this library and once all the pieces are set up it’s been easy to use. All the code snippets can be found in this gist. Thanks for reading!
If you would like to view some of my video content, I encourage you to check out my video course and bite-sized tutorials available on Caster.io.
