In nav3, I’m working on scene transitions which se...

# compose-android

[Mark]

In nav3, I’m working on scene transitions which seems largely dependent on contentKey which is derived from the nav key. In my case, the backstack is presented as a sliding horizontal list of panes (showing 1 or many panes at once, according to available space). Navigate forward and the entire scene pans horizontally - the new pane sliding in from the right, the oldest pane sliding of to the left. Similarly, in reverse for pop. However, suppose there are 3 entries: key1, key2, key1, with the last two keys visible in the scene. Because the outgoing scene is the same key as the incoming scene, we end up with an ugly transition where the right pane slides from right side to left side (instead of sliding off to the right). The only workaround I found is to make the key a class instead of data class , but then this messes up the viewmodel persistence (because it’s keyed on the nav key).

[Jonas]

Not sure I understand the use case correctly. But, could you add an argument to the data class of the key1 entry - a instance id so to say, in which case the two instances would differentiate? Or is that exactly what you mean with the vm persistence, that they need to have the same key?

[Mark]

That was the solution offered by Gemini, but I don't like it all, regardless of the probable viewmodel implications. I simply want to transition nav entries, not nav keys.

[Jonas]

Do not understand what you mean. Do the two instances of nav entries differentiate but only the serialized content key is the same? You are able to specify any type as content key, you just have to make sure its serializable.

[Jonas]

Does this touch your problem or am I misunderstanding?

[Mark]

When two entries on the backstack have the same key, then they will also have the same contentKey. In other words, neither key nor contentKey will help to tell them apart. Maybe something can be done with the metadata, but anyway only the contentKey is available when determining whether an entry should be animated (via SharedTransitionLayout) or simply enter/exit the scene. I really don’t think changing the key to include some identifier is a good solution. Feels like a hack. Why would we change that just for correct animations? Perhaps it’s the only way, in which case there is no choice.

Currently, `SharedTransitionLayout`will always animate (from old position to new position) when the contentKey is shared by the old layout and the new layout. Maybe nav3 should have a step beforehand where it filters out entries being added or removed from the scene. Such entries should only be transitioned according to the transition specs.

[Bianca Tudora]

Hello, we’re hitting a similar nav3 duplicate-key issue in our implementation (with the class-instead-of-data-class workaround which messes up the viewmodel persistence). Did you ever find a solution for it?