The Compose's NavigationController doesn't allow for "free-form" navigation. I get that having a laid out static navigation graph is great, but in a considerably large project I don't think its tenable. I was able to create a "hacky" solution. However I'm curious why "free-form" navigation isn't directly supported? Answer: A static graph must to be created at start up to handle resuming after process death Hopefully something better will come along soon!

What happens when your app process is terminated in the background and the user returns to the app?

I haven't tested that out yet, but what do you expect?

The reason for the static/parameterized navigation graph is so that the system can always restart your app from a deep destination without re-running all of the navigation code that got you there. I would expect that with the code above, the navigation system would try to navigate to a route that doesn't exist, since the code that navigated to it never ran.

How does compose's navigation normally handle this?

Normally since the routing is declared up front, the navigation can restore from the saved instance state and know what the last state of the back stack was

I see which is the purpose of having a static navigation graph

those apps are deeply broken. All it takes is launching a web browser or the camera on most android devices and all other apps get killed in the background.

Do you think Google will ever provide such a solution?

Maybe! We're certainly open to going where the developer interest is if we can make it work. I see @Ian Lake lurking in the emoji reactions above so if he feels strongly against it he can correct me here 😛

What makes you think the current approach isn't tenable in a large project? Note that you don't have to build your graph in one file - you can call methods, use a for loop to go through subgraph providers, etc. You have all the power of Kotlin code

to a first approximation though, the current setup of navigation with arguments is already this same kind of functional mapping

Maintaining a routing table for every view in large app is a big ask

For all the reasons Adam mentioned above, defining the graph ahead of time is a conscious decision by the Navigation Component

Obviously theres no other solution, so thats what we'll do. Its just creates a more rickety app in the end.

I think if you approach it in terms of building small, modular features with their own subgraphs, each individual graph becomes a lot more manageable

many of the patterns that are applicable to something like ktor or spring boot also can be used here; declaring extension functions on the navigation scope, etc.

Yes it seems like a web server approach to a UI application

I'm fascinated by the fear that this forms something "rickety" and would like to know more 🙂

Well you seem quite set in your beliefs so I doubt I will convince but here goes For starters comparing

navigator.navigate { SomeOtherComposable(params) }

to

navigator.navigate("some/route?id=3")

. The first one is clearer and you get the benefits of the compiler checking the view and route works. The second one while it taps into a central routing system, it's more arbitrary than the first. 1. Having a centralized routing table works for server side development because routing between "views" already has a large level of indirection. Also with a web server theres not often much connection between individual routes. UI Applications routing between views is a direct operation and its often time theres a strong connection between views. 2. Having an explicit "entry" points for a "view" is a must for a large project. This is an area Android has traditionally suffered. The navigation component team has improved this with named generated routes. This has been super helpful. 3. When managing an App with 100 views and roughly 2 entries per view, thats 200 different routes. A views individual route should almost always be stored along side the view itself. This has been done by having static constructors with Fragments or just named constructors for VCs on the iOS side. This isn't always the case, but it is most of the time. So the current "best practice" with Compose's navigation system is: 1. A individual Compose view includes its possible routes in its own file 2. A module or subset of Compose views collects all the possible routes into a list. You probably include your route manipulation logic here if needed. 3. The app collects all possible modules routes into one master list. 4. You then route via a string path vs 1. A individual Compose view includes its possible routes in its own file 2. You route by directly using the exposed Compose view routes Other aspects this improves 1. When figuring out how to route to a view, there is only one source of truth 2. Adding and removing view does not involve editing a high traffic file 3. Removing a view causes a compiler error I get the process death requirement, I just wish there was a better solution. Thanks 🙂

Thanks! I don't have a terribly strong opinion here beyond meeting the process death requirement, so I'd consider anything on the table; it's still early days here

Yes but there needs to be some sort of abstracted "ViewState" that handles taking in inputs and surfacing outputs

Yeah, something like that. The trouble with arbitrary lambdas is that they're so useful, half the stuff you end up capturing just works and it starts building expectations

