Great question! To handle a platform specific forms of navigation (like android back navigation, or iOS gestures) you will need platform specific implementations. These implementations can be used in our shared code with KMP's "expect" and "actual" approach. I haven't made any videos on expect and actual yet, but there's a lot of good information about it here: kotlinlang.org/docs/multiplatform-expect-actual.html
@@MaximumDevelopment oh one more thing. Can i just use navCrontroller.popBackStack instead of handling the backpress right? like for example for splash screen.
If I understand your question correctly, yes you can. You can use the navController in your code without any need for user input. For instance, you could have the app start on a splash screen (with the home screen in the back stack), and use a coroutine to navigate back to the home page after a brief delay. There's a lot of creative ways you could approach this.
Great question! This could warrant its own video but here are my thoughts. For starters, we could implement our custom nav graph in its own composable, and pass our state into it. This would clean up our App component, but we would still have to deal with a large, unwieldy list of screens elsewhere. We actually have this same problem with most navigation libraries. Going beyond this, we could implement a series of nested nav graphs, breaking up our monolithic graph into smaller chunks (where navigation from certain screens would branch into different graphs). This is just one possible solution. If it were my project, I would also consider how many standalone screens could be reduced to sub-screens (removing them from the graph, and handling their visibility within their parent composable). As always, there could be many solutions to this, with differing pros and cons. I’m curious how you would approach solving this. Thank you for watching, and for your thought provoking question!
Another great video. Thank you
Thanks for the support!
Great content. While watching and implementing can understand how the compose navigation library written for android.
Thank you! I’m glad you found it helpful.
Wow! Great video. I use Avenger for common navigation. I didn't know what you shared is supported.
Thank you! It's a great time to be a multiplatform developer. There's so many excellent options available to us.
@@MaximumDevelopment yes, love how clear you are in your explanation. So crystal clear!
nice , and great content,❤
Thank you 😁
Great Video Sir 💯
Thank you, I appreciate it!
Hello, simple good video, i have a question. How can you handling backpressed in this KMP? Like onbackpressed or something.
Great question! To handle a platform specific forms of navigation (like android back navigation, or iOS gestures) you will need platform specific implementations. These implementations can be used in our shared code with KMP's "expect" and "actual" approach.
I haven't made any videos on expect and actual yet, but there's a lot of good information about it here:
kotlinlang.org/docs/multiplatform-expect-actual.html
@@MaximumDevelopment oh right! Thank you for the info. I will check it out.
@@MaximumDevelopment oh one more thing. Can i just use navCrontroller.popBackStack instead of handling the backpress right? like for example for splash screen.
If I understand your question correctly, yes you can. You can use the navController in your code without any need for user input. For instance, you could have the app start on a splash screen (with the home screen in the back stack), and use a coroutine to navigate back to the home page after a brief delay. There's a lot of creative ways you could approach this.
what happens when you got 50 screens? we list them all in the App component?
Great question! This could warrant its own video but here are my thoughts.
For starters, we could implement our custom nav graph in its own composable, and pass our state into it. This would clean up our App component, but we would still have to deal with a large, unwieldy list of screens elsewhere. We actually have this same problem with most navigation libraries.
Going beyond this, we could implement a series of nested nav graphs, breaking up our monolithic graph into smaller chunks (where navigation from certain screens would branch into different graphs).
This is just one possible solution. If it were my project, I would also consider how many standalone screens could be reduced to sub-screens (removing them from the graph, and handling their visibility within their parent composable).
As always, there could be many solutions to this, with differing pros and cons. I’m curious how you would approach solving this.
Thank you for watching, and for your thought provoking question!