Full Guide to Nested Navigation Graphs in Jetpack Compose

hey guys and welcome back to a new video in this video I will give you a full guide on nested navigation graphs in Jetpack compose what these are how you can use them and why you should use them in which scenarios every Android developer should definitely know about this concept so let's jump right into it and the first thing you need to play around with this is of course the navigation dependency of compose so in your build.gradle app file you need to add this line of code and this is just for collecting state from a viewmodel so this is optional but you can also add that and to start right from the basics let's go to main activity and in here what we want to do is we want to first of all set up our main navigation graph a navigation graph in the end just defines different destinations of different screens in our app and from which screen we can go to which that is at least how it previously worked with Android when we used XML when we use compose then we have the so-called routes so it's very similar to just a URL and now we can actually go from any screen to any screen at any time just using this route so far so good you maybe already know this concept the first thing we need is a so-called nav controller which we get with remember nav controller and with that we just get access something we can use to jump between different screens and we now need to assign this nav controller to a nav host which is our main nav graph which defines all our screens so we passed this here and instead of this graph we want to pass a start destination which is just a route so for example the home screen or so and then here we have a block of code where we can add our screens and for the sample I want to assume that we have some kind of calendar app with an online thing so we have a feature where the user needs to log in to see their personal calendar entries and then we have a main calendar feature now I want to teach you how I would structure the navigation graph for that so usually if you're a little bit familiar with navigation compose then we use these composable calls here to define a specific screen in our app so for example our login screen and then here we get a block or we can place any type of composable like a text but usually that is now your real screen and you can of course put all your screens as such composable blocks in this outro nav host and you will be able to navigate between these but with this we don't get the advantages of having nested navigation graphs and NASA navigation graph is basically yeah it is a sub graph of our big main navigation graph so let's consider our feature in this app for example so the user might start on the login screen if they're not logged in from there we might have a button to go to the register screen and we might have a button for them to reset a password so three screens that belong to this auth feature and the thing is that we actually only want to navigate inside of this feature to these different screens so in an app you're usually not able to go to the forgot password screen from the main feature so it's usually just a little button in the login screen and the same for registration so the whole navigation for this feature happens inside of the feature and these screens and only if the user successfully logs in and then you have one jump from the whole first kind of graph to the next graph which is then the the main graph where the user can see their calendar entries maybe add edit one and these kinds of things and in the end all these queens that belong to one feature can be put in the so-called nested navigation graph and we can do this in compose using navigation and now every single navigation graph every nested graph has on the one hand the star destination just like this main nav graph so here this will be the screen that will show up first when we navigate to this whole graph so every single nested navigation graph needs to have one start destination as well which would be long in here and we need a route so every single lasted navigation graph needs to have a route because from this point on we don't navigate to this login screen directly anymore but to this whole graph at least if we navigate to this from outside of this graph so the route would be our feature so off for example and then we can also put in our composer blocks inside of this nested graph so in here we could also have two more on the one hand one for register and one for forgot password for example so we expect to get from the forgot password screen maybe to the login screen from the login screen to the registration screen and back but once we leave this feature this off feature which we can only leave by successfully logging in then we don't want to have all these screens on our back stack anymore and that is one big advantage of having such a nested navigation graph that we can pop the whole graph from our back stack another big Advantage is that this nested navigation graph now has its own backstack entry which is the reason why we can pop this whole graph from the back stack and this means that we can also scope a view model to such a backstack entry so we can scope a view model to this whole graph and not only to these specific screens anymore so that way we can effectively share the same view model instance in a whole feature and as soon as we pop the whole graph the view model will also be cleared and the way we can do this is we can create a little helper function composable this will extend a nav backstack entry and we call this shared view model and all this will need here is access to our nav controller and it will return an instance of our view model but since we want to be able to pass or to return any view model here we need to make this a generic type T here we need to specify this first of all that we have this type T and then inside we first of all need to get access to the route of the current NASA navigation graph we're in so if we call this for example from the registration screen so with this nav backstack entry we have here then we need to retrieve the route of the parent navigation graph so the power navigation graph is this navigation graph we specified here and then at that navigation graphs backstack entry so first of all Val nav graph route and we can get that using destination dot parent to refer to the parent which is now a navgraph as you can see and then saying that route if that's now we just return view model here which is the normal compose function which we turn the view model of course if you're using dagger Hilt then this would need to be healed view model correspondingly um but let's leave it like this and then with this Navigator route we can get access to the parent entry so the parent backsec entry which is a remember call so when oops not that one um import that and whenever this backstack entry we call this function on changes we want to get the parent entry from our nav controller so we get the exec entry where we need to pass the route we want to get the backstack entry 4 which is now the navgraph route we fetched before and then with this parent entry we can scope our review model to this exact entry so to our navigation graph so we can return viewmodel um and here we pass our parent entry right now we could call this on any type here so even on things that are on the viewmodel which is why we need to add this information here so that the steam must inherit from viewmodel and I shouldn't call The Constructor here and then we get another little issue which is simply that we need to make this T Reef fight and inline this so that we have access to this type information here instead of this function but now this is complete and we have a very convenient helper function to get access to a shared viewmodel inside of a nested navigation graph so if we go for example to our route create a sample view model like this make that inherit from viewmodel and we now want to share this between our whole auth feature we can go inside of these screens and say a value model is equal to 8. shareviewmodel and passing our nav controller we need to specify that we want to have a sample view model and that's it and if we now put this in every of our screens inside of this nested navigation graph all these will be the same view model instance but as soon as we pop this above our Nest navigation graph from the back stack the viewmodel and its state will be cleared which is exactly what we also expect because when we clear business the navigation graph from backstack so when we log in for example then we also don't need the the shared state of this view model for the auth feature anymore and the same way we could now go ahead and create more nested navigation graphs inside here navigation this time the start destination could for example be calendar overview so or you just see all your calendar entries the route of this will be the calendar feature and then here you again have two composables which are now part of this calendar sub graph so calendar overview and then we can also have our calendar entry screen for example we get more detailed information about a calendar entry but there might still be use cases for a screen outside of a subgraph and that is for example if we have a screen here which might be an about screen which should be reachable from from any feature you might get to an about screen from the calendar feature but you might also have a little button that leads to the screen or on the auth feature so then you can also just put this inside of the main graph and you will still be able to navigate to that and last but not least I want to show you how you can now navigate from one graph to another and how you can also make sure that the previous graph is not contained on the back deck anymore so if you log in successfully then you don't want to be able to go back to the login screen or any of the auth related screens so let's say on login we have a button and when we click this button we want to navigate to the calendar overview screen so what we can do is we can say nav controller dot navigate and the route we want to navigate to is calendar overview no we don't want to navigate to that we want to navigate to calendar because that is the route of our next NASA navigation graph and since that has the start destination of calendar overview that will be the screen where we will get to so whenever you actually navigate from one feature to another you just navigate to the nested navigation graph instead so instead of the specific screen route you want to get to however with this we didn't pop the previous so the auth graph yet from the back stack we can do this by adding yellow Lambda in here and saying prop up to and we specify the route until we want to pop this from the back stack this would be our auth graph here and we want to set inclusive to true so that also this route will be popped from the back stack so that means no matter how much you navigate it within this graph as soon as you log in all this graph will be popped from the back stack so you don't really need to find out how many screens of the all feature are on your backs like how many do you need to pop and these kinds of things so I really recommend to start using such nested navigation graphs if you have a set of screens that belong together and where these are usually not reachable directly from other screens except for the start destination of that then that makes total sense and it's also very easy to share a viewmodel in such a nested navigation graph so if you enjoyed that and then you will definitely also enjoy my more advanced Android premium courses which will prepare you for the industry as an Android developer so that sounds good to you click the first link in this description check these out and I will wish you an amazing rest of the week and see you back in the next video bye bye thank you

Channel: Philipp Lackner

Views: 46,096

Keywords:

Id: FIEnIBq7Ups

Length: 12min 1sec (721 seconds)

Published: Wed May 24 2023