Ya especially when Android's process death is such a pervasive issue that direct injection of arguments into "ViewState"s shouldn't happen

But we've been burned endlessly by saving a class type and instantiating by reflection. After a decade of it on android I think we're over it; explicit serialization/factories are generally the better bet, but then it's more boilerplate to write

My own implementation wasn't meant to be taken as a good one btw

It's a real one though; it expresses what you reached for and that's useful data

Ya but Androids application framework is set up to somewhat require a DI framework

Mostly to solve some particular own-goals we performed over the years

Ya

Thanks 😄

I work a lot both iOS and Android

Some of the stuff here has me hopeful for DI-like use cases: https://youtrack.jetbrains.com/issue/KT-10468

I know you probably don't hear this to often, but I prefer Android as a dev platform

Hah, yeah, and having worked in the guts of all three over the years, there's a ton of good reason for them to be complaints

haha true true

Anyway, truly, I appreciate the thoughtful feedback here. I know sometimes it looks like we're set in our ways or holding the party line, but the ground truth feedback like this is the best kind we can get

Thanks!

Yeah, it is always great to see different perspectives

@Adam Powell "those apps are deeply broken. All it takes is launching a web browser or the camera on most android devices and all other apps get killed in the background." I still wish Android made this easier to test. There should definitely be a big huge button in Android Studio that allows you to trigger process death. There's is a workaround in AS by pressing the stop button in the logcat pane, but even the functionality of that changed in some beta back in the day. I'd wager 99% of android devs don't even know of a reliable/easy way to trigger process death.

Hahaha totally, I remember opening up a ton of poorly optimized Wikia sites to force it

@Colton Idle @birdsofparadise Android has "Don't keep activities" option at Developer options menu. It does exactly what you need :) Also, ADB has an equivalent command to test that particular behavior. Happy New Year 🥳

@Sergey Y. Thanks thanks. I do wish it was as easy as a single click, but its a billion times easier than loading up bad websites lol.

Don't keep activities can be useful, but it's also not a full process restart. If anything is relying on live references in the process you won't catch it

@Sergey Y. yea. my point wasn't that it doesn't exist, it's that it's not as easy as it should be. IMO if the android team cared about process death restoration then they would give you an easy way to trigger it. 5 years of working on Android apps and none of the teams have cared about process death. (i do, it's just that my teams haven't). Maybe just bad luck of teams on my part.

would give you an easy way to trigger it

Come on, you are developer, an engineer, 5 min to read official documentation and you are good to go 🙂 Sometimes I regret that the official development language is not C++, there is no place for tenderness. Only brutal skills and reading manuals. Ah, modern developers... 😞

If I had a nickel for every time I heard, "if the android team cared about X..." 😂

@Adam Powell I'm unsure it's unfair of me to say. But process death has just become a thing that no one cares about seemingly. Idk maybe just my point of view tho. /Shruggie

Most of the reason for that is because we've spent years building tools and libraries that facilitate ignoring it. From activity stacks being managed by the system and stock views implementing savedInstanceState, to fragment back stacks handling it, to Room and encouraging more robust disk persistence rather than relying only on savedInstanceState, to arch components ViewModel and SavedStateHandle and now the savedInstanceState APIs for Compose. The reason Activity recreation/state restoration works the way it does is in no small part to encourage supporting the full process death case correctly and to deliberately make an app look more broken more often when it doesn't. 🙂

Yeah. I think I read that from Dianne way back on stack overflow. A hill I'd still die on is that process death should be a button in AS. I think I submitted a bug on issue tracker once they came out with the new process death apis. 😁 I only mention it because I care about process death restoration but I'm always on teams that don't care.

adb shell kill -9

has worked for longer than android studio has existed 😛

Yeah. That's what I mean. There's different things available to us like that. Swipe the app away, force stop in settings > app, kill via adb, stop button in AS. It would just be nice to have a little pane in AS that helps test these situations deterministically. That's all I'm advocating for. 😁