Oh, looks like that we must not pass a `Job` to `l...

# coroutines

[Marc Knaup]

Oh, looks like that we must not pass a Job to launch as it breaks parent/child-relationship 😅
We’ve got to take the Job returned by launch instead.

[wasyl]

https://github.com/Kotlin/kotlinx.coroutines/issues/1001 fyi

[streetsofboston]

It could even be argued not to have a cancel method as well, for a common MyTask. Cancelling the CourotineScope should suffice.

Instead, a special MyCancellableTask should offer this extra cancel functionality, to indicate that this (calling cancel) should be used with some care.

[Marc Knaup]

Thanks!

Even after using coroutines for months now I still cannot fully wrap my head around how to implement some basic things properly. Like for example there’s no easy way to create a child coroutine scope without directly invoking code in it.

The worst thing is that most approaches “somehow work”, so the resulting errors are tricky to spot.

[Marc Knaup]

@streetsofboston true, not every task is cancellable. A separate sub-interface makes sense.

Cancelling the coroutine scope doesn’t make sense. The task is just one operation in the scope and I don’t want to cancel others.

[Marc Knaup]

Also, afaik all that cancel() on a coroutine scope does is to call cancel() on the Job of the coroutine scope’s context.

[streetsofboston]

If the cancellation of your task is related to an object ending its lifecycle (eg the object, that is the target of the data of your task, goes away), you should create a CoroutineScope for that object.

[streetsofboston]

You want to avoid managing the cancellation of all MyTasks that you launch….

[Marc Knaup]

But that parent-child relationship is already established when I launch my task?

[Marc Knaup]

cancel() is just for canceling the task if the parent is still alive.

[streetsofboston]

If the parent is still alive, what are the use cases for canceling a MyTask?

[Marc Knaup]

Whatever the task is doing is no longer relevant?

[streetsofboston]

When is it no longer relevant?

[Marc Knaup]

Well that depends on the use case.

A current example is that I can stop a validation process if whatever is being validated has been removed.

[streetsofboston]

Sorry to ask these questions, but in most use-cases you don’t need to cancel a launch’s Job. The CoroutineScope should handle it.

[streetsofboston]

Ah… that ‘whatever’ should have its own CoroutineScope. When that is being removed, it should call ‘cancel’ on its CoroutineScope.

[Marc Knaup]

So I should potentially create a crazy amount of coroutine scopes for all kinds of objects that may be used in any long-running coroutine?!

[streetsofboston]

Yup. A CoroutineScope is just an interface around a CoroutineContext that has a Job.

[streetsofboston]

It is very lightweight.

[Marc Knaup]

So every User, Message, Post - whatever business model I have - should have a CoroutineScope? 😮

[streetsofboston]

No. But the target of that User, Message, Post should have its own CoroutineScope.

[Marc Knaup]

What “target”?

[streetsofboston]

E.g. a screen/UI, or a cache tied to a User, a database,

[Marc Knaup]

Yeah that’s clear.
But what if there is no natural target?

The data I’m validating belongs to an app’s AuthticationManager which has app-lifetime.

[Marc Knaup]

I guess in that case I could subdivide the lifecycle further in signed-out and signed-in.

[Marc Knaup]

But even then the lifetime of what needs to be validated (some sign-in credentials) may only need validation for a fraction of the lifetime of the signed-out state.

[streetsofboston]

Yes, but then you don’t need to cancel it, i think. Just let the sign-in run its course. The AuthenticationManager will always be there to receive the sign-in result.

[Marc Knaup]

I need to cancel it if the sign-in is complete (that’s easy as sign-out lifecycle ends) but also if the sign-in fails due to invalid credentials (in some cases), in which case a validation is no longer needed.

[streetsofboston]

On a failure of a Coroutine, if a child-coroutine fails or gets cancelled, all its sibling-coroutines fail/get cancelled. No need to cancel it manually

[Marc Knaup]

There is no coroutine failure.

[streetsofboston]

You said that when the ‘sign-in’ fails….

[Marc Knaup]

Yes, that doesn’t mean that any coroutine will fail.

[Marc Knaup]

Also, only a subset of potential sign-in error causes must cause the validation task to be stopped.

[streetsofboston]

But the Coroutine in which the failed sign-in runs will fail….

[Marc Knaup]

Why, if I catch it and report the sign-in error to the UI?

[Marc Knaup]

Also, the validation is bound to the signed-out lifecycle, not the sign-in process.

[streetsofboston]

Ah, the UI is the target of all your asynchronous code. Then your UI (screen) is the CoroutineScope (having a SupervisorJob).

[Marc Knaup]

No, while signed out there is not necessarily a UI.

[Marc Knaup]

sign-in/sign-out lifecycle and UI lifecycle have some overlaps. That’s about it. None is child of the other and cannot be either 🤔

[Marc Knaup]

They describe totally different things and lifecycles

[streetsofboston]

Ah… they have overlapping lifecycles.

I wrote a blog post a while ago about lifecycles and how to tie them to CoroutineScopes. The overlapping of CoroutineScope (switching between them) is also mentioned toward the end of it.
https://medium.com/swlh/how-can-we-use-coroutinescopes-in-kotlin-2210695f0e89

[Marc Knaup]

Thanks, I’ll check it out

[streetsofboston]

In the beginning it is tricky to get our heads around Structured Concurrency. But when it clicks, it is a very nice system 🙂

Often, when your code starts managing Jobs and Cancellation explicitly, it is often (but not always!) a code-smell that may be able to get solved by Structured Concurrency.

[Marc Knaup]

In an ideal world I agree 🙂
But I guess we’re still a long way to get there. Flow is a good step forward though!

[Marc Knaup]

With UI it’s quite easy as there is a direct relationship between how long you see the UI component and the related coroutine scope.
It’s already a little tricky on Android though because depending on the use-case you may need create…destroy lifecycle, start…stop lifecycle or resume…pause lifecycle.

[streetsofboston]

Flow uses Structure Concurrency too. It is like a suspend function, with respect to Structure Concurrency, but it can produce multiple values instead of just one 🙂

[streetsofboston]

Don’t tie the onPause/onResume to a lifecycle (CoroutineScope). That is just paused and resumed.
Instead, tie a lifecycle/CoroutineScope to the lifecycle of a ViewModel; starts on the first creation of an Activity, dies on the onDestroy with ‘isFinished() == true’ (that is when the ViewModel’s onCleared is called)

[Marc Knaup]

That’s dangerous though. I may keep network and other background events running even when the entire app is in background. The activity isn’t destroyed then, only stopped.

I had that problem just recently 😅

[streetsofboston]

Yup, that is true. But what happened, what went wrong when the app was in the background?

[Marc Knaup]

It kept polling the server every 10 seconds for data that the user isn’t even able to see as the Activity is stopped.

[Marc Knaup]

And for a chat I have tied the “automatically marking messages as read” logic (in a chat) to the resume…pause lifecycle of an Activity. Messages shouldn’t be marked as read if the Activity is merely started but not resumed. Or worse - not visible at all.

[streetsofboston]

Ah… that is different than a one-shot ‘get-me-some-data-from-the-network-and-then-show-it’ case.
Having a Job for this use-case would indeed make sense.

[Marc Knaup]

Even in a one-shot I expect network requests to be canceled when the user stops seeing the Activity.

[streetsofboston]

For a one-shot, canceling the ViewModel’s CoroutineScope is sufficient for when the Activity goes away.

[streetsofboston]

But if the Activity is just in the background, why cancel the request? The user may come back 2 seconds later…

[Marc Knaup]

Would Android create a new scope in onStart?
Also, my code would have to know that whatever has been set up in onCreate that’s bound to the scope has to be set up again in onStart, which doesn’t seem right.

[Marc Knaup]

I’m messing with a well-defined lifecycle then

[Marc Knaup]

For just one specific task within that scope

[streetsofboston]

Why cancel in the onStop? Your Activity’s views are still there and when the user comes back, they will see the data from the request.
Tie the scope to a ViewModel; starts at the initial creation of the Activity, stops on the final destruction of it (onDestroy with isFinished==true)

[Marc Knaup]

Child scopes make more sense

resume…pause
is a child of
start…stop
is a child of
create…destroy

[streetsofboston]

That could work, but for one-shot requests, why cancel it when the Activity goes into the background? The user could come back. Also, when the phone rotates, onStop is called and you don’t want to cancel the request.

[Marc Knaup]

It doesn’t make sense to waste resources when the app is in background. Depending on the network layer and use case the app may be busy for minutes in the background, including retries and related heavy duty.

[Marc Knaup]

Good thing is that I don’t support rotation for now 😄

Isn’t AndroidX’s lifecycle observation supposed to prevent such temporary lifecycle hick-ups due to configuration changes?

[Marc Knaup]

Otherwise some logic may be necessary to prevent split-second lifecycle deaths and just keep it alive.

[streetsofboston]

When the app is in the background for a while, the OS will pause the app (starve it of CPU cycles). Often, there is no need to manage that yourself.

The AndroidX’s ViewModel is used to prevent such hick-ups. The ViewModel’s lifecycle survives config-changes. But it remains active when the app/Activity is just in the background.

[Marc Knaup]

I don’t rely on the OS to reduce my apps unnecessary activity. Also, the more resources the app uses in the background the worse it may be downgraded by the OS for that.

[streetsofboston]

Don’t over-complicate it 🙂
Create your ViewModel for your Activity. Use the ViewModel’s CoroutineScope (it has one of its own), to launch network requests and such.

[Marc Knaup]

Nope, no background network requests for us.
It also slows down the app.
If you leave a Activity with a heavy API request on a bad connection and go the next Activity, the user will have to wait longer because previous API request(s) are still consuming network resources.

[streetsofboston]

Yup, if you requests are very heavy, then yes, canceling it sooner can be a good thing to do.

[Marc Knaup]

No matter how I turn it, network requests to deliver data for anything but what the user is currently interested in is a bad idea.

The only exception is if the entire synchronization logic is centralized and independent of UI, like in WhatsApp for example.

[Marc Knaup]

Even non-heavy requests can be bad on a mobile connection. We’re talking long delays + multiple retries here :)

[streetsofboston]

Another way of doing this without managing Jobs of individual requests is to ‘finish’ the activity when moving to another activity. That would kill the ViewModel, cancel its CoroutineScope, cancelling all outstanding requests. Rotation/config-changes would not cause requests to be cancelled.

[Marc Knaup]

afaik that would mess with the back stack

[Marc Knaup]

And would be a workaround for a lifecycle which isn’t the right one in the first place 🙂

[Marc Knaup]

If it’s clearly defined like
“network requests live as long as the Activity is visible” then start…stop is that exact lifecycle

[Marc Knaup]

Or my (weird?) approach of having a val reader: Flow<Nothing> which causes new messages in a chat conversation to be marked as read automatically while the Flow has any consumers.

I subscribe to it in the related Activity in the resume…pause lifecycle.

[Marc Knaup]

I wasn’t sure what the best approach is to implement that, but Flow<Nothing> works 😅

[Marc Knaup]

It’s that weird 🙂

[streetsofboston]

Is that (the Flow<Nothing>) to keep the message flow alive?

[streetsofboston]

Haha… cool trick, but it seems to work 🙂

[Marc Knaup]

No, it doesn’t affect message delivery.
It only causes the Flow-generating side to mark messages as read while the Flow is being collected.

[Marc Knaup]

Collection is here 🙂

[Marc Knaup]

It’s a project I’ve taken over which is based on MVP approach. No MVVM yet 😕

[streetsofboston]

I mean, you keep the Flow alive, ie. it remains active in what it is doing (mark incoming messages as read) while the collector is not interested in the Flow’s emissions.

[Marc Knaup]

But I was happy to kick out that stupid RxJava for Flow!

[Marc Knaup]

I mean, you keep the Flow alive, ie. it remains active in what it is doing (mark incoming messages as read) while the collector is not interested in the Flow’s emissions.

Exactly

[Marc Knaup]

But it doesn’t feel right as there’s no data that actually “flows”.

[Marc Knaup]

I guess I need something like

conversationCoordinator.markAsReadWhileScopeIsAlive(this)

[streetsofboston]

Sorry, need to go to a meeting 🙂
Great chatting with you!

[Marc Knaup]

u2, have fun

[Marc Knaup]

Regarding task cancelation - I just have another use case in front of me:
When clicking on a message attachment, a task starts that downloads the attachment and then opens the UI for it. That one needs to be canceled when the Activity stops.
But it also needs to be canceled when the user has clicked on another attachment in the meantime. That is not related to any lifecycle and thus requires a manual cancel.