Hello Android devs! I'm looking into writing a nav...

# android

[Isaac Udy]

Hello Android devs! I'm looking into writing a navigation library (expressing navigation routes as a Kotlin DSL), and I'm interested to hear what kind of funky situations you get your navigation stack into. Obviously there's "go to X" or "go back", but the more complicated examples that I'm interested in are about screens presenting nested screens, back-stack manipulations, and understanding the "types" of navigation. The examples I can think of off the top of my head are:
• A bottom tab bar Activity presenting several different fragments
• An activity presenting two fragments in a Master/Detail flow
• A "sign up" flow that tracks and displays progress through completing several child forms
• A dialog that pops over a screen and tracks some kind of navigation through a flow or tabs as above
• An Activity/Fragment that wants its parent Activity/Fragment to display a snackbar after it has completed (i.e. "XXX has been saved [view]")
• Navigation "types" of "forward from this screen" or "on top of this screen" or "replace this screen"
If you're not doing anything interesting with your navigation, I'm also interested in hearing whether or not you often pass messages back to a parent screen once the child has finished doing something (via onActivityResult, a message bus, or any other way).

Your thoughts and examples are much appreciated!

[stantronic]

Push notifications and deep links often present interesting challenges in constructing / simulating what the back stack should be once you’ve navigated somewhere from clicking on them.

[stantronic]

Also handling auth with navigation - making sure that once a user has logged out that none of the authenticated screens are accessible etc.

[Isaac Udy]

Thanks Steven! I've got some plans for backstack simulation (specifically for deep links), so it's good to hear you also think that's an important concern.

Auth is a great one as well - how would you imagine this is handled? Should the View be aware of the auth requirements for itself (and automatically close itself), or would you think that a deeper layer of the architecture should be able to control the navigation stack for this purpose (i.e. when requesting a "UserSession", if one doesn't exist, the data layer of the app would trigger a redirection to a login screen)

[stantronic]

yes, I would definitely opt for the second way - the View shouldn’t have to think about auth concerns. Also might be worth thinking of apps which are capable of having multiple accounts signed in, and some kind of account switching mechanism.

[stantronic]

I don’t know if you’ve spent any time in React Native world - they have a structure called a switch navigator which they recommend for authentication-related navigation routing - https://reactnavigation.org/docs/en/auth-flow.html

[Ray Ryan]

Forgive the auto horn tooting, but Square’s workflow library was driven by these same concerns. If nothing else it’s something you can plunder.

https://square.github.io/workflow/

I’m particularly pleased with our master / detail samples, e.g.:

https://github.com/square/workflow/blob/master/kotlin/samples/containers/poetry/src/main/java/com/squareup/sample/poetry/PoemWorkflow.kt

[Isaac Udy]

Thanks @Ray Ryan, I'll take a look at those 🙂