https://kotlinlang.org logo
#android
Title
# android
d

dave08

12/10/2019, 1:38 PM
Hi! Would anyone have a recently implemented
IntentService
using Coroutines and built on top of a
LifecycleService
?
a

Adam Powell

12/10/2019, 2:18 PM
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
d

dave08

12/10/2019, 2:22 PM
just use coroutines on their own
Does that mean using a
LifecycleService
with
runBlocking { }
? And how would I queue the Intents coming in?
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?
a

Adam Powell

12/10/2019, 2:24 PM
You can start work right away
What's your use case?
d

dave08

12/10/2019, 2:26 PM
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...
I have a SyncAdapter to do this in general, but a Service allows to run this process manually in certain edge cases...
a

Adam Powell

12/10/2019, 2:34 PM
I think WorkManager might be a good fit then
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.
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
d

dave08

12/10/2019, 2:37 PM
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...
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...
a

Adam Powell

12/10/2019, 2:45 PM
if you're using
CoroutineWorker
the lifecycle to think about is usual coroutine cancellation
👍🏼 1
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 🙂
d

dave08

12/10/2019, 2:55 PM
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 😉!
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?
The first I need to know to know if I have access to the app's Application for DI and other initializations...