material-components-android: [Motion] Can't use both Container transition and Shared element

Description: I’m trying to implement transition #1, which is from the new material motion system.

If I use sharedElementEnterTransition = MaterialContainerTransform() then I get a really nice looking container transform, BUT my issue is that my container has an image and I’d like to share that image. There doesn’t seem to be clear guidance on how to do this, so I tried my best with just getting the container (outer viewgroup) and the contained imageView, and it doesn’t seem to work. I can verify that my shared element is working, because if I remove my container transition and just put the transition on the image view via TransitionInflater.from(context).inflateTransition(android.R.transition.move) then I get a nice animated shared element. My issue is that I want both.

Looking at the gif from the material team below, it does seem like they include a package deal of a container transition + a shared element imageview.

https://miro.medium.com/max/1400/1*0vL7z6wwb1X9tvR6_rdQLw.gif

Expected behavior: As far as I can understand, MaterialContainerTransform() should allow you to chain another shared element.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 26 (11 by maintainers)

Commits related to this issue

Removed drawing view id prop for simplicity The MaterialContainerTransform expects the id to be a resource?! The React Native ids aren't resources so android throws error when it can't find it. Could... — committed to grahammendick/navigation by grahammendick 3 years ago

Most upvoted comments

Re: the “bad” container transform, I think that’s a relatively common issue we’re seeing when the incoming screen/view doesn’t have a background, but it should be easily fixable.

Have spent ages trying to figure out why my container transform wasn’t scaling and this was the issue! Thanks for this.

daniel-stoneuk on May 1, 2020

Thanks @ColtonIdle! Let’s file separate issues for anything specific that is happening.

dsn5ft on Aug 3, 2020

@dsn5ft sounds good. I will still give this a whirl when I get a chance to try the newest updates. Thanks again!

ColtonIdle on Jun 16, 2020

Yep exactly, that’s what I was thinking with the FrameLayout.

dsn5ft on May 18, 2020

Thanks for all of the info!

I would definitely recommend a container transform (without traditional shared element) for that Kodaline transition. It wouldn’t result in the exact same staggered effect as in the GIF, but when set up correctly (with the correct container colors in place), I think it would look really good. And you could probably still have some of that staggered polish effect by having the fab be GONE initially and then fading/scaling it in, potentially even while the container transform animation is happening.

Re: the “bad” container transform, I think that’s a relatively common issue we’re seeing when the incoming screen/view doesn’t have a background, but it should be easily fixable. I’d suggest either:

Setting a background (something like android:background="?attr/colorSurface") on your root view in the incoming screen, that way you don’t get any overlap due to transparency.

Setting a container color on the transform itself and changing its fade mode to be a “fade through”, that way a persistent container background will be drawn as part of the transition animation, and the outgoing and incoming content will be faded out and in sequentially. Something like:

    transform.setContainerColor(...<read in R.attr.colorSurface>...);
    transform.setFadeMode(MaterialContainerTransform.FADE_MODE_THROUGH);

(I actually did the latter in a recent update to our Catalog app - https://github.com/material-components/material-components-android/commit/d5faac589b283dbe90b45952cd41bdf5cc2f63a6)

dsn5ft on Apr 22, 2020