Before migrating from coroutines experimental, i w...

# coroutines

[Harun]

Before migrating from coroutines experimental, i was able to use the launch as in the above snippet. Trying to do the same on Kotlin 1.3 and am not able. What am i missing?

-.kt

[gildor]

You missed migration to structured concurrency

[gildor]

direct replacement for standalone launch would be GlobalScope.launch

[gildor]

See release notes of 0.26
https://github.com/Kotlin/kotlinx.coroutines/releases/tag/0.26.0

[Harun]

Was reading about GlobalScope.launch on ,its not recommended since it will tie the lifecycle of your coroutine to the whole application

[gildor]

correct

[gildor]

same as old standalone launch

[gildor]

but looks that you manage lifecycle manually using field with Job instance

[gildor]

so should be fine for you

[gildor]

there is no difference comapring to old standalone implementation

[gildor]

but in general better to migrate to CoroutineScope for you component

[gotoOla]

When it comes to backend services that are running within a docker container (e.g. one JVM per docker container with one app running in it) is there any benefit in creating a coroutineScope vs running Globally?

[Harun]

Yeah using it in a view model so that when the view model is destroyed i cancel the job

[gotoOla]

if the Services that are running in the app are singletons (i.e. the lifetime of the services is the same lifetime as the applications)

[Harun]

The problem i had with coroutineScope is that it requires to be called from a suspending function

[gildor]

When it comes to backend services that are running within a docker container

It’s not related to docker or type of your hardware.
It depends only on coroutine lifecycle.

Even for BE it make sense to limit lifecycle of coroutine in some cases, like coroutine has request lifecycle

If all your coroutines are global and should be stopped only when app is killed than no, no difference, use global ones

[gildor]

The problem i had with coroutineScope is that it requires to be called from a suspending function

I don’t understand what is your problem. Sure, you need it only in suspend function because this block is suspend while running child coroutines. You can create instance of scope using constructor instead if you want. But you don’t need it if you have some lifecycle-aware component (like Android Activity/Fragment/ViewModel)

Anyway. check guides and examples first, they should answer on most of you questions

[Harun]

Okay thanks alot for the clarification

[acando86]

In regard of whether structured concurrency is relevant for backend development or not, my way to visualise structured concurrency in general (please correct me if i'm wrong) is that it's not just a way to confine/delimit the overall scope of coroutines within the lifecycle of a part of your application , but it's really a way to properly structured nested coroutines all the way down in some sort of parent - child relationship. It's not just a matter of - let's say - release your coroutines resource when a screen or android activity is destroyed (that's something that was doable before manually to some extend by keeping a reference to the job when invoking launch(..) and cancelling) , it's more a way to systematically organise coroutines in some hierarchy so they are aware of their scope and they know how to properly behave for example when an exception occurs or in case some cancellation is triggered (a typical example here being parallel execution using async/await or equivalent statements)