Newer
Older
# JobManager
An Android library that facilitates scheduling persistent jobs which are executed when their
prerequisites have been met. Similar to Path's android-priority-queue.
Add as a gradle dependency, replacing `${latest_version}` with the version currently available:
```
dependencies {
compile 'org.whispersystems:jobmanager:${latest_version}'
}
```
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
## The JobManager Way
Android apps often need to perform blocking operations. A messaging app might need to make REST
API calls over a network, send SMS messages, download attachments, and interact with a database.
The standard Android way to do these things are with Services, AsyncTasks, or a dedicated Thread.
However, some of an app's operations might need to wait until certain dependencies are available
(such as a network connection), and some of the operations might need to be durable (complete even if the
app restarts before they have a chance to run). The standard Android way can result in
a lot of retry logic, timers for monitoring dependencies, and one-off code for making operations
durable.
By contrast, the JobManager way allows operations to be broken up into Jobs. A Job represents a
unit of work to be done, the prerequisites that need to be met (such as network access) before the
work can execute, and the characteristics of the job (such as durable persistence).
Applications construct a `JobManager` at initialization time:
```
public class ApplicationContext extends Application {
private JobManager jobManager;
@Override
public void onCreate() {
initializeJobManager();
}
private void initializeJobManager() {
this.jobManager = JobManager.newBuilder(this)
.withName("SampleJobManager")
.withConsumerThreads(5)
.build();
}
...
}
```
This constructs a new `JobManager` with 5 consumer threads dedicated to executing Jobs. A
Job looks like this:
```
public class SampleJob extends Job {
public SampleJob() {
super(JobParameters.newBuilder().create());
}
@Override
public onAdded() {
// Called after the Job has been added to the queue.
}
@Override
public void onRun() {
// Here's where we execute our work.
Log.w("SampleJob", "Hello, world!");
}
@Override
public void onCanceled() {
// This would be called if the job had failed.
}
@Override
public boolean onShouldRetry(Exception exception) {
// Called if onRun() had thrown an exception to determine whether
// onRun() should be called again.
return false;
}
}
```
A Job is scheduled simply by adding it to the JobManager:
```
this.jobManager.add(new SampleJob());
```
## Persistence
To create durable Jobs, the JobManager needs to be given an interface responsible for serializing
and deserializing Job objects. A `JavaJobSerializer` is included with JobManager that uses Java
Serialization, but you can specify your own serializer if you wish:
```
public class ApplicationContext extends Application {
private JobManager jobManager;
@Override
public void onCreate() {
initializeJobManager();
}
private void initializeJobManager() {
this.jobManager = JobManager.newBuilder(this)
.withName("SampleJobManager")
.withConsumerThreads(5)
.withJobSerializer(new JavaJobSerializer())
.build();
}
...
}
```
The Job simply needs to declare itself as durable when constructed:
```
public class SampleJob extends Job {
public SampleJob() {
super(JobParameters.newBuilder()
.withPersistence()
.create());
}
...
```
Persistent jobs that are enqueued will be serialized to disk to ensure that they run even if
the App restarts first. A Job's onAdded() method is called after the commit to disk is complete.
## Requirements
A Job might have certain requirements that need to be met before it can run. A requirement is
represented by the `Requirement` interface. Each `Requirement` must also have a corresponding
`RequirementProvider` that is registered with the JobManager.
A `Requirement` tells you whether it is present when queried, while a `RequirementProvider`
broadcasts to a listener when a Requirement's status might have changed. `Requirement` is attached
to Job, while `RequirementProvider` is attached to JobManager.
One common `Requirement` a `Job` might depend on is the presence of network connectivity.
A `NetworkRequirement` is bundled with JobManager:
```
public class ApplicationContext extends Application {
private JobManager jobManager;
@Override
public void onCreate() {
initializeJobManager();
}
private void initializeJobManager() {
this.jobManager = JobManager.newBuilder(this)
.withName("SampleJobManager")
.withConsumerThreads(5)
.withJobSerializer(new JavaJobSerializer())
.withRequirementProviders(new NetworkRequirementProvider(this))
.build();
}
...
}
```
The Job declares itself as having a `Requirement` when constructed:
```
public class SampleJob extends Job {
public SampleJob(Context context) {
super(JobParameters.newBuilder()
.withPersistence()
.withRequirement(new NetworkRequirement(context))
.create());
}
...
```
## Dependency Injection
It is possible that Jobs (and Requirements) might require dependency injection. A simple example
is `Context`, which many Jobs might require, but can't be persisted to disk for durable Jobs. Or
maybe Jobs require more complex DI through libraries such as Dagger.
JobManager has an extremely primitive DI mechanism strictly for injecting `Context` objects into
Jobs and Requirements after they're deserialized, and includes support for plugging in more complex
DI systems such as Dagger.
The JobManager `Context` injection works by having your `Job` and/or `Requirement` implement the
`ContextDependent` interface. `Job`s and `Requirement`s implementing that interface will get a
`setContext(Context context)` call immediately after the persistent `Job` or `Requirement` is
deserialized.
To plugin a more complex DI mechanism, simply pass an instance of the `DependencyInjector` interface
to the `JobManager`:
```
public class ApplicationContext extends Application implements DependencyInjector {
private JobManager jobManager;
@Override
public void onCreate() {
initializeJobManager();
}
private void initializeJobManager() {
this.jobManager = JobManager.newBuilder(this)
.withName("SampleJobManager")
.withConsumerThreads(5)
.withJobSerializer(new JavaJobSerializer())
.withRequirementProviders(new NetworkRequirementProvider(this))
.withDependencyInjector(this)
.build();
}
@Override
public void injectDependencies(Object object) {
// And here we do our DI magic.
}
...
}
```
`injectDependencies(Object object)` will be called for a `Job` before the job's `onAdded()` method
is called, or after a persistent job is deserialized.
## License
Copyright 2014 Open Whisper Systems
Licensed under the GPLv3: http://www.gnu.org/licenses/gpl-3.0.html