Hi Would anyone have a recently implemented `IntentService`

Question

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

Adam Powell · Answer

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 · Answer

gt just use coroutines on their own Does that mean using a `LifecycleService` with `runBlocking ` And how would I queue the Intents coming in

dave08 · Answer

gt 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 · Answer

You can start work right away

Adam Powell · Answer

What s your use case

dave08 · Answer

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 · Answer

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

Adam Powell · Answer

I think WorkManager might be a good fit then

Adam Powell · Answer

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 · Answer

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 · Answer

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 · Answer

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 · Answer

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

Adam Powell · Answer

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 slightly smiling face

dave08 · Answer

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 wink

dave08 · Answer

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 · Answer

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