Is there any way to reset

targetContentZIndex

after a

ContentTransform

animation is done in

AnimatedContent

?

Curious what's your use case for needing to reset it?

I'm implementing a stack navigator with transitions, I need to make sure when popping, the previous screen in the stack doesn't overlay the old current screen

Having the

zIndex

based on the size of the stack would be a good choice for your use case. How and when would you want to reset the zIndex if we had a way to reset it? I'm assuming you are trying to reset the zIndex for the outgoing screen?

My thinking was to expose an initialContentZIndex to go alongside target

What would you reset it to?

You can see the current behavior of it here, so you can visualize the zindex

That sounds nice in the ideal scenario. What if the animation gets interrupted and there are more than one outgoing screens?

Hmmmmm, that’s a good point

(The question above was one of the things that we factored into this design.) It's entirely possible there are better solutions than what's provided. 🙂 I'm open to new ideas

Is there any kind of perf drawback with zindex?

Do you mean perf drawback in the fully obstructed cases where there is a rich screen underneath?

No, because there would be no screen underneath technically, until a transition occurs

I don't think the specific zIndex value matters much to performance. The zIndex eventually comes down to a sorting: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:compose/[…]ommonMain/kotlin/androidx/compose/ui/node/LayoutNode.kt;l=394

Good to know!

Pretty cool demo btw! 😍

Thank you, my manager gave me the blessing to rewrite our react native app, we’re kinda sick and tired of the performance overhead and tooling effort associated with it

Inconsistent design as well?

Yup, plus, the codebase feels kinda thrown together in places, poor patterns in use, poor state management

Sounds like you have a fun project on your hand. 😉

And don’t get me started on React Native’s bridge concept 😆

Glad to hear that. Let me know if you have any other questions/suggestions on animation. As I was just thinking about it, there's another interruption scenario during the screen transition, which is going back before the push onto the stack is finished, then all of a sudden the incoming screen becomes outgoing, and vice versa. We definitely don't want the zIndex to be swapped in that case - zIndex jump almost never looks good

Yeah, as of now though, I haven’t seen any kind of major zindex jumping with using the stack, but any sanity check would be a huge help 😛

This design is forcing

zIndex

to be considered more holistically.

That should have a lesser zindex still, since the stack is smaller at time of eval though, right?

if you use the stack size as the zIndex, it should be the same.

I’m not keeping it currently, but that’s also why theres the +1 and -1 offsets on the zIndex added to the stack size

In that case I would expect the current size of the stack to be sufficient, maybe that's what

history.size + 1f

is?

Yeah, that is to compensate for the loss of the current item

Mostly in terms of influencing design through the shape of lower level animation APIs. Why

Is there any reason why the internal progress is documented to return 1F when currently 0, but not actually animated? It’s not all that clear to me, seems counterintuitive

The

SwipeProgress

seems to be experimental, so definitely not set in stone. I'd recommend putting your feedback in a bug. The documentation says when it's not animating, the from/to would be the same, so the progress fraction won't matter that much I assume?