Hi! Would anyone have a recently implemented `IntentService` using Coroutines and built on top of a ...

# android

[dave08]

Hi! Would anyone have a recently implemented IntentService using Coroutines and built on top of a LifecycleService ?

[Adam Powell]

IntentService is just shy of being deprecated, if you're trying to trigger background work in your app either just use coroutines on their own or use WorkManager's CoroutineWorker if you need the system to continue/retry the work on your behalf after your process dies

[dave08]

just use coroutines on their own

Does that mean using a LifecycleService with runBlocking { } ? And how would I queue the Intents coming in?

[dave08]

use WorkManager's CoroutineWorker

I need this to run right away, will WorkManager do that, or does it just schedule things for when it decides to run them?

[Adam Powell]

You can start work right away

[Adam Powell]

What's your use case?

[dave08]

I need to sync the state of a device in an MDM solution... meaning downloading (w/ a custom downloader...)/installing company apps, setting up restrictions...

[dave08]

I have a SyncAdapter to do this in general, but a Service allows to run this process manually in certain edge cases...

[Adam Powell]

I think WorkManager might be a good fit then

[Adam Powell]

What I meant by, "just use coroutines on their own" wasn't runBlocking though, and doesn't need a service. Just launch what you need to, or send queued messages to an actor, or whatever makes sense. All the service stuff does on Android is provide a signal to the OS that your app is still doing work, and as of Oreo your ability to use services to send that signal is severely limited.

[Adam Powell]

WorkManager uses the JobScheduler under the hood to negotiate all of that with the system instead, but with a friendlier API that works across different platform versions

[dave08]

Can I put the whole process into one Worker, or do I have to split it into little pieces (MUCH more work)...? I tried making some kind of generic adapter for my business logic... but WorkManager forces you to create tons of boilerplate classes for each step apart from the business logic layer...

[dave08]

I mean, will it just kill longer-running processes (or have some kind of lifecycle that needs managing) -- even when rescheduled, it might not be so nice to only have a few apps at a time spread out in pieces...

[Adam Powell]

if you're using CoroutineWorker the lifecycle to think about is usual coroutine cancellation

[Adam Powell]

you can put it into one worker if you like, it makes no real difference. Splitting it up into more workers/work requests lets you use WorkManager itself to persist the intermediate state between steps and pick up where those left off, but since you called it boilerplate it sounds like you probably already have a different solution to this implemented that would be redundant 🙂

[dave08]

We basically check the current state vs. expected, so I guess it should be fine... apart from some little delicate steps that I want to make sure are done to clean up if Android cancels the process... which I guess could be handled by catching the cancellation and withContext(NonCancellable) { } or similar

Thanks for clarifiying things 😉!

[dave08]

Two more little extra question though: 1) Which context does WorkManager use to run things from (a global Android process, the apps's - with the Application object of the app there too, a service in the app), 2) Can these work items be scheduled from a BroadcastReceiver?

[dave08]

The first I need to know to know if I have access to the app's Application for DI and other initializations...