How to Implement Three-Panel Fragment Transition Animation Like in Gmail App?

Other Questions Gmail
1

I’m trying to create a fragment animation that works similar to what you see in the Gmail app. I need help with implementing a three-panel transition effect.

Current Setup

I have two fragments displayed side by side on screen initially (let’s call them Panel A and Panel B).

What I Want to Happen

When user taps something in Panel B, I need these animations to run together:

  • Panel A slides out to the left and disappears
  • Panel B moves to where Panel A was and gets smaller
  • Panel C slides in from the right to fill Panel B’s old space

The back button should reverse all these movements.

Code Example

public class MainActivity extends AppCompatActivity {
    private LeftPanel leftPanel;
    private MiddlePanel middlePanel;
    private RightPanel rightPanel;
    
    private void startPanelTransition() {
        ObjectAnimator slideLeft = ObjectAnimator.ofFloat(leftPanel.getView(), "translationX", 0, -getScreenWidth());
        ObjectAnimator shrinkMiddle = ObjectAnimator.ofFloat(middlePanel.getView(), "scaleX", 1.0f, 0.6f);
        ObjectAnimator slideInRight = ObjectAnimator.ofFloat(rightPanel.getView(), "translationX", getScreenWidth(), 0);
        
        AnimatorSet animationSet = new AnimatorSet();
        animationSet.playTogether(slideLeft, shrinkMiddle, slideInRight);
        animationSet.start();
    }
}

Problems I’m Running Into

  1. Using setCustomAnimations() only lets me specify one in and one out animation, but I need three different animations running at once
  2. Hard-coding pixel values doesn’t work across different screen sizes
  3. Not sure how to handle the third fragment initially (should it be hidden or what?)
  4. Having trouble making this work with layout weights for responsive sizing

Has anyone successfully implemented this type of three-fragment animation? I’ve seen partial solutions but nothing complete that actually works. Any working code examples would be really helpful.

2

You’re overcomplicating this with ObjectAnimators. I hit the same issue building something similar. Here’s what works: use a single FragmentContainerView with ViewPager2, but control it through code instead of letting users swipe. Make your three fragments upfront and manage visibility with fragment transactions plus simple translate animations on the container. For responsive sizing, use a weight-based LinearLayout as your parent. Set initial weights like 1:1:0 for the three panels, then animate weight changes with ValueAnimator. When transitioning, update weights to something like 0:0.6:1 while running translateX animations at the same time. The fragment manager handles lifecycle, your weight animations handle sizing. You’ll skip the setCustomAnimations limitations completely and get perfectly synced movement across all screen sizes.

3

Skip trying to sync multiple fragment animations - it’s a nightmare. Instead, use ConstraintLayout and animate the constraints themselves. Keep all three fragments in the layout at once, then show/hide them with a single FragmentTransaction while running ValueAnimator on the parent container’s LayoutParams. Use percentage widths like 0.4f and 0.6f instead of fixed pixels so it works across different screen sizes. For the third fragment, keep it loaded but set the container to GONE initially. When you need it, flip visibility to VISIBLE and animate the constraint changes. The constraint animation handles positioning, fragment lifecycle handles content - you get perfect sync because you’re animating layout constraints instead of juggling separate fragment animations.

4

I’ve done this exact thing on a client project. Skip the separate fragment animations - use MotionLayout instead. Set up all three panel states in your MotionScene XML with percentage-based positioning and scaling. Then you just trigger everything with one method call. Make a ConstraintSet for your starting state (A and B visible) and another for the end state (B and C visible, with B moved). MotionLayout handles all the interpolation automatically, so everything moves perfectly in sync without timing headaches. Keep the third fragment attached but hidden outside the visible area initially - set its constraint at parent end with 100% translation. When you transition, MotionLayout slides it in while moving the other panels. Going back is just transitionToStart() instead of transitionToEnd(). Works way better than FragmentTransaction animations since you’re animating the container, not individual fragments.

5

had this issue a while back. dont use setCustomAnimations, go with FragmentTransaction and replace(). control ur animations with ViewPropertyAnimator for better smoothness. also, make sure to add the middle frag to the backstack – otherwise, you’ll lose stuff on rotation!

6

honestly just use coordinator layout with behaviors. ive done this exact thing and behaviors handle the coordinated movement way better than trying to sync multiple animators. create custom behaviors for each panel that respond to the same trigger event - way less buggy than fragment transitions.

7

Fragment animations are a pain when you need multiple things happening at once. I hit this same issue last year and ended up automating the whole transition pipeline.

Instead of wrestling with FragmentTransaction limits, I built a workflow that handles all three animations through coordinated API calls. The automation listens for triggers, then fires simultaneous requests for each panel state change.

For your setup, create triggers that manage the left slide out, middle panel resize, and right panel slide in as separate but synchronized operations. No hardcoded pixels or weight calculations - just define transition parameters once and let automation handle timing.

The responsive sizing issue disappears because you can programmatically calculate screen dimensions and adjust animations accordingly. Plus you get proper back button handling through the same automated flow.

I used to spend hours debugging fragment lifecycle issues and animation timing. Now I configure the transition once and automation handles everything. Way cleaner than managing multiple animators or constraint changes manually.