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

# compose

[Chris Fillmore]

What is the difference between using these two scopes?

val scope1 = rememberCoroutineScope()
val scope2 = LocalLifecycleOwner.current.lifecycleScope

[Chris Fillmore]

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(...)
        }
      }
    }
  )
}

[Chris Fillmore]

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

[Adam Powell]

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

[Chris Fillmore]

Very interesting, thanks for the answer Adam!

[Adam Powell]

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.

[Chris Fillmore]

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.)

[Chris Fillmore]

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

[Chris Fillmore]

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

[Adam Powell]

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

[Adam Powell]

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

[Chris Fillmore]

In my case I wrote a class CustomTabsNavigator : Navigator<CustomTabsNavigator.Destination>

[Chris Fillmore]

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

[Chris Fillmore]

Thanks for the discussion