If each DestinationNavigator would know the StackEntry.Id of the entry it's created for we could optimize certain operations:
- Result APIs wouldn't need to look up an entry based on the route in this case and wouldn't require a generic parameter for said route.
- We could have a more specific
navigateBack() that no-ops when the id is not on the back stack anymore which would prevent often encountered issues with user actions triggering back twice.
Other considerations:
- We'd need to add
StackEntry.Id to the public API.
- The public
NavDestination API could pass the id together with the route to the composable.
- In codegen it could be automatically injected.
The main downside is that the way of defining DestinationNavigator becomes more verbose.
@Inject
@SingleIn(ExampleRoute::class)
@ForScope(ExampleRoute::class)
@ContributesBinding(ExampleRoute::class)
class ExampleNavigator(hostNavigator: HostNavigator, stackEntryId: StackEntry.Id) : DestinationNavigator(hostNavigator, stackEntryId) {
// ...
}
If each
DestinationNavigatorwould know theStackEntry.Idof the entry it's created for we could optimize certain operations:navigateBack()that no-ops when the id is not on the back stack anymore which would prevent often encountered issues with user actions triggering back twice.Other considerations:
StackEntry.Idto the public API.NavDestinationAPI could pass the id together with the route to the composable.The main downside is that the way of defining
DestinationNavigatorbecomes more verbose.