Before `Nav3` on payment deeplink I used to just f...

# compose

[ursus]

Before Nav3 on payment deeplink I used to just find Fragment reference in the fragment manager, cast it and call a function on it a "payment successful" callback

How would this translate to Nav3? Is this no longer a navigation library concern and should it be some SharedFlow I manage myself, i.e. unrelated to navigation?

Or, can I get a hold of the nav entry reference, or ideally its viewmodel (scoped to the entry)?

[piyush]

Not sure if I understand your problem completely but if its just about navigation to a screen from fragment, you own the backstack you can push anything in to it. Rest would be handled by your NavDisplay to trigger the appropriate entry. How you access you stack in your fragment is your choice, You can inject a Navigator which maintain your back stack or you can use sharedflow to observe changes and do that way.

[Konstantin Tskhovrebov]

https://github.com/terrakok/mobicon/blob/main/sharedUI%2Fsrc%2FcommonMain%2Fkotlin%2Fcom%2Fgithub%2Fterrakok%2Fmobicon%2FDeeplinkService.kt

You could take a look here

[ursus]

My question is not necessarily about navigating to a new screen, but passing a event to the existing payment screen already on backstack (payment is on the web and then redirect to the app, so on android that comes as Intent)

and before in Fragment world id just get the reference, but now in Nav3 nav entries don’t have instances (?), and backstack is just a list of keys

so how should I let the existing naventry know?

[piyush]

Keys are mapped to entries, so you don't need entry instances. In nav3 nav keys are way you handle your navigation and stack. In your case you have the Intent so you need to map that intent to a nav key and then use that nav keys go to payment successful screen.

[ursus]

no payment success screen, has to be same screen, my requirements

[Ian Lake]

Reaching down into your fragment was always the wrong way to do things anyways - you should not be trying to push events down the hierarchy at all (that's backwards from the usual state down and events up flow)

[Ian Lake]

Maybe what you actually want is for your screen to listen for new incoming intents itself, which is something already possible with LocalActivity.current as OnNewIntentProvider as mentioned https://kotlinlang.slack.com/archives/CJLTWPH7S/p1708009228234749?thread_ts=1707831281.198569&cid=CJLTWPH7S

[ursus]

Just to clarify, are you suggesting creating an api consumed by nav entry, like activity result (rememberLauncherForActivityResult) permission results etc, which then gets piped into viewmodel via a function, like clicks etc do?

Or a completely me-owned sharedflow/stateflow injected into viewmodel ctor via DI?