A modern programming language that makes developers happier.

kotlinlang

What is the difference between using these two scopes?
```val scope1 = rememberCoroutineScope()
val scope2 = LocalLifecycleOwner.current.lifecycleScope```


Suppose both of these were in a composable screen, scoped to a particular destination. In my specific case I have something like

```bottomSheet(...) {
  val scope = /* one of the scopes I'm asking about */
  
  MyScreenContent(
    onClickSomething = {
      scope.launch {
        val someResult = doSomethingSuspending()
        if (someResult is success) {
          navController.navigate(...)
        }
      }
    }
  )
}```

I am under the impression that `LocalLifecycleOwner.current` is the lifecycle of the bottom sheet in the example above

`LocalLifecycleOwner` is generally going to be very broadly scoped, usually to whatever activity, fragment, or navigation destination is above you. `rememberCoroutineScope` returns a scope that is a child of the composition effect scope and is cancelled when the call to `rememberCoroutineScope` leaves the composition. Dispatchers and other context elements may differ between the two; for example the lifecycle scope is generally not going to have the `MonotonicFrameClock` available that is required for most of the compose animation apis to work

Very interesting, thanks for the answer Adam!

I wouldn't personally get into a habit of using `LocalLifecycleOwner.current.lifecycleScope` for things but there are occasional reasons to use it depending on what other abstractions you're invoking/appealing to. I would probably avoid the kind of usage in the snippet above.

In my specific case, the user has clicked something that will launch a Chrome Custom Tab. I want to call `CustomTabsSession.validateRelationship()`  at this point, because this could fail in a variety of ways. Most of these ways are just programmer error, I think, but some could perhaps warrant handling in the application (maybe there was a timeout, e.g.)

The CustomTabs service is already running in `LocalLifecycleOwner.current`, which is what triggered this question

(I am getting `LocalLifecycleOwner.current` at the point where I create the NavController)

if I were to write a suspend-friendly version of the custom tabs apis I'd probably do it in such a way that doesn't have any bearing on which scope something like `validateRelationship` is called in

but when you want the call to continue vs. get cancelled depending on the state of the composition and whether the user has done something navigation-like to change their context is more of a UX design question for the specific case

In my case I wrote a `class CustomTabsNavigator : Navigator&lt;CustomTabsNavigator.Destination&gt;`

Currently it has a CoroutineScope property because this is handy for a variety of things.

But anyway this is kinda getting down into the weeds