[Motion] Can't use both Container transition and Shared element

[ColtonIdle]

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.

[dsn5ft]

Hi @ColtonIdle, thanks for the feedback! In the GIF you linked, that's actually just a pure container transform. It looks like the image is a shared element because it's in the same relative position in both the start and end containers.

We believe that the container transform pattern is simpler and more generally applicable than the traditional shared element pattern, while providing an effect that works well and emphasizes the navigation hierarchy. With that said, supporting the container transform with a traditional shared element seems like a reasonable request, so I'll leave this open.

One potentially tricky thing about combining the two patterns is that the image shared element would have to be excluded from the container transform animation, which currently animates the container and all of its children. Do you have a mock of what you'd like your final container transform + image shared element to look like?

[ColtonIdle]

Nice to hear that it's just a container transform! I guess my current container transform just looked really bad when I had a similar setup (card expanding into a fragment) and it seemed to look bad to me because the image and elements didn't seem all that natural. I agree that in the gif I linked, the 1st animation looks pretty darn perfect.

But yes, I would love to say (in example 1) that "Hey this is a container transform, but bundled inside of it I want the imageView and textView to also land here" and so it would make sure to smooth the animation of those two items.

I'll try to come up with a sample app animation that shows the container transform looking "bad". I was working on hitting a deadline and so I didn't have much time to refine what I was working on. The shared element docs aren't that great in my point of view and so maybe I was doing something wrong? I'll try to check in back here later tonight with an example.

[ColtonIdle]

@dsn5ft maybe another good question to ask (because this is essentially what I'm working with) is how would you try to build this animation... today?

Would this be something that container transform would be better suited for or shared element?

[ColtonIdle]

In addition to the question above, here's an example container transform that looks pretty bad in my opinion.

Fragment A

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val hold = Hold()
        hold.duration = 3000
        exitTransition = hold

    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        view.findViewById<View>(R.id.cardView).setOnClickListener { card ->
            val extras = FragmentNavigatorExtras(card to "shared_element_container")
            findNavController().navigate(R.id.action_FirstFragment_to_SecondFragment, null, null, extras)
        }
    }

Fragment B

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val transform = MaterialContainerTransform()
        transform.duration = 3000
        sharedElementEnterTransition = transform
    }

Am I misusing the MotionContainerTransform?

Here is how it looks with a shared element transition instead:

            val extras = FragmentNavigatorExtras(
                view.findViewById<ImageView>(R.id.imageView) to "sharedImage",
                view.findViewById<TextView>(R.id.textView1) to "sharedText1",
                view.findViewById<TextView>(R.id.textView2) to "sharedText2")
                findNavController().navigate(R.id.action_FirstFragment_to_SecondFragment, null, null, extras)

This looks pretty good, but unfortunately my designer doesn't like how the material card just "goes away". This is something that the motion container transform is good at.

So then my designer says, cant a shared element just be the card? And so I try that

            val extras = FragmentNavigatorExtras(
                view.findViewById<ImageView>(R.id.imageView) to "sharedImage",
                view.findViewById<TextView>(R.id.textView1) to "sharedText1",
                view.findViewById<TextView>(R.id.cardView) to "shared_element_container",
                view.findViewById<TextView>(R.id.textView2) to "sharedText2")
                findNavController().navigate(R.id.action_FirstFragment_to_SecondFragment, null, null, extras)

but that looks really bad again.

This is what led me to the conclusion that it would be great to have a Container Transform with optional shared elements. =)

Maybe I'm just misusing container transform (or theres some fine tuning in there I could do to make it look better).

All of the code can be found here: https://github.com/ColtonIdle/ContainerTransformOrSharedElement

[dsn5ft]

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.

OR

• 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 - d5faac5)

[ColtonIdle]

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.

👍

Tried option 1 and it Looks better

Option 2 looks kinda bad because of the fade through

Looks like I'll probably go with option 1? Unless you have any other suggestions. I will say that I'm a little disappointed by the output. it doesn't look like #1 from the original sample gif I posted at all.

Also, whats the difference between settings a background color on rootview vs transform.setContainerColor(...<read in R.attr.colorSurface>...);?

[jonasnaimark]

Hey @ColtonIdle
Option 1 is your best bet. Regarding not looking like #1 from the sample, there's a few things to consider:

• The recordings are in super slow motion, so frames that are meant to be so fast they're not really noticeable end up being highlighted in an unrealistic way. With default durations the transition will look much better and closer to the sample. Slow mo is great for debugging, but to get a sense of the design I'd suggest testing on a device using normal durations.

• The incoming view has a purple app bar which is a bit distracting. The sample details page uses a transparent app bar which creates a more seamless fade between views.

• The card shadow disappears the instant it starts expanding which creates a small visual glitch. This is a bug we're working on.

It's also worth checking out the catalog app which has an implementation of #1 from the sample. Scroll to the bottom and tap "Transitions" then "Demo".

[dsn5ft]

Thanks @jonasnaimark! Re: that last question:

Also, whats the difference between settings a background color on rootview vs transform.setContainerColor(...<read in R.attr.colorSurface>...);?

Calling setContainerColor will result in that color being drawn behind both the start and end container views for the duration of the transition, while a background on the root view in the incoming destination would only apply to that view, which in your case should be drawn on top of the start view.

[ColtonIdle]

@jonasnaimark and @dsn5ft Wow. Thank you for the help. This has all been really great and eye-opening.

@jonasnaimark

1. Good point. I'm sure at a real speed the animation will look better. I just posted them in slow mo in order to have it be easier to show. 😄
2. Any tips for removing the bar? My apps architecture is a single activity and multiple fragments. Each fragment is in control of its toolbar. I wonder if I can just nest the transition one viewgroup down so that the bar stays at the top of the screen? I'll give it a whirl.
3. Thanks for the heads up on the bug. I can definitely see this being even smoother when that's worked out.

@dsn5ft thanks. That makes sense too!

[dsn5ft]

@ColtonIdle np! You might be able to remove the bar from the animation by adding an id to your LinearLayout and using transform.addTarget(<id>).

[ColtonIdle]

Now I'm basically working on removing the toolbar as per @jonasnaimark suggestion.

Here's the anim with a background set on my second fragment, and android:transitionName="shared_element_container" being set to my root view in my second fragment. This is the same as I showed earlier.

Here's the anim but I moved android:transitionName="shared_element_container" down to the linear layout as I basically am hoping to skip the toolbar from also being animated. This looks bad for two reasons. 1. Surprisingly the text looks worse? (didn't expect that) 2. The toolbar "pops" in at the end.

Here's me removing the bar as per @dsn5ft suggestion. I understood the suggestion as android:transitionName="shared_element_container" should still be on my root view, but if I add an id to my LL (android:id="@+id/myActualLayout") and then did transform.addTarget(R.id.myActualLayout) but I got a really weird result. It's as if my duration doesn't do anything anymore? Not sure if this is a bug.

[daniel-stoneuk]

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.