MATTHEW WILLIAMS: Hi.
I'm Matthew from the Android Cloud Team.
And I'm going to talk about how you're apps can efficiently use
platform resources with the new job scheduler API's.
You lucky devils.
So what are we doing here exactly?
I mean this is YouTube.
You could be watching video game replays or fashion tips.
But don't go just yet.
I'm going to show off a new way to handle execution
of background jobs in a way that will improve battery life also
developer's lives.
So what background jobs?
Well, there are different kinds of work
your app needs to get done that aren't user facing.
Periodically hitting the network to upload user data
or downloading config parameters.
These typically don't need to be reflected immediately--
if at all-- to the user.
For example, think of a network operation
that would not update the UI.
The types of jobs I'm talking about are also self-contained.
One way to think of it is that we're
interested in execution logic that can be easily refactored.
Another way to think about it is that sum bundle of parameters
that you need to know to run your task.
The [? neove ?] user, the list of rows in your database
that are dirty, or the list of contacts
that the user has requested be uploaded.
So why create a new API?
You might wonder what's our rationale.
And clearly these things have been possible for as long
as Android has been around.
Well, not quite.
Take network calls as an example.
These are a strong candidate for the kinds of work
we're interested in.
Apps usually do them ASAP to kind of get them out
of the way.
This leads to unnecessary radio wake ups
where everyone is doing their own thing haphazardly.
To sell you some more, let's take a look at home
we might write code to periodically upload data
but without the job scheduler.
There are roughly two ways you could have done this.
You could use a handler and post a delayed message,
if the period was small enough.
But what happens if the user kills their app,
or if the system does?
At this point, you decide the AlarmManager is for you,
because at least you'll be started
when the alarm goes off.
The problem is now that if the phone turns off,
your alarm is gone.
So you're stuck doing your own business stunts.
Then what if in execution time, the network wasn't available?
You'd need to handle this and try again later.
You have to register a broadcast receiver
so you'd know when connectivity came back.
I guess you could try writing a sync adapter, which kind of
solves a bunch of these issues for you
and is an excellent piece of code.
But it's not intended to be used for scheduling.
Regardless of route, it would be a mess and difficult
to get right.
So we've decided to get it wrong for you.
We've taken pre-existing functionality, wired it
together with new functionality, and we're giving it to you
in a nice palatable package.
We've introduced the concept of idle mode, a window of time
for which the system has determined the phone is unused
and is not likely to be turned on soon.
For example, having a job run while the device is idle
and also charging is likely to happen at night when
the user is sleeping with the phone plugged in next to them.
The second thing we've done is integrate
it closely with new system API so that it will inform clients
when the network is active.
This means that the handshake with the carrier
has already happened.
So when we batch your app's network calls to follow on
shortly after, it will circumvent the battery course
of you doing this handshake independently.
Less pesky battery blaming and battery
[INAUDIBLE] for you and more battery for our users.
So let's take a look at how to use this functionality.
Here we'll see the sorts of work you might like to express.
Run this when the phone is plugged in.
Run this whenever an unmetered network becomes available.
But make sure I run within the hour.
Wait at least 10 minutes, and then run this
the next time the device is idle.
Every 15 minutes, whenever a network is available
let me know so I can do some small health check.
These four use cases there are a number of constraints.
And you can specify as many or as few of them as you want.
The scheduler will only run a job that
has all of its criteria satisfied.
The one exception being when you set a deadline.
When this deadline expires, it'll
override your existing constraints.
Let's take a look at how we do this practically.
For this job assessing the deadline of an hour.
What will happen if the phone is in airplane mode
after the hour has expired?
Well, we'll talk about failure retry
in the next and last section.
For now let's look at some other interesting things.
My job service is the endpoint you provide.
Here you are identifying it so that the system will
know where your job should land.
Wi-Fi upload ID is handled on your job
to differentiate it from others as you schedule.
So it's your integer that you pick yourself.
You take this job in for object, and it
passes into the system in a normal way, and voila.
But where does my logic go?
OK, so you extend a service provider by the framework.
The framework service handles all of the serious life cycle
mechanics for you, leaving you with only the implementation
of onStartJob and onStopJob to worry about.
Once your job is landed on your service
and you've done whatever it is you set out to do,
call jobFinished and you're done.
And that's more or less it.
Oh yeah, I mentioned it was really
easy to request a reschedule if your job failed
for some reason.
In either onStartJob or jobFinished,
you provide a Boolean to indicate
whether you need to be rescheduled.
Bam!
Done.
OK, that's a lot of detail.
But if you're still with me, you have it
and are ready to use this stuff.
The take away is that being good citizen should be
is painless a show as possible.
So thanks for watching.