having an app with two screens, the main screen an...

# compose

[Pablo]

having an app with two screens, the main screen and the places screen, I have a parent App class which haves a composable parent method and I wanna fill it with a nav host and a drawer/rail/bottomnav for navigate. Then, the two screens of the app haves their own classes and their own viewmodels. The problem here is that... where should I keep the current tab selected of the drawer/rail/bottomnav? I mean... that should be in a uistate inside a viewmodel... should the parent app class have their own viewmodel too? In the codelab courses I'm doing they use just a viewmodel for the entire app because the app only haves a single screen... so now I'm not sure what i'm suposed to do

[Pablo]

I created a parent App class with the parent composable because the drawer/rail/bottomnav must be displayed on all the screens, so I suposse it is the correct approach, but then, now I don't know where to store the current selected tab of the drawer/rail/bottomnav

[Stylianos Gakis]

Look at how NowInAndroid does this.
They don't use a VM for it, just a simple state holder that you initialize at your activity, above the NavHost even, and the NavController is hoisted high up so that it can be passed in that class so that you can do still like determine when the NavRail/bottombar should show.
I do the same here too if you want yet another example https://github.com/HedvigInsurance/android/blob/develop/app%2Fapp%2Fsrc%2Fmain%2Fkotlin%2Fcom%2Fhedvig%2Fandroid%2Fapp%2Fui%2FHedvigAppState.kt#L95-L113

[Stylianos Gakis]

To know which option to show as selected, look at the current destination and look at its hierarchy to find if that top level destination is in there. https://github.com/HedvigInsurance/android/blob/develop/app%2Fapp%2Fsrc%2Fmain%2Fkotlin%2Fcom%2Fhedvig%2Fandroid%2Fapp%2Fui%2FNavUtils.kt#L33-L37
Where createRoutePattern is the route of that top level destination which you navigate to when you press the bottom bar entry

[Stylianos Gakis]

We do this here https://github.com/HedvigInsurance/android/blob/develop/app%2Fapp%2Fsrc%2Fmain%2Fkotlin%2Fcom%2Fhedvig%2Fandroid%2Fapp%2Fui%2FHedvigNavRail.kt#L46-L53

[Pablo]

please, can you share with me the link to see the code of nowinandroid where they do this?

[Stylianos Gakis]

https://github.com/android/nowinandroid

[Pablo]

oh, yes, I know the project, but it's a mastodontic project, I mean if you can share with me the link to the class with that implementation you told me

[Stylianos Gakis]

NiaAppState should be the equivalent class like we do HedvigAppState

[Pablo]

I'm checking exactly that class, and it is inside a viewmodel

[Stylianos Gakis]

Got a link for where that happens?

[Pablo]

oh no, the viewmodel haves another uistate class

[Pablo]

MainActivityUiState

[Pablo]

this project it's extremely complex for my current level

[Stylianos Gakis]

I understand, but that class covers what you're going for here if I understood you correctly.
I also linked you exactly how we do it in our project, with links to all places.
You should try to follow either of those two and piece the things together. Otherwise the next step is I write your code for you 😅

[Pablo]

they are using a @Composable called

@Composable
fun rememberNiaAppState

[Pablo]

they are storing that composable as a state variable with the nav host and a lot of logic

[Pablo]

that's far more advanced than my current level

[Pablo]

appState: NiaAppState = rememberNiaAppState

[Pablo]

😨

[Stylianos Gakis]

Well, it's up to you if you want to copy that behavior and do the same, or if you want to simplify what you do since you don't feel comfortable with doing this. Which also means that you simply have to not have that feature in your app.
Calling a rememberFoo function isn't something special. You do it all the time at places like rememberCoroutineScope(), or rememberScrollState(). And I don't think those are advanced use cases.

[Pablo]

probably I'll understand this way of storing the state in the future

[Pablo]

for now it's too soon

[Pablo]

it's something wrong if I store the state of the single activity of my app in a viewmodel that contains the current navigation route?

[Pablo]

I think i'll open a new thread with this question

[Stylianos Gakis]

Your ViewModel will survive configuration changes, but your app state probably won't, so you will be leaking those old instances into your ViewModel.
So I don't think you want to do that at all, especially if you want to have your NavController inside that class too