Oh looks like that we must not pass a `Job` to `launch` as i

Question

Oh looks like that we must not pass a `Job` to `launch` as it breaks parent child relationship sweat smile We ve got to take the `Job` returned by `launch` instead

wasyl · Answer

<https github com Kotlin kotlinx coroutines issues 1001> fyi

streetsofboston · Answer

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

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

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

Also afaik all that `cancel ` on a coroutine scope does is to call `cancel ` on the `Job` of the coroutine scope s context

streetsofboston · Answer

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

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

Marc Knaup · Answer

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

Marc Knaup · Answer

`cancel ` is just for canceling the task if the parent is still alive

streetsofboston · Answer

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

Marc Knaup · Answer

Whatever the task is doing is no longer relevant

streetsofboston · Answer

When is it no longer relevant

Marc Knaup · Answer

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

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

Ah that whatever should have its own CoroutineScope When that is being removed it should call cancel on its CoroutineScope

Marc Knaup · Answer

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

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

streetsofboston · Answer

It is very lightweight

Marc Knaup · Answer

So every `User` `Message` `Post` whatever business model I have should have a `CoroutineScope` open mouth

streetsofboston · Answer

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

Marc Knaup · Answer

What target

streetsofboston · Answer

E g a screen UI or a cache tied to a User a database

Marc Knaup · Answer

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

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

Marc Knaup · Answer

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

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

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

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

There is no coroutine failure

streetsofboston · Answer

You said that when the sign in fails

Marc Knaup · Answer

Yes that doesn t mean that any coroutine will fail

Marc Knaup · Answer

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

streetsofboston · Answer

But the Coroutine in which the failed sign in runs will fail

Marc Knaup · Answer

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

Marc Knaup · Answer

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

streetsofboston · Answer

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

Marc Knaup · Answer

No while signed out there is not necessarily a UI

Marc Knaup · Answer

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 thinking face

Marc Knaup · Answer

They describe totally different things and lifecycles

streetsofboston · Answer

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

Thanks I ll check it out

streetsofboston · Answer

In the beginning it is tricky to get our heads around Structured Concurrency But when it clicks it is a very nice system slightly smiling face 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 · Answer

In an ideal world I agree slightly smiling face But I guess we re still a long way to get there `Flow` is a good step forward though

Marc Knaup · Answer

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

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

streetsofboston · Answer

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

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 sweat smile

streetsofboston · Answer

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

Marc Knaup · Answer

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

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

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

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

streetsofboston · Answer

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

streetsofboston · Answer

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

Marc Knaup · Answer

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

I m messing with a well defined lifecycle then

Marc Knaup · Answer

For just one specific task within that scope

streetsofboston · Answer

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

Child scopes make more sense resume pause is a child of start stop is a child of create destroy

streetsofboston · Answer

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

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

Good thing is that I don t support rotation for now smile Isn t AndroidX s lifecycle observation supposed to prevent such temporary lifecycle hick ups due to configuration changes

Marc Knaup · Answer

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

streetsofboston · Answer

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

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

Don t over complicate it slightly smiling face 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 · Answer

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

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

Marc Knaup · Answer

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

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

streetsofboston · Answer

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

afaik that would mess with the back stack

Marc Knaup · Answer

And would be a workaround for a lifecycle which isn t the right one in the first place slightly smiling face

Marc Knaup · Answer

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

Or my weird approach of having a `val reader Flow lt Nothing gt ` 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 · Answer

I wasn t sure what the best approach is to implement that but `Flow lt Nothing gt ` works sweat smile

Marc Knaup · Answer

It s that weird slightly smiling face

streetsofboston · Answer

Is that the Flow lt Nothing gt to keep the message flow alive

streetsofboston · Answer

Haha cool trick but it seems to work slightly smiling face

Marc Knaup · Answer

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

Collection is here slightly smiling face

Marc Knaup · Answer

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

streetsofboston · Answer

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

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

Marc Knaup · Answer

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

But it doesn t feel right as there s no data that actually flows

Marc Knaup · Answer

I guess I need something like `conversationCoordinator markAsReadWhileScopeIsAlive this `

streetsofboston · Answer

Sorry need to go to a meeting slightly smiling face Great chatting with you

Marc Knaup · Answer

u2 have fun

Marc Knaup · Answer

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