Detailed explanation of Android Transition Framework --- super cool animation framework

Preface

As early as Android 4.4, Transition was introduced, but it was not truly implemented until 5.0. What is Transition used for? Next, I will analyze this powerful animation framework of Google through examples and principle analysis.

Let's start with a rendering to calm the situation

This effect will be described below, but you must first understand some basic concepts of this framework.

The core of Transition Framework is to help developers automatically generate animations based on different scenes (explained below). Usually, animations are enabled through the following methods.

• TransitionManager.go()
• beginDelayedTransition()
• setEnterTransition()/setSharedElementEnterTransition()

Let’s explain each of these situations one by one.

TransitionManager.go()

First, let's introduce the Scene class and see the official explanation.

A scene represents the collection of values ​​that various properties in the View hierarchy will have when the scene is applied. A Scene can be configured to automatically run a Transition when it is applied, which will animate the various property changes that take place during the scene change.

The popular explanation is that this class stores the properties of various views under a root view. The instance is usually obtained by getSceneForLayout (ViewGroup sceneRoot, int layoutId, Context context).

• sceneRoot

The location where the scene changes and the animation is executed

• layoutId

That is the root view mentioned above

Maybe this explanation is a bit weak, so let me give you an example.

[[185335]]

 private Scene scene1; 
 
 private Scene scene2; 
 
 private boolean isScene2; 
 
 @Override 
 
 protected void onCreate(Bundle savedInstanceState) { 
 
    super.onCreate(savedInstanceState); 
 
    setContentView(R.layout.activity_scene); 
 
 initToolbar(); 
 
 initScene(); 
 
 } 
 
 
 private void initScene() { 
 
    ViewGroup sceneRoot= (ViewGroup) findViewById(R.id.scene_root); 
 
    scene1=Scene.getSceneForLayout(sceneRoot,R.layout.scene_1,this); 
 
    scene2=Scene.getSceneForLayout(sceneRoot,R.layout.scene_2,this); 
 
    TransitionManager.go(scene1); 
 
 } 
 
 
 /** 
 
 * Switch between scene1 and scene2 and play animation * @param view   
 
 */ 
 
 public void change( View   view ){ 
 
    TransitionManager.go(isScene2?scene1:scene2,new ChangeBounds()); 
 
 isScene2=!isScene2; 
 
 }

scene1:

scene2:

Note that in the two scene layouts, 1 and 4, 2 and 3 have the same ID except for the different positions and sizes of the images. They can be considered as one view because the different creation animations of the starting scene are for the same view.

The above simple example triggers the animation through the first method TransitionManager.go(). That is, when entering the Activity, manually set the start scene to scene1 through TransitionManager.go(scene1). Click the button to switch to the end scene state through TransitionManager.go(scene2, new ChangeBounds()): scene2.Transition The framework analyzes the differences between the start scene and the end scene through the ChangeBounds class to create and play animations. Since the ChangeBounds class analyzes and compares the position boundaries of the views in the two scenes to create movement and scaling animations. It is found that from scene1->scene2 is actually 1->4, 2->3. So the corresponding animation is executed, which is the following effect:

There are several other classes similar to the ChangeBounds class, all of which inherit the Transiton class.

• ChangeBounds

Detect the view's position boundaries to create moving and scaling animations

• ChangeTransform

Detect the view's scale and rotation to create scaling and rotation animations

• ChangeClipBounds

Detects the position boundary of the view's clipping area, similar to ChangeBounds. However, ChangeBounds targets the view while ChangeClipBounds targets the view's clipping area (rect in setClipBound(Rect rect)). If not set, there will be no animation effect

• ChangeImageTransform

Detect the size, position, and ScaleType of ImageView (specifically ImageView) and create corresponding animations.

• Fade, Slide, Explode

These three create fade-in, sliding, and explosion animations respectively according to the visibility of the view.

The implementation effects of the above animation classes are as follows:

• AutoTransition

If TransitionManager.go(scene1) does not specify an animation, the default animation is the AutoTransition class. It is actually an animation collection. Looking at the source code, we can see that the Fade and ChangeBounds classes are actually added to the animation collection.

 private void init() { 
 
  setOrdering(ORDERING_SEQUENTIAL); 
 
  addTransition(new Fade(Fade. OUT )). 
 
          addTransition(new ChangeBounds()). 
 
          addTransition(new Fade(Fade. IN )); 
 
 }

Speaking of animation collections, in fact, animation classes can be created not only through methods like new ChangeBounds(), but also through XML files. And if it is an animation collection, the XML method may be more convenient.

It only takes two steps. The first step is to create an XML file in res/transition as follows:

