Is there a "better" way to make sure that all of my screens (looks like my app will likely have over 50+ screens) all handle the case where a user is signed in or out? example: I only have 4 screens so far (signin, home, account, settings), but I've caught myself doing this same exact pattern 3 times now. Replace

Screen1

with

Screen2

and

Screen3

to get an idea for my duplicated code

@Composable
fun Screen1Screen(navController: NavController, viewModel: Screen1ViewModel = hiltViewModel()) {
    if (viewModel.userManagerService.loggedIn) {
        ActualScreen1()
    } else {
        navController.navigate(Screen.SignInScreen.route)
    }
}

Making sure that most screens follow the above pattern seems super error prone.

1. avoid calling

navigate

in composables. Navigate is not idempotent. In general be suspicious of any verbs invoked on any objects that outlive the current recomposition unless those methods are specifically designed to be composition-safe. (e.g. they only mutate snapshot state.) Use the

*Effect

APIs to create actors in the composition that can take action if present after composition is successful. 2. You can declare your own extensions on

NavGraphBuilder

that wrap the content of a destination in some navigation preamble if you like, or simply create something like a

SignedInContent

composable that accepts a

content: @Composable () -> Unit

avoid calling 

navigate

 in composables

😭. Jeez I suck at this navigation thing. lol. If only it wasn't mission critical to my every app.

yeah, so once you have a

SignedInContent

you can do something like declare a

fun NavGraphBuilder.signedInComposable(..., content: ...) {
  composable(...) {
    SignedInContent(..., content)
  }
}

which then means when someone goes to add a screen they'll wonder why they're typing

