I guess somewhat related to <this> discussion, got...

# compose

[Stylianos Gakis]

I guess somewhat related to this discussion, got a question regarding compose navigation, process death recreation and dynamic backend driven routes.

[Stylianos Gakis]

We got a use case where we don’t even have an initial graph which we can inform the navController, but we’re dynamically calling NavController.createGraph() with the information that comes from the backend for the entire flow.
From my understanding there’s not much we can do here in terms of process death recreation, so I’m looking for a way to potentially opt out from it, since we hit this error, and do it ourselves instead, by storing the previous information in persistent storage, and doing something with it, not sure tbh still thinking about it.

Does this feel like it has a solution, or does anyone have any idea about how to approach this?

[Colton Idle]

we don’t even have an initial graph which we can inform the navController

🤯

Just out of curisotiy. whats the use case/ business req that prevents you from having an initial graph? i think compose-nav is fairly dependent on having thaat initial graph so maybe thaat navigation library might not be the right tool here.

[Stylianos Gakis]

It’s a flow which is entirely driven from backend, to enable changing it up without making an app release, as long as it uses existing components which the app knows how to render. Entirely SDUI for that flow basically.

[Colton Idle]

interesting. i also work on a completely sdui app, but we define all of the routes in the nav graph anyway and the sdui also has server driven "actions" which can open a new screen

[Stylianos Gakis]

Yeah, but for us those actions take us to arbitrary screens, which are also defined by the backend 😅
I thing another thing I may need to explore is having all routes be the same endpoint afterall (so it’ll be a stack of all of the same url) but have them, render different things depending on incoming data instead of depending on the URL.
Still trying to fight this and figure it out 😄

[Colton Idle]

yeah. if its SDUI and each page is also "made up" on the fly. then it seems like you would just want a single destination. but something we decided early on in our project is that action are dynamic. screen content is dynamic. but routes are deterministic.

[Colton Idle]

that simplified a ton of things for us.

[Colton Idle]

and it basically gives us 99% of what we want anyway

[Stylianos Gakis]

Yeah so within the flow, do you then actually use compose navigation to .navigate() to the same destination again, building the backstack like that, or do you do the “inside the destination” parts as some other custom solution?

[Colton Idle]

So we use compose navigation, but we have deteministic destinations, so we have all destinations part of the graph already.

[Stylianos Gakis]

Ah right yeah forgot about that part. I’ll have to try smth else then 😄

[steelahhh]

Can I interest y'all in some Appyx goodness 👀

Sure, it goes against all of the Google guidelines, but the use case you're describing is pretty much a perfect fit for Appyx with its model driven navigation concept

[Stylianos Gakis]

Yeah it very well may be a better approach for this.
For now I simply made it work, in a very weird way though, by using normal .saveState() and .restoreState(bundle) myself, just after I’ve fetched the routes from the backend, populating the graph again, and then calling restoreState. It was an interesting thing to make work, and I don’t love it but in our special case where I don’t have the graph ready there for me at startup, while I do need the NavHostController state to be restored, and for it to be restored if the graph isn’t there yet then it crashes since it can’t find the routes that it’s trying to restore 😂
Tbh I might be missing something or doing smth wrong or whatever, but it is what it is.

Appyx or any more “free-form” nav library may be the next thing I try if things go bad 😄 How has your experience with it been? How about process death handling with it, which was the reason I had all these issues in this case.

[steelahhh]

Yeah, sounds like a reasonable solution for this 😅

My experience with Appyx has been fantastic so far - proper custom transitions support (should be even better in v2🤞) and state restoration just works, but you have to be mindful of the bundle limitations

But if you're heavily relying on Hilt/Anvil, you're gonna have to roll some custom stuff to make DI work more seamlessly, or go the manual-ish route

[Pablichjenkov]

Jetpack navigation is really limited, especially for dynamically changing Apps. Apps that change navigation based on server data.

[Stylianos Gakis]

Awesome to hear about your good Appyx experience!
Interesting you mention bundle limitations, since those limitations is exactly the reason that we can’t just load the old state into savedStatehandle, and re-populate the graph from that saved state. This state was over 0.5MB and is bound to become bigger later on. So now we store that representation that backend sends us to DataStore, then asynchronously reload it from there and then do the restoreState as mentioned above.
If it’d all fit in the bundle then we could get this instantly from there instead of asynchronously from DataStore.