Android-job: Test Job with Execution Window.

[tatocaster]

Hi

new JobRequest.Builder(SyncJob.TAG)
                .setExtras(extras)
                .setExecutionWindow(startMs, endMs)
                .setRequiredNetworkType(JobRequest.NetworkType.ANY)
                .setUpdateCurrent(true)
                .setPersisted(true)
                .setRequirementsEnforced(true)
                .build()
                .schedule();

this is a builder for a job, and execution window is between 1AM - 6AM as it was given in the example(it fits well, my needs).

• Question is , how can I test this? If I change phone's clock, this does not help, because execution windows is too wide. Also, I noticed that this job runs after the 6AM, for example, it happened to run at 8PM.
  I looked in library's test files, but there was written expected behavior of job, not the action itself. It may not run in the given execution time window.

• in onRunJob, I do async job and return RESCHEDULE every time ,to ensure that service will run, because it failed to run, several nights.

Please response, maybe I'm missing something.

Thanks in advance.

[vRallev]

If you follow the sample, then it should work. It's possible that devices adjust the execution window in order to save battery. Unfortunately, there isn't anything I could do.

You can start a job manually if the job schedule is used (Android 5+), see here.

Can you show your onRunJob() method? If you follow my sample, then you shouldn't return RESCHEDULE. That explains why you see that your job runs at 8 PM.

[tatocaster]

mSyncService.getLastSyncDateFromServiceObservable()
                .subscribe(
                        lastSyncDate -> {
                            // something
                        }, error -> Log.e(TAG, "onError: ", error)
                );

        return Result.RESCHEDULE;

yeah, here it is.

it's clear now, I missed point that, setUpdateCurrent with parameter false will not cancel current running job and schedule new one. According to this, RESCHEDULE is no more needed, and seems more clear.

[vRallev]

You also should make your sync a blocking call, see https://github.com/evernote/android-job/blob/master/FAQ.md#how-can-i-run-async-operations-in-a-job

[tatocaster]

but why? Firebase Job Dispatcher allows us to run async on start. here and returns true, that means job is not finished yet. but it runs in background thread.

of course I can make my call as blocking and whole operations blocking using RxJava (too simple), but why exactly? Do you think this is a main problem here ?

[vRallev]

I don't like the design of the JobScheduler. The problem is that you need to launch a background thread on your own and manage its state. You end up with many callbacks, because you need to post the result to the service again.

The library is doing all of this for you. However, if you run an async operation then the worker thread of the library finishes and doesn't know that there's still an operation going on.

Could be a problem, because when the library thinks it's done, then the service is killed and your app is more likely stopped by the system.

[tatocaster]

OK, that was clear explanation.
Thank you, very much!

I will refactor to a blocking call and schedule job when it needs to updateCurrent or not.

I will close this issue and open new if something unexpected will occur..

thanks.