james
07/24/2022, 11:17 PMval navigateToDetailScreen: (Int) -> Unit
declared
b. navigateToDetailScreen
is passed into the nav graph builder and passed into every composable()
route that might need to call it
c. navigateToDetailScreen
is then passed through as many Composables as required until it is passed into to the Composable that will generate the action from an onClick event
2. Passing the instance of NavController
from the same top level (where the NavHost is declared) down to each screen and into the ViewModel which will then keep a reference to it
3. Wrapping NavController
in a custom navigator class and injecting that custom class into ViewModels where it’s required
if I think about how best to build something flexible, testable, and not too “polluting” of my codebase, #3 seems like the best option, but when I look at examples of what others have built that method seems like the least common, so I find I am second guessing myself and wondering if there’s a problem with that option which I’m not seeingIan Lake
07/24/2022, 11:55 PMColton Idle
07/24/2022, 11:57 PMjames
07/25/2022, 12:01 AMColton Idle
07/25/2022, 12:02 AMjames
07/25/2022, 12:15 AMnavigateToX
parameters passed in
• traditionally, we would simply tell the ViewModel that a click event happened and the ViewModel would own the logic which decides what that means. eg:
◦ we clicked ButtonA, but we might want to either navigate to ScreenX or ScreenY, depending on some logic
◦ the ViewModel will also send what happened here back to our analytics engine
the second point is the more pressing one.. when the Composable owns the navigation event, you can still trigger this stuff from the ViewModel (analytics and deciding which screen to nav to, etc) but it becomes quite verboseIan Lake
07/25/2022, 1:03 AMdewildte
07/25/2022, 7:44 PM