composable(...

instead of

signedInComposable

like all of the other destinations in the block

Hm. Kinda confused me on this

if (!signedIn) {
  Column {
    Text("You are logged out")
    Button(onClick = { navigator.navigate("signin") }) {
      Text("Sign in")
    }
  }
}

Breaking that apart 1.

signedIn

is a mutableStateOf() right? 2. Shouldn't the onClick mutate

signedIn

to false?

1. it's a stand-in for your condition, whatever it may be calculated from. 2. no, that state isn't owned here and that button has no right/access to mutate it.

Oh boy. A lot of this is admittedly going over my head. Going to take some time to read through this again.

to put it another way, you shouldn't "do stuff" during composition, but you can declare the presence of a composable that will "do stuff" for you via an effect once the composition is successful.

Yeah. So since I've been writing a complete design system the past few months. I've gotten to know compose well, and I basically only think about drawing things in composables. I never "do" anything, but now that I have entered the world of trying to tie these things together... my brain is fried apparently.

the key there is that

onClick

doesn't happen during composition

Okay. I thought my

signedIn

variable which is a mutableStateOf() also falls into the category of "doesn't happen during recomposition", because I figured it wouldn't be called multiple times.

You can think of a

LaunchedEffect

as a kind of actor that can be present in the composition

When you said

the key there is that 

onClick

 doesn't happen during composition

I think I already "knew" that. Basically in my head. I don't want to do anything really in a composable, because I just like to pretend that it can be called 100000 times without me even realizing. I like to operate under that assumption. SOOO I thought if I had a

signedIn

mutableStateOf() then I thought even if my composable is called 10000000 times, then it would only actually execute once because

signedIn

never actually changes.

ah

Interesting. So if the composable recomposes 1000 times... then technically navigate would have been called 1000 times?

and skip/restart is an optimization; there are plenty of cases where it won't skip.

Gotcha. Okay. So that was something I wasn't understanding. Cool. So I shouldn't "bank" on optimization to prevent my method being called. Okay. This is starting to make sense. I see where my understanding was failing me.

I'd have to double check with Jeremy and Ian but there's probably a clever way of writing a harness around the

NavHost

composable call to handle login states without a trampoline, but we'd have to work through all of the potentially complicated cases.

Yeah, it's so weird, because I think of the fact that a

userIsLoggedIn

as state, and was originally thinking that this means that I could probably just handle this on the activity level. i.e. Observe if userIsLoggedIn and then navigate based on that.

you could do that too

Yeah. I'm trying to go "by the book" with whatever Ian suggests. He seemed to suggest that the navigation should be done on a per screen basis. https://kotlinlang.slack.com/archives/CJLTWPH7S/p1626787985077800?thread_ts=1626726997.043700&cid=CJLTWPH7S

yep, Ian's spent more time with the UX teams around navigation more recently than I have 🙂

I'm lazily working on "yet another" navigation library, my main inspiration is that I want to make it declarative in the sense that you only specify your nav graph and then you never have to call 'push/pop/popTo' or whatever imperative commands. I want to make it so that backstack modification command (push/pop/popTo) will be automatically derived from the navgraph structure. What you do instead is you only say something like "navigateTo(someGraphNode)" and its place in the node hierarchy determines whether it'll be push or pop or reset or whatever.

@dimsuz in such a system how do you represent navigating to a related item on an item detail page?

Backstack is being built based on fixed rules. There are two kind of nodes: Flows and Screens. Flows contain Screens (leaf nodes). Jump between two screen nodes which have the same parent is a Push unless this node is already in the recorded backstack, then it's a Pop. So in your example it would be either Push or a Pop depending on the situation. That's one of the rules, there are a few more. Node transitions are based on Hoare's hierarchical state machines, but backstack building rules are something I've invented on top of that. I'm planning to apply this for large-ish apps, to see how it'll play out. So far it does for some small experiments, I'll have to do a lot more.

do report back, sounds interesting 🙂

I’m questioning my authentication flow based on your guy’s conversation. In our app, you have to be authenticated to view any content.

@Composable
fun NavGraph() {
    val navController = rememberNavController()

    val authenticationState =
        viewModel<SignInViewModel>().authenticationState.collectAsState(initial = Unknown).value
    when (authenticationState) {
        is Authenticated -> {
            NavHost(navController = navController, startDestination = NavRoots.ProjectRoot.route) {
                projectNavigation(navController)
            }
        }
        is Unauthenticated -> {
            NavHost(navController = navController, startDestination = NavRoots.AuthRoot.route) {
                authenticationNavigation(navController)
            }
        }
        is Unknown -> Text(text = "Loading")
        else -> Text(text = "else $authenticationState")
    }
}

fun NavGraphBuilder.projectNavigation(navController: NavHostController) {
    navigation(
        startDestination = ProjectRoutes.ProjectList.route,
        route = NavRoots.ProjectRoot.route
    ) {

        composable(ProjectRoutes.ProjectList.route) {
            ProjectsScreen(navController)
        }
}

When I switch the

navHost

via the result from the viewmodel, it’ll call

navigate

under the hood, correct? So this would violate the first point that Adam made in his first message right?

I'd need to read some navigation-compose code to be sure but I think using the same navController there could go sideways. The idea I've been working with is that the unauthenticated path has its own navController instance, and that unauthenticated branch is emitted per-destination on the authenticated path

ahh yeah, it seems to be working fine for us now with the same navController. In terms of what you said in #1, would the code I put above run into any issues with recomposition? Should I put this in an effect?

I think that looks fine? I know @Ian Lake has chimed in on this sort of thing a lot in the past, and basically has said that you should try to shape it so that you check the auth in each screen and handle it from their. In my mind, that's a lot of duplicate code and it leaves room for error if you business requires "In our app, you have to be authenticated to view any content." But.... to Ians point. If your product team ever comes back and say "Hey. pretty please. can you make this one screen handle an un-auth user AND an auth user" then you're sort of screwed and you have to do all this checking anyway. A good example he gave is twitter. You typically are hit with a login screen if you go to twitter.com, but if you get a link to a specific URL, twitter does allow you to view the tweet itself.

my preference for the implementation details of, "check the auth in each screen and handle it from there" is to selectively emit either the logged in content or the login flow rather than doing trampoline nav, but essentially yes. You can wrap it up into something like

loggedInComposable

in your

NavHost

block and it's really no more cumbersome

We have built an abstraction on top of NavHost/NavController which simply uses them as a "driver" to push/pop screens. And instances of this abstraction (NavFlow) contain logic which decides which screens to push, which dependencies to supply to those screens (auth or no-auth) etc. These flows are composable, i.e. provide means to start another flow when one finishes etc. So NavController is basically an implementation detail, this "driver" code knows nothing about authentication.