Closed BVantur closed 2 years ago
Hi @BVantur π
First of all, thank you so much for the very detailed explanation π And thank you for the kind words.
In my understanding of jetpack's compose navigation, we shouldn't use nested NavHosts. I also found this answer which goes in the same direction: answer link
So, if we follow that advice, you should put Scaffold at the top level and use only one DestinationsNavHost. Then, both "HomeScreen" and "InternalDetailsScreen" would be part of a nested navigation graph. After this, you would only have one NavHostController, and it (or the DestinationsNavigator wrapper) could be used to navigate anywhere. Your Scaffold could react to the current destination, and in case that destination is not part of the "nested nav graph", then we just hide the Scaffold elements.
I'll take your github project and make some changes because I also wanna try putting into reality what I'm saying here. Maybe I even open a PR there π no promises though!
Thank you again, and please let me know if my answer helped you
Actually, it's easier to just post a patch here π
This is meant for your compose-destinations
branch.
Thank you very much @raamcosta ;) We will use your proposed solution for our use case. I didn't know that there should be only 1 NavHost for the whole app. I am used to using more NavHosts in the old Navigation component, so I thought I can do this with Compose as well. To be honest, I am not a fan of this kind of solution that hides or shows something at the top of the whole UI hierarchy, depending on what is present somewhere down in the tree. But is working for us, so thank you! ;) Is not a hard solution to implement and to understand. You can go ahead and close the issue if you like. ππ
Glad that helped π
I guess is one of those things that are much more ok to do with compose, since it's all about reacting to stuff. The next version of the library is going to change some things and add some features. I have been doing major internal refactor and such. I noticed you had nested NavHosts and in that sample app and it seemed to work fine. To be honest there is a clear lack of documentation around some things in compose navigation. That is why I am working on it being possible to have multiple NavHost calls in my library. Even though I didn't think it would be correct, now I don't know anymore and I prefer to leave that decision up to the developers.
With this new version it will be easier to import dependencies, you will be able to pass Parcelable, enums and Serializable as navigation arguments and more. But some APIs will change a bit. Stay tuned for that and let me know if you have any issue migrating. Also I will be having two versions one with beta dependencies (beta compose, beta accompanist) and one for stable dependencies.
If there is anything else I can help you with, don't hesitate to reach out. Even with a Twitter DM for quick questions π
@raamcosta we are currently in the POC phase of our new project and really do like your lib and would like to use it as it does remove so much boilerplate and makes the code so much more readable. We did implement Drawer and bottom navigation at the top level of our composable hierarchy, but that is starting to feel a bit hacky, we would really love it to have the drawer and bottom navi only where needed as subgraphs, so to have a separation of concerns. Would you share with us please when would you expect to offer this possibility with your lib?
Hi @rubinbasha π
Very soon. I have been working on the next release and it is pretty much ready. The only thing holding me back from releasing it today is that I would like to update all the docs in the wikis before I do that.
Even so, I'm expecting to release it before the end of this week. If you want to try the new version out even if there will be some documentation lacking, I can maybe release it and simply don't advertise the new version on GitHub. If that would help, do let me know.
@raamcosta that is amazing news already, if it is a matter of days or just a week or so , then I would by no means want to rush you. I deeply thank you for the amazing job. Honestly this lib was the first thing I searched for when I wanted to enter the @Compose world π
Hey @raamcosta π
If you will add support for multiple NavHost calls, that would be awesome. ;) In our sample app, we are getting really complex MainActivity with handling AppBar and additionally handling BottomBar for some screens in it. Another thing that we are currently having trouble with because of a lack of support for multiple NavHosts is with drawing under the system. Sometimes we show BottomBar/AppBar and when we don't show it, we currently need to handle inset padding separately because contentPadding from Scaffold doesn't always return expected content padding. Do you have any timeline on when you will publish those changes?
Hi @BVantur !
Yeah, as I told @rubinbasha I do have a version ready to be released with that and other changes and features. I'll call it 1.0-beta cause I feel this version deserves to be the 1.0 version as it changes quite a few things π The only thing I am doing now is updating the wikis.
But you know what, I have used your repository to test the new version, so, what I can do is I can release this new version to maven central, and make a PR in your repository with my changes, so you can see how things work and you can start working immediately.
Later when I finish the documentation I can update the Readme and make the release official.
I will do this later today after work π I'll reply here to let you know.
Ohh I see now. I didn't refresh the page and didn't see new comments added here. Sorry for bothering you with more or less the same question. But great news that you have already made those changes. Can't wait to try out your new version of the library. Looking forward to it!! ππ
@BVantur
There you go: https://github.com/BVantur/ComposeNestedGraph/pull/1
Any questions about the changes, let me know :)
Although the version is not "public" in the sense that I still want to update wikis before that, you can totally use it :) (btw I forgot to remove the dependency in the PR, but you don't need to import "androidx.navigation:navigation-compose" as it is now a transitive dependency of my library)
@raamcosta Thanks a lot. We've checked your changes and we have a couple of problems on which we couldn't find the solution on how to solve.
We've created a new branch, where we adapt your changes with the new version of the library. I also added TODO comments in the code on where we had troubles. Here you can check the changes we made.
(This part is tagged in our code with number 1# next to TODO comments) The main problem we are currently having is how to use DestinationsNavigator for our nested NavHost in combination with Drawer items. So we went a step further with the code that was provided to us by you through that Pull request. We said that we want to have more items in the Drawer menu and we want to switch content in nested NavHost, by selecting items from the Drawer menu. The first thing that we noticed was that we don't have DestinationsNavigator from nested NavHost available, so for this purpose, we've created a lateinit variable called childNavigator in our HomeScreen composable function. This childNavigator variable gets filled after we set up DestinationNavHost composable for ProfileScreen. After that, we use that childNavigator to do the navigation for our drawer items, but we've got some problems with this approach. Navigation for us happens only for the first time. After that, the navigation doesn't work anymore on any of the items from the Drawer menu. But if we navigate back with the system back button, for example, we can do another navigation from the Drawer menu. We've played around to try to make it work, but we didn't find a solution for this. Can you maybe help us with this use case? Are we doing something wrong in our code?
OUR DRAWER CONTENT:
(This part is tagged in our code with number 2# next to TODO comments) Additionally to the above problem would be great if there would be the possibility to send some optional arguments to the starting screen of a nested NavHost's screen. I am not sure how to do that with the current way of having that composable call for the start destination inside of nested NavHost.
Hi @BVantur !
Check this: https://github.com/BVantur/ComposeNestedGraph/pull/2
Let me know if there is any clarification or anything else I can help you guys with!
Thank you very much. We didn't know that there is such an easy possibility to access the parent navigation controller. This looks really nice. We will keep you posted if we will need any clarification on anything else.
First of all, let me say we really appreciate the effort put into this library. We really like how easy it is to do navigation with this library in Android Compose. Thank you very much. πππ
Nevertheless, we stumbled on some problems with our use case. We are planning to start developing with Jetpack Compose and we are now in the phase of researching which navigation approach should we use in our app. For better understanding, here is a github repository to the project with the below-mentioned problem.
What we need is to have multiple DestinationsNavHosts in our app because we are using one DestinationNavHost(root) that is used for the main flow of the app(SplashScreen -> HomeScreen,ExternalDetailsScreen) and another DestinationNavHost(nested) that is used as a container for Drawer menu items(ProfileScreen, InternalDetailsScreen) in the home screen.
OUR APPLICATION FLOW:
So, our pain point in our application is ProfileScreen. There we have 2 buttons. Button with the text "Inside details screen" opens a new screen inside nested DestinationNavHost as is presented with InternalDetailsScreen above in the Image. For that, we use DestinationsNavigator from ProfileScreen and it works fine. But we have a problem with the button that has "External details screen" for a text, and here is expected to show a new screen in the root DestinationNavHost. If we use DestinationsNavigator from ProfileScreen, the screen is presented as InternalDetailsScreen. But we want to replace the content in root DestinationNavHost. Currently, we are solving this with a companion object on MainActivity which stores the DestinationsNavigator in it from HomeScreen and then we access it when we press on the "External details screen" button to navigate to the correct screen.
Is there a capability in this library that we are not seeing to do that kind of navigation with parent DestinationsNavigator? We would really appreciate it if you could point us on how to use that with the current state of the library?