Adding extension function for scheduling jobs

[RamV13]

Resolves #554

Signature

inline fun <reified T : Service> Context.scheduleJob(
    jobId: Int,
    buildSequence: JobInfo.Builder.() -> Unit
): Int

Before

val serviceComponent = ComponentName(this, MyService::class.java)
val builder = JobInfo.Builder(jobId++, serviceComponent)

if (wiFiConnectivityRadioButton.isChecked) {
    builder.setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED)
} else if (anyConnectivityRadioButton.isChecked) {
    builder.setRequiredNetworkType(JobInfo.NETWORK_TYPE_ANY)
}

systemService<JobScheduler>().schedule(builder.build())

After

scheduleJob<MyService>(jobId++) {
    if (wiFiConnectivityRadioButton.isChecked) {
        setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED)
    } else if (anyConnectivityRadioButton.isChecked) {
        setRequiredNetworkType(JobInfo.NETWORK_TYPE_ANY)
    }
}

Benefits

• no need for a Context parameter
• compile-time enforcement of the Service type upper bound for the class given to the JobInfo.Builder via the ComponentName (also cleaner by avoiding ::class.java)
• automatic construction of the ComponentName instance
• lambda with receiver for building the JobInfo
• automatic system service retrieval as well as build and schedule calls

* code snippet adapted from Google Samples

[JakeWharton]

All of this locking seems like it can be replaced with a simple CountDownLatch(1) and await with a reasonable timeout. Right now it seems overly complicated for no good reason.

[RamV13]

Agreed and updated. I was just following the convention I observed in the Android CTS.

[JakeWharton]

Having to use the context twice here is weird. This function call does not read very well. Perhaps we should address #526 first. But beyond that I'm not sure I'm convinced we need to handle scheduling and job creation in a single function.

[RamV13]

I've updated the API to

scheduleJob<TestService>(context, jobId) {
  /* ... */
}

which I think reads much nicer. Also, #526 won't change the function call in this case. Do you think this version makes it worth it to handle the scheduling and creation in a single function?

[RamV13]

I've updated the API again as per @rom4ek's suggestion and also added an upper bound on the type passed to the ComponentName. Please check out the Benefits section in the PR description to see why I think this would be worth it. Looking forward to hearing your thoughts! If you still feel that scheduling and job creation shouldn't be coupled like this, then I can just update the extension to simply provide the functionality of job creation.

[romtsn]

Shouldn't this be an extension function of Context then?

[RamV13]

Good point ... fixed

[romtsn]

Formatting

[AllanWang]

Shouldn't this return the int that is returned from schedule? And in light of that, I'm not sure if this constitutes a feature addition or not, but you could also use safe casting and return JobScheduler.RESULT_FAILURE if the service isn't found, which seems to happen a lot.

[RamV13]

Fixed

[AllanWang]

You can have the get system service and schedule calls in one line. Also note that I'm just a visitor and not a contributor. Those who manage the project may have a different opinion on the safe casting.

[RamV13]

Just keeping it on separate lines for formatting