:bulb: Missing screen callbacks in AndroidX Naviga...

# feed

[Hristijan]

💡 Missing screen callbacks in AndroidX Navigation for KMP/CMP? 💡

I wrote a guide on implementing type-safe navigation callback results.
https://funkymuse.dev/posts/kmp-type-safe-nav-callback/

[Stylianos Gakis]

I've seen a ton of people discuss this or implement their own thing for this.
But in our app I've never had the need for such a mechanism, and if there's any cross-screen communication that typically only happens going forward, so navigating with arguments, or changing things on your data layer, and then each screen observes that instead.
What typical use cases do you have for such a feature, could you give me some examples?

[Hristijan]

Confirmation dialog

List chooser

Etc...

This is a standalone generic screen globally accessable as a destination where I send the UI details and create the screen from params, once a user completes the flow I get a callback, no need to create a separate confirmation screen for each flow or use showDialog flag

[Stylianos Gakis]

Interesting! So you prefer having that as a global shared destination driven by your navigation as well.
I typically just put the dialog in the screen itself tbh. It's not more code, since the contents themselves are still, just like in your solution, shared code that is written once in one place. All the screen itself has to do is call the dialog composable, and hookup the onClicks.
That way you can also just directly change the state itself from inside the dialog, even if that involves more than just returning 1 result back when you're done with the dialog.
Have you tried doing it this way and you simply did not prefer it?

[Hristijan]

Yes, I even had some helpers that kinda hid away showing/dismissing of the dialogs and it felt like that screen got polluted with so much logic once we started having more than 2-3 dialogs (yes even with the abstraction), it was called rememberDialogMemberState that had toggle/show/hide capabilities and inside it hosted the Content of the dialog UI, so for each dialog we had to have a new remember and if we want to persist the state we had to be using rememberSaveable, then it also meant some logic had been going in the UI that shouldn't be there.

This new way we also know that the NavBackstack will restore everything alongside up to the dialog and what on the dialog is show of course with the correct arguments and we don't have to use rememberSaveable for everything that lives in the dialogs.

The only thing that can't b done in a good UX is nested BottomSheet destinations, because you can only have one visible at the moment and if you want more than 1, once you show the second the first is hidden and once you go back it pops up again in a weird fashion, it's not like this backdrop thing on iOS that they do have and we had to do this manually tho.