I'm not sure how immediate works, doesn't it run o...
# coroutines
I'm not sure how immediate works, doesn't it run on the caller's thread and Hi would be printed before Finished... (maybe I have to add a
Immediate just avoid dispatching if it's main thread. Imagine that without immediate coroutine always does
<http://mainHandler.post|mainHandler.post> { work() }
and with immediate it will do
if (isMainThread) work() else post { work() }
But because you do delay (), it will always also do mainHandler.postDelay(::work, 30), just because it's only way for non blocking delay
If you want to do something on caller's thread you can use Unconfined
But what is exactly your use case for it?
In the end, with immediate, does all the code in
get run before the method exits, or can such code leak? I have a SyncAdapter that I need to use its service's lifecycleScope on
But I don't want work to leak
And runBlocking won't give me the Service's scope, so if Android kills the service, the task might leak
It will leak if it will not be cancelled
Same as with other dispatcher
That's why I want to use
Yes, make sense, I'm still didn't get your case
Do you launch something in a service?
Copy code
override fun onPerformSync(
			account: Account,
			bundle: Bundle,
			s: String,
			contentProviderClient: ContentProviderClient,
			syncResult: SyncResult
	) = coroutineScope.launch {

		syncEventTrigger.onSyncStart(context, syncResult)
				.onStart { i { "Sync Started" } }
				.onCompletion { i { "Sync Stopped" } }

    }.let { Unit }
Which Android runs in the context of a bound service
So I made that service into a
that provides me with a
extension (from ktx)
But I'm afraid onPerformSync will exit before the tasks are finished in
Then Android might unbind the Service and cancel all my tasks because it thinks I'm finished already
That's why I wondered that maybe immediate maybe stops onPerformSync from exiting since it's running on it's thread
If so, just cancel scope on service.onDestroy
I don't understand how that would help? That's handled by
automatically I think, the problem knowing whether onPerformSync exits before the work is all done...
Unless you mean to use runBlocking, and just handle the cancelling myself?
(which might be a bit harder from an adapter using a bound service...)