Hey friends, I wrote a post on compose navigation. This post details some of the common mistakes you...

# compose

[Tim Malseed]

Hey friends, I wrote a post on compose navigation. This post details some of the common mistakes you can make when trying to implement jetpack navigation with compose, and how to avoid them

https://programminghard.dev/compose-navigation/

[Stylianos Gakis]

Hey nice article!
One thing I was wondering about, with the final approach we fix the problem of hitting back and going back to the login screen which is super bad.
But since we’re navigating from the “home” destination to the “login” in the NotLoggedIn case, we can then press the back button on the “login” screen right? What will this do? As I see it it will pop the back stack, then go to “home”, and home will quickly realize that we’re still not logged it and go to the “login” screen again, making the back gesture basically do a quick flicker of going back and forth or even if this is too quick to flicker it will at least do nothing.
Am I missing something here?

[Tim Malseed]

Hey, thanks for reading.

Great question - yes, you’re 100% correct. There’s a back-press navigation loop in this example, which I’ve overlooked! I will update the post.

The way I address this problem, is by implementing a BackHandler on the login screen, like so:

@Composable
fun LoginScreen (onExitApp: () -> Unit) {
    BackHandler(enabled = true) {
        onExitApp()
    }
}

Where onExitApp() propagates the event up the call hierarchy, back to the host Activity, which then calls finish()

[Stylianos Gakis]

This is an option for sure, but I’m pretty sure we don’t want to actually finish the activity when pressing back.
In fact ever since Android 12+ pressing back means that the app goes in the background without finishing the activity, meaning that when open the app again you’re in a hot state, skipping showing stuff like the Splash screen and so on.
Read more here specifically the quote “Root launcher activities are no longer finished on Back press”.
I think it’d be a shame to lose this nice feature if we finish the activity ourselves.

Do the official docs provide some guidance regarding this exact scenario that I’ve missed maybe? Sorry for the ping @Ian Lake but I’d really appreciate if you share your thoughts or post an appropriate docs link regarding this here 🙌

[Tim Malseed]

Another really interesting point, not one I’d given much consideration to.

Just having a look at the docs. When onBackPressed is called:
https://developer.android.com/reference/android/app/Activity#onBackPressed()

• On platform versions prior to Build.VERSION_CODES.S, it finishes the current activity, but you can override this to do whatever you want.

• Starting with platform version Build.VERSION_CODES.S, for activities that are the root activity of the task and also declare an IntentFilter with Intent#ACTION_MAIN and Intent#CATEGORY_LAUNCHER in the manifest, the current activity and its task will be moved to the back of the activity stack instead of being finished. Other activities will simply be finished.

So, we could follow the same pattern, and call moveTaskToBack(), instead of `finish()`:
https://developer.android.com/reference/android/app/Activity#moveTaskToBack(boolean)

[Stylianos Gakis]

Hmm yeah one could do that, but then maybe we’d be breaking how things should actually function for APIs 11 and lower?
Or in the case where we’re not actually on our Launcher activity, where even in 12+ going back does in fact finish the activity?
Not sure tbh how I’d solve this perfectly 😅

[Tim Malseed]

If you wanted to exactly match the behaviour, you could just follow the docs as above, and finish() below Android S, and moveTaskToBack() above.

If you’re not on the launcher activity, I guess you can pass the nonRoot = true flag into moveTaskToBack(nonRoot: ..)?

[Tim Malseed]

nonRoot boolean: If false then this only works if the activity is the root of a task; if true it will work for any activity in a task.

[Stylianos Gakis]

Yeah just read that too. Does that then mean that it will simply not do anything, or that it will finish instead of moving the task to the background?

[Tim Malseed]

It will ‘work for any activity’ - work presumably meaning ‘will move the task to the back’,

[Tim Malseed]

Not sure though - I have not tested this!

[Stylianos Gakis]

Plus this then puts the burden (and the room to make a mistake) on the developer. And if you refactor stuff, move activities and such it may break without you noticing if you move that code from a Lanucher to a non Launcher activity. I’d love to be able to avoid having to this myself. But yeah, it seems like provided some testing there’s a way to do all this manually as well.

[Tim Malseed]

Yeah, I’m not sure what alternative you have really. You can’t exit the app via the navController, and going back to the start destination is not valid here potentially problematic.

You could store some state on a ViewModel to indicate that the user has failed to log in, and then render some different content on the ‘home’ screen to reflect this.

[Tim Malseed]

So, going back to the example in the blog post, you might store a flag in the savedStateHandle of the AppViewModel called, say, loginSuccessful . Initially it’s null (neither success nor failure). Upon navigating back from the login screen, you set loginSuccessful = false.

Then, this becomes an additional ViewState , say LoginFailed. If this is your ViewState, then you might render some other content to the user - like a login button and an explanation that the user needs to log in

[Tim Malseed]

This way, the user is on the start destination, and if they again press back, they exit the app - relying on the system to decide whether to finish or moveTaskToBack

[Stylianos Gakis]

Yeah just because I’d prefer not to handle it myself doesn’t mean I know a way to do so 😅
That’s why I pinged Ian in case he had a better idea.
But other than that maybe doing this and adjusting depending on the Android version you’re in might make the most sense right now. Or what you suggested right above^^
I haven’t found myself in such a situation so I don’t have any more ideas atm.

[Tim Malseed]

Storing a loginSuccessful flag is something Ian alludes to in the ‘navigating navigation’ video actually. I reckon doing this, and rendering some content to the user explaining that they need to login - and then relying on the system to handle exiting the app - this seems like the right way to do it.

[Tim Malseed]

Thanks for mentioning this @Stylianos Gakis! I appreciate the discussion. I'll update the post with some new recommendations!

[Stylianos Gakis]

Thanks for the discussion! Looking forward to reading the updated article when you find the time to do so 🤗