I’m a bit unsatisfied with code like this:

@Composable
fun MyNavHost() {
  val launcher = rememberLauncherForActivityResult(contract = ...) { result ->
    // handle 'result'
  }

  NavHost(...) {
    composable(...) {
      MyScreen(onClick = { launcher.launch(...) })
    }
  }
}

My assumption is that we would want a 1-1 relationship between an ActivityResultLauncher and a nav graph Destination. Right? This trivial example is fine, but if you add more and more screens (most of which do not rely on a launcher), and more launchers (photos, permissions, whatever), it’s hard to tightly scope the related concerns. I would like to have code where the

onResult

callback is adjacent to the definition of the Destination.

I tried to make a custom navigator

class ActivityResultNavigator : Navigator<ActivityResultNavigator.Destination>()

But I’m not sure what to do about the ActivityResultLauncher. Using

rememberLauncherForActivityResult

doesn’t really help since it has the same problem as my above sample code. That is, I can’t create the launcher adjacent to the Destination, because it relies on a Composable context. I could define my own ActivityResultLauncher but I’m unsure how to manage its lifecycle in the context of Navigation and Compose.

I’d appreciate any feedback or suggestions. Am I looking at this the wrong way?

Which means you could write it as

composable(...) {
  val launcher = rememberLauncherForActivityResult(contract = ...) { result ->
    // handle 'result'
  }
  MyScreen(onClick = { launcher.launch(...) })
}

or put it inside

MyScreen

If I can put it in the composable() block, that’s much better

Thanks for responding!

it is more that the positioning within the composable that matters, as it relies on

rememberSaveable

under the hood