# compose

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<CustomTabsNavigator.Destination>

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

Thanks for the discussion