res/transition/changebounds_and_fade.xml:

 <?xml version= "1.0" encoding= "utf-8" ?> 
 
 <transitionSet xmlns:android= "http://schemas.android.com/apk/res/android" > 
 
 <changeBounds /> 
 
 <fade /> 
 
 </transitionSet>

Then call it in the code:

 Transition sets=TransitionInflater. from (this).inflateTransition(R.transition.changebounds_and_fade);

Finally, I would like to add that TransitionManager.go(scene2) actually calls scene1.exit() of the current scene(scene1) and scene2.enter() of the next scene(scene2).

They will trigger scene1.setExitAction() and scene1.setEnterAction() respectively. You can customize some special effects in these two methods.

beginDelayedTransition()

Next, let's introduce the next trigger method. If you understand the above, the following is very simple. The previous TransitionManager.go() has always created the start scene and end scene according to the XML file, which is a bit troublesome.

The principle of beginDelayedTransition() is to change the properties of the view through code, and then create the animation by analyzing the differences between the start scene and the end scene through the previously introduced ChangeBounds and other classes.

Let’s take an example again:

[[185338]]

 @Override 
 
 protected void onCreate(Bundle savedInstanceState) { 
 
    super.onCreate(savedInstanceState); 
 
    setContentView(R.layout.activity_begin_delayed); 
 
 initToolBar(); 
 
 initView(); 
 
 } 
 
 
 @Override 
 
 public void onClick( View v) { 
 
 //start scene is the current scene 
 
  TransitionManager.beginDelayedTransition(sceneRoot, TransitionInflater. from (this).inflateTransition(R.transition.explode_and_changebounds)); 
 
 // next scene At this point the scene statue has been changed through the code 
 
 changeScene(v); 
 
 } 
 
 
 private void changeScene( View   view ) { 
 
 changeSize( view ); 
 
    changeVisibility(cuteboy,cutegirl,hxy,lly); 
 
 view .setVisibility( View .VISIBLE); 
 
 } 
 
 
 /** 
 
 * Switch between 1.5 times the width and height of the view and the original size * Use ChangeBounds to achieve the zoom effect * @param view   
 
 */ 
 
 private void changeSize( View   view ) { 
 
    isImageBigger=!isImageBigger; 
 
    ViewGroup.LayoutParams layoutParams = view .getLayoutParams(); 
 
 if(isImageBigger){ 
 
        layoutParams.width=( int )(1.5*primarySize); 
 
        layoutParams.height=( int )(1.5*primarySize); 
 
 } else { 
 
        layoutParams.width=primarySize; 
 
        layoutParams.height=primarySize; 
 
 } 
 
 view .setLayoutParams(layoutParams); 
 
 } 
 
 
 /** 
 
 * VISIBLE and INVISIBLE state switching * @param views 
 
 */ 
 
 private void changeVisibility( View ...views){ 
 
 for ( View   view :views){ 
 
 view .setVisibility( view .getVisibility()== View .VISIBLE? View .INVISIBLE: View .VISIBLE); 
 
 } 
 
 }

When a click event is triggered, the current scene status is recorded, and then the size of the clicked view is changed, and the visibility of other views is changed, and then the changed scene status is recorded. In this example, the second parameter of beginDelayedTransition() is a set of ChangeBounds and Explode animations, so the scale animation is executed when the size is changed, and the explosion effect is executed when the visibility is changed. The overall effect is as follows:

Interface switching animation

After talking so much, we finally come to the highlight: the switching effect between Activity/Fragment. There are two types of interface switching, one is Content Transition without shared elements and the other is Shared Element Transition with shared elements.

Content Transition

Let me explain a few important concepts first:

• A.exitTransition(transition)

The Transition framework will first traverse the A interface to determine the view (non-shared element view) on which the animation is to be executed. Before executing A.exitTransition(), the A interface will obtain the start scene of the interface (the view is in the VISIBLE state), and then set all the views to be animated to INVISIBLE, and obtain the end scene at this time (the view is in the INVISIBLE state). Create execution animations based on the differences in transition analysis.

• B.enterTransition()

The Transition framework will first traverse the B interface, determine the view to be animated, and set it to INVISIBLE. Before executing B.enterTransition(), get the start scene at this time (the view is in the INVISIBLE state), then set all the views to be animated to VISIBLE, and get the end scene at this time (the view is in the VISIBLE state). Create execution animations based on the differences in transition analysis.

According to the above explanation, the interface transition animation is based on the change of visibility, so the parameters in getWindow().setEnterTransition(transition); are generally instances of the Fade, Slide, and Explode classes (because these three classes create animations by analyzing different visibilities). Usually, writing a complete Activity Content Transiton has the following steps:

• Add in style

 <item name = "android:windowActivityTransitions" > true </item>

Automatically set to true when Material themes are applied.

• Set up the corresponding A leaves/B enters/B leaves/A re-enters animations.

 //A is not set by default to null   
 
 getWindow().setExitTransition(transition); 
 
 //B is not set to Fade by default 
 
 getWindow().setEnterTransition(transition); 
 
 //B is not set to default to EnterTransition 
 
 getWindow().setReturnTransition(transition); 
 
 //A is not set by default to ExitTransition 
 
 getWindow().setReenterTransition(transition);

Of course, you can also set it in the theme

 <item name = "android:windowEnterTransition" >@transition/slide_and_fade</item> 
 
 <item name = "android:windowReturnTransition" >@transition/return_slide</item>

• Jump interface

The jump interface here cannot just startActivity(intent), it needs

 Bundle bundle=ActivityOptionsCompat.makeSceneTransitionAnimation(activity).toBundle; 
 
 startActivity(intent,bundle)

Ok, now you can run the switching animation between activities.

But you will find that when the interface is switched, after a while, B enters after A exits (it's really too much, not showing A the complete ExitTransition). If you want to wait until A completely exits before B enters, you can set setAllowEnterTransitionOverlap(false) (the default is true), which can also be set in xml:

 <item name = "android:windowAllowEnterTransitionOverlap" > false </item>
 <item name = "android:windowAllowReturnTransitionOverlap" > false </item>

Having said so much, I think I need to give another simple example.

A.Activity:

 @Override 
 
 protected void onCreate(Bundle savedInstanceState) { 
 
    super.onCreate(savedInstanceState); 
 
    setContentView(R.layout.activity_main); 
 
 initToolBar(); 
 
    getWindow().setExitTransition(TransitionInflater. from (this).inflateTransition(R.transition.slide)); 
 
 //If setReenterTransition() is not set, the default is the same as setExitTransition 
 
 } 
 
 
 public void goContentTransitions( View   view ){ 
 
    Intent intent = new Intent(this, ContentTransitionsActivity.class); 
 
    ActivityOptionsCompat activityOptionsCompat = ActivityOptionsCompat.makeSceneTransitionAnimation(this); 
 
    startActivity(intent,activityOptionsCompat.toBundle()); 
 
 }

res/translation/slide.xml:

 <transitionSet xmlns:android= "http://schemas.android.com/apk/res/android" > 
 
 <slide android:duration= "1000" ></slide> 
 
 </transitionSet>

B.Activity:

 @Override 
 
 protected void onCreate(Bundle savedInstanceState) { 
 
    super.onCreate(savedInstanceState); 
 
    setContentView(R.layout.activity_content_transitions); 
 
 initToolbar(); 
 
 
 Slide slide=new Slide(); 
 
 slide.setDuration(500); 
 
    slide.setSlideEdge(Gravity. LEFT ); 
 
    getWindow().setEnterTransition(slide); 
 
    getWindow().setReenterTransition(new Explode().setDuration(600)); 
 
 }

The achieved effects are as follows:

If you look closely at the animation, you can actually find that the status bar of A is also pulled down and up, and there is a certain distance between it and the view below. Virgo said he couldn't stand it.

In fact, in principle, the switching animation of Activity targets the visibility of the view of the entire interface, but is there any way to make the Transition framework focus on only a certain view or ignore a certain view? Of course, transition.addTarget() and transition.excludeTarget() can achieve the above functions respectively.

Conveniently, this attribute can also be set in XML, so what we need to do now is to exclude the statusBar, which can be written in slide.xml like this:

 <transitionSet xmlns:android= "http://schemas.android.com/apk/res/android" > 
 
 <slide android:duration= "1000" > 
 
 <targets > 
 
 <! --Except the status bar-->   
 
        <target android:excludeId= "@android:id/statusBarBackground" /> 
 
 <! --Only for the status bar-->   
 
 <! --<target android:targetId="@android:id/statusBarBackground"/>--> </targets>   
 
 </slide> 
 
 </transitionSet>

It's done. I won't post the effect, you can imagine it...

Shared Element Transition

Content Transition and Shared Element Transition often exist at the same time in interface switching. Different from Content Transition, there are mainly the following differences:

• startActivity()

 Bundle bundle=ActivityOptionsCompat.makeSceneTransitionAnimation(activity, pairs).toBundle; 
 
 startActivity(intent,bundle)

Here pairs is a collection of instances of the Pair<View, String> class, which stores the shared view and name between the two activities. The name here should be consistent with the transitionName of the shared view of interface B. Like this:

 Intent intent = new Intent(this, WithSharedElementTransitionsActivity.class);
 ActivityOptionsCompat activityOptionsCompat = ActivityOptionsCompat.makeSceneTransitionAnimation(this
 ,new Pair< View , String>(shared_image, "shared_image_" )
       ,new Pair< View , String>(shared_text, "shared_text_" ));
 startActivity(intent,activityOptionsCompat.toBundle());//xml<TextView
 android:text= "withShared"  
 android:transitionName= "shared_text_"  
 style= "@style/MaterialAnimations.TextAppearance.Title.Inverse"  
 android:layout_width= "wrap_content"  
 android:layout_height= "wrap_content" /> 
 
 
 ><de.hdodenhof.circleimageview.CircleImageView
 android:id= "@+id/icon_gg"  
 android:layout_centerInParent= "true"  
 android:src= "@mipmap/xkl"  
 android:transitionName= "shared_image_"  
 android:layout_width= "150dp"  
 android:layout_height= "150dp" />

• setSharedElementEnterTransition()/setSharedElementReturnTransition()

If not set, the default is @android:transition/move animation. The defaults for setExitTransition() and setEnterTransition() are null and Fade.

In fact, the principle of Shared Element Transition is similar to Content Transition, both of which create animations based on the different status of the scene.

The difference is that Content Transition creates animation by changing the visibility of the view to change the state of the scene, while Shared Element Transition creates animation by analyzing the size, position, and style of the shared view of the A and B interfaces. Therefore, the former usually sets Transitions such as Fade, while the latter usually sets Transitions such as ChangeBounds.

Finally, let's analyze how to achieve the gif effect at the beginning of the article.

1. The entire animation includes Content Transition and Shared Element Transition. However, the setExitTransition() of interface A is not set to null.
2. When entering interface B, the shared view here is simply moved, so setSharedElementEnterTransition(transition) does not need to be set, and the default is move. At the same time, a water ripple expansion animation will be executed, which can be achieved through the ViewAnimationUtils.createCircularReveal() method. After the Shared Element Transition ends, Content Transition is executed, and it can be seen that it is a Slide animation. So it can be completed by setting setExitTransition(new Slide()). Note that Slide here only acts on the bottom item (target must be set), otherwise it acts on the entire view.
3. The most important thing is that when B exits, you can see the upper part of the screen slides up and the lower part slides down. A visual effect of being torn in the middle. So you can split the layout into two and specify it as a target with two different directions of Slide, like this:

 <transitionSet 
 
 android:duration= "800" xmlns:android= "http://schemas.android.com/apk/res/android" > 
 
 <slide android:slideEdge= "top" > 
 
 <targets > 
 
     <target android:targetId= "@id/viewGroup_top" ></target> 
 
 </targets> 
 
 </slide> 
 
 <slide android:slideEdge= "bottom" > 
 
 <targets > 
 
     <target android:targetId= "@id/viewGroup_bottom" ></target> 
 
 </targets> 
 
 </slide> 
 
 </transitionSet>

There is actually a pit here. Let's first look at the isTransitionGroup() method:

 public boolean isTransitionGroup() { 
 
 if ((mGroupFlags & FLAG_IS_TRANSITION_GROUP_SET) != 0) { 
 
 return ((mGroupFlags & FLAG_IS_TRANSITION_GROUP) != 0); 
 
 } else { 
 
     final ViewOutlineProvider outlineProvider = getOutlineProvider(); 
 
 return getBackground() != null || getTransitionName() != null || 
 
             (outlineProvider != null && outlineProvider != ViewOutlineProvider.BACKGROUND); 
 
 } 
 
 }

The return value is true, which means that the ViewGroup executes the Activity Transition as a whole, and false, which means that each subview in the ViewGroup executes its own. If the ViewGroup sets background or TransitionName, or setTransitionGroup(true), the return value is true, which means that the animation is executed as a whole.

So it is best to set setTransitionGroup(true) for viewGroup_bottom and viewGroup_top.

The effect is as follows, I added some other special effects

I won't post the specific code. All the codes in this article have been uploaded to Github (I am the link), including the switching of Fragments which is not introduced in this article but is included in the code. I hope everyone can give me a star.

If you still don't understand what it means after reading it once, I strongly recommend that you read it again while running the code. It is actually quite simple once you understand it.

Finally, I want to say that there are still some things about this Transition Framework that I haven’t finished talking about. It may take some time to update. Next, I will also write related articles about Dagger 2 and the enhanced version of NavigationBar, so stay tuned.