<@UHAJKUSTU> What would be the correct way to hand...

# decompose

[लातों वाला भूत]

@Arkadii Ivanov What would be the correct way to handle deeplink from native code with retained component.
I keep getting

java.lang.IllegalArgumentException: SavedStateProvider with the given key is already registered

This is possibly because of retainedComponent trying to recreate using the same key.
The trouble is Android allows sending deeplink intent from onNewIntent as well as onCreate.
Adding code in thread

[लातों वाला भूत]

App.android.kt

@OptIn(ExperimentalDecomposeApi::class)
fun AppCompatActivity.setUpMedialApp(
    modifier: Modifier = Modifier,
    deeplink: String? = null
) {
    val rootComponent = retainedComponent {
        RootComponentImpl(it, deeplink)
    }

    setContent {
        MedialApp(
            darkTheme = isSystemInDarkTheme(),
            dynamicColor = true,
            component = rootComponent,
            modifier = modifier
        )
    }

}

[लातों वाला भूत]

This is how I am calling it from Android native

override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        KoinConfig(this).initKoin()
        Firebase.initialize(this)
        checkForUpdates()
        content(intent)
        ExceptionHelper()
    }


    override fun onNewIntent(intent: Intent?) {
        super.onNewIntent(intent)
        content(intent)
    }

    private fun content(intent: Intent? = null) {
        setUpMedialApp(deeplink = getDeeplink(intent))
    }

[Arkadii Ivanov]

This is possibly because of retainedComponent trying to recreate using the same key.

This looks like the cause, setUpMedialApp is being called twice.

Usually (without retained components) there are two ways of handling deeplinks.

1. In onNewIntent, call setIntent(intent) and then call recreate() . And in onCreate you can call defaultComponentContext(discardSavedState = deepLink != null) , where deepLink is a deeplink parsed from the Activity intent.
2. In onNewIntent, call just call a root component's method and pass the deeplink there. The root component then just navigates to the required state.
The first option is preferable from my point of view. But some people actually prefer the second variant.

But since you are using retained components, currently there is no way of using the option #1 (there is no discardSavedState argument in retainedComponent function), only option #2 is possible. I think I could add discardSavedState to retainedComponent function. What do you think?

[लातों वाला भूत]

Ahhh..this is precisely what I wanted to ask. How to discard saved state in retained component. I believe Android deeplink handling mandates this functionality considering retainedComponent will be the goto way of porting VM's to decompose.

[लातों वाला भूत]

Regarding option 2. I have my concerns with exposing RootComponent methods to native code. I might be wrong though but that sounds like a hack.

[Arkadii Ivanov]

Cool. I will try to update retainedComponent API. Filed https://github.com/arkivanov/Decompose/issues/588

[लातों वाला भूत]

Thanks a lot. Kudos to you for being super active

[लातों वाला भूत]

@Vaibhav Jaiswal

[लातों वाला भूत]

@Arkadii Ivanov any timeline on this?
Resuming app from app icon while it's in the background also results in a crash.

I think this again because of retainedComponent being recreated.

[Arkadii Ivanov]

I think the app shouldn't crash when you start it from background, and the Root component shouldn't be recreated. It should just resume as usual.

[Arkadii Ivanov]

Why are you trying to recreate the component in this case?

[लातों वाला भूत]

It's the same as the code above. I think onNewIntent is getting called when resume app from app icon

[लातों वाला भूत]

What should I do in that case?

[Arkadii Ivanov]

Perhaps just ignore and do nothing?

[Arkadii Ivanov]

Otherwise the entire navigation state will be reset

[Arkadii Ivanov]

I think you can call setIntent(intent), and then if there is no deeplink - just return from onNewIntent and do nothing.

[Arkadii Ivanov]

Anyway, if you really need the fix, you can temporarily copy it from here: https://github.com/arkivanov/Decompose/pull/594

[लातों वाला भूत]

Thanks will take a look

[लातों वाला भूत]

Will update here on how that goes.

[Vaibhav Jaiswal]

@Arkadii Ivanov This is not working discardSavedState
It still crashes with the same error

[Arkadii Ivanov]

You might be using it incorrectly. This is supposed to be used only in onCreate.

[Arkadii Ivanov]

I will document this explicitly: https://github.com/arkivanov/Decompose/issues/new

[Vaibhav Jaiswal]

@Arkadii Ivanov I changed my onNewIntent() to this

override fun onNewIntent(intent: Intent?) {
        super.onNewIntent(intent)
        setIntent(intent)
        recreate()
    }

Now its not crashing, but navigation is reset
Checking if deeplink is there or not and doing nothing will handle the scenario when app is minimized and opened

[Arkadii Ivanov]

Yes. I think recreate is only needed if there is a new deeplink. If no deeplink, then just don't recreate.

[Arkadii Ivanov]

I will document this as well, thanks.

[लातों वाला भूत]

Thanks a lot @Arkadii Ivanov

[Vaibhav Jaiswal]

@Arkadii Ivanov There's a small issue when using this, when we change device theme (dark to light or vice versa) when using app, as onCreate is called again
RootComponent gets created again hence nav state is lost

Do you know of any workaround?

[Arkadii Ivanov]

I have updated the docs with samples some time ago. I think it should help. https://arkivanov.github.io/Decompose/navigation/stack/deeplinking/#handling-deep-links-since-v300-alpha01

[Vaibhav Jaiswal]

Thanks, will try it out

[Arkadii Ivanov]

Decompose 3.0.0-alpha05 is released with the changes in retainedComponent function.

[लातों वाला भूत]

Thanks a lot @Arkadii Ivanov. Will be adding this in our next release

[लातों वाला भूत]

@Arkadii Ivanov I was unable to solve the scroll vs drag pointer input problem. But I did notice an interesting caveat that webview page prevents swiping and hogs the scroll event to itself. Can something similar be achieved with scrollable components?

[Arkadii Ivanov]

I doubt that. If you really want fullscreen back swiping, I would recommend trying to place the overlay under the content, and don't use Surfaces for your screens.

Otherwise, I don't think there is an easy way to achieve this. Maybe also ask in #compose channel - like how we can place a touch interceptor on top of the content and only react to touch events that are not being processed by a widget underneath? Currently it seems that scrollable widgets don't consume the events, and the events continue their way through other widgets.