In `Nav3`, when I handle `onNewIntent` deeplink, l...

# compose

[ursus]

In Nav3, when I handle onNewIntent deeplink, like this

class MainActivity {
	private val pendingDeeplink = MutableStateFlow<Deeplink?>(null)

	override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)
        val deeplink = resolveIntent(intent)
        pendingDeeplink.value = deeplink
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
    	setContent {
    		val backStack = rememberNavBackStack2<SubscriberNavKey>(MainKey) <---
	        LaunchedEffect(pendingDeeplink) {
	            pendingDeeplink
	                .collect { deeplink ->
	                    applyDeeplink(backstack, deeplink) <----
	                    pendingDeeplink.value = null
	                }
	        }
    		NavDisplay bla bla 
    	}
    }
}

If the app was on MainKey, and then went to background -- basically the app is running already, i.e. its not killed -- and then I apply the deeplink which say pushes some screen -- I always see MainKey screen for a split second, no matter if the next screen has transition animation or not, it's always seen briefly

I'd assume it's due to the way I apply the deeplink, via LaunchedEffect which runs after composition.

Is there a way to not have the MainKey be seen and have the deeplink applied "sooner" somehow?

[Konstantin Tskhovrebov]

try DisposableEffect

[ursus]

how do I collect a flow without coroutine?

or are you saying to not use flow?

[Vilgot Fredenberg]

I guess I don't see why you're using a flow in the first place. Why not call applyDeeplink in ::onNewIntent?

[Konstantin Tskhovrebov]

☝️ extract the backStack outside

[ursus]

I'm just prototyping so I'm not set with this pattern

[ursus]

hmm I could .. but then I need to save it my self .. which I guess should be warranted now

[Konstantin Tskhovrebov]

or instead of the MutableStateFlow use a regular mutableState + DisposableEffect

[Konstantin Tskhovrebov]

and LaunchedEffect(pendingDeeplink) has no sense. MutableStateFlow is not changed

[ursus]

thats just in case instance were to change, same as collectAsState works

[ursus]

so you're suggesting something like this?

class MainActivity {
	private val backstack = StateListWhatever<NavKey>()

	override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)
        val deeplink = resolveIntent(intent)
        applyDeeplink(backstack, deeplink)
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
    	setContent {
    		
    		NavDisplay bla bla(backstack)
    	}
    }
}

[ursus]

+ saveState handling?

[Vilgot Fredenberg]

You could even declare the state via lateinit and defer assignment to composition. This would crash if composition never happened prior to onNewIntent, but I'm not sure that's possible through non-programmatic means.

[ursus]

I'm not sure what's that supposed to solve?

[Vilgot Fredenberg]

That would allow you to keep using rememberNavBackStack2.

[Vilgot Fredenberg]

Untitled.cpp

Untitled.cpp

[ursus]

I see so to keep it in the field

[ursus]

I think I like youre original suggestion better, to simply take it over myself

class MainActivity {
	private lateinit var backstack: NavBackStack<NavKey>()

	override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)
        val deeplink = resolveIntent(intent)
        applyDeeplink(backstack, deeplink)
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        if (savedInstanceState != null) {
        	backstack = savedInstanceState.getBackStack(KEY)
        } else {
        	backstack = NavBackStack<NavKey>(MainKey)
        }
    	setContent {
    		NavDisplay bla bla(backstack)
    	}
    }
}

[Vilgot Fredenberg]

The issue you may run into is that savedstate (android) is different from saveable (compose)

[ursus]

why?

I'm looking at what the remembernavbackstackdoes

rememberSerializable(
        serializer = NavBackStackSerializer(elementSerializer = NavKeySerializer())
    ) {
        NavBackStack(*elements)
    }

I'd imagine its just to use kotlinx.serialization, into string, pass that into the android savedstate as a blob

override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putString(KEY, Json.encodeblabla(backstack, NavBackStackSerializer())
    }

[Vilgot Fredenberg]

It also supports Android specific types as well (@Parcelable, IBinder, and SparseArray)

[Vilgot Fredenberg]

I personally use rememberSaveable for my backstack with entries being annotated with Parcelable. YMMV

[ursus]

I know but specifically this, doesnt it always use json? since this builtin stuff uses KSerializer?

[Vilgot Fredenberg]

rememberSerializable supports (the aforementioned) platform-specific types

[ursus]

> I personally use rememberSaveable for my backstack with entries being annotated with Parcelable.
btw why? doesn't that pull in android dependency when defining navkeys? or do you not mind?

If figured they went the @Serializable route out of the box for this exact reason

[Vilgot Fredenberg]

I only target Android so there's no dependency issue. As for why, rememberNavBackStack uses reflection or requires repeating all entry types via SavedStateConfiguration. Parcelable has no such issue

[ursus]

reflection huh? whats the @Serializable requirement on keys then for?

[ursus]

anyways the tldr; is you as well don't use the builtin rememberNavBackStac() , right?

[Vilgot Fredenberg]

You can take a look here: https://github.com/androidx/androidx/blob/8fcd416a452c54c72b1f344ac8c4d76fc4808b12[…]x/navigation3/runtime/serialization/NavKeySerializer.android.kt

[Vilgot Fredenberg]

> anyways the tldr; is you as well don't use the builtin rememberNavBackStac() , right?
I just use

val backStack = rememberSaveable { mutableStateListOf<Any>(Home) }

[ursus]

I see so it's not mandatory somehow .. means you can also skip the @Serializable on keys as well right

[Vilgot Fredenberg]

You own the backstack, it can be whatever you want.

@Parcelize
data object Home : Parcelable

[ursus]

yea, its just strange mixing reflection and @Serializable, totally unexpected

[ursus]

I wonder now .. that reflection is only applied at save/restore time, so very infrequently.. is it worth the new plugin? chances are you already have the kotlinx.serialization applied

[Ian Lake]

Why are you overriding onNewIntent at all when we already talked about how you can receive that signal inside composition where your back stack is already defined? You don't need any of this MutableStateFlow+collect stuff
https://kotlinlang.slack.com/archives/CJLTWPH7S/p1775346591629329?thread_ts=1775315820.880149&cid=CJLTWPH7S

[ursus]

Hmm, well the prior convo was about, or atleast I read it as having per nav entry callback

But now I think, and correct me if wrong, you mean to only have a single onNewIntent callback but declared from within setContent, i.e. where the backstack reference is in scope, so I can still use the rememberNavBackStack()

Am I right?

[Ian Lake]

The same pattern of getting the onNewIntent into the composable that needs to process it applies to both situations, yes

[ursus]

Okay now it clicked, thank you!

[ursus]

Okay so I tried it, api is nicer, however the original effect is still there, is there no way around it? Or it is what it is? (Even if I turn off the transition)

See video

Screen Recording 2026-04-14 at 19.48.36.mov

[ursus]

@Ian Lake For posterity, unfortunately the OnNewIntentProvider registered in composition is not process restore safe (on deeplink). As it's registered later, and can/will miss the onNewIntent (race)

class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()

        setContent {
            val activity = LocalActivity.current as ComponentActivity
            DisposableEffect(activity) {
                Log.d("Default", "registering onNewIntentProvider")
                val listener = Consumer<Intent> { value ->
                    Log.d("Default", "callback onNewIntent intent=${value.data}")
                }
                activity.addOnNewIntentListener(listener)
                onDispose {
                    activity.removeOnNewIntentListener(listener)
                }
            }
            AppRoot(appStateHelper)
        }
    }

    override fun onNewIntent(intent: Intent) {
        super.onNewIntent(intent)
        Log.d("Default", "onNewIntent")
    }
}

i.e. when I say go to pay something into custom tabs, which are a different process, so my app is then eligible to get killed, so I kill it, and then on redirect/deeplink back to the app's process is started again, however - the odd bit - obviously activity.onCreate is called but intent there is null - and it immediately calls onNewIntent with the proper not null intent.

And that is a race between activty.onNewIntent and the OnNewIntentProvider registration in composition, which is a race and most of the time it misses by a lot

13:25:23.699  D  onNewIntent
13:25:24.158  D  registering onNewIntentProvider

half a second

-- unless I'm doing it wrong

[Vilgot Fredenberg]

Registration being delayed (and not restored) makes sense to me. I can't speak for why the intent deliver pattern is like that, however.

[ursus]

Yea it does .. however I'd still expect the onCreate carry the intent and onNewIntent not get called here, but yea a race nonetheless