You’ve probably noticed that when you write something like:

context.getResources().getColor(R.color.some_color_resource_id);

Android Studio will give you a lint message warning you that the Resources#getColor(int) method was deprecated in Marshmallow in favor of the new, Theme-aware Resources#getColor(int, Theme) method. You also probably know by now that the easy alternative to avoiding this lint warning these days is to call:

ContextCompat.getColor(context, R.color.some_color_resource_id);

which under-the-hood is essentially just a shorthand way of writing:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
  return context.getResources().getColor(id, context.getTheme());
} else {
  return context.getResources().getColor(id);
}

Easy enough. But what is actually going on here? Why were these methods deprecated in the first place and what do the new Theme-aware methods have to offer that didn’t exist before?

A common source of problems when dealing with shared element transitions stems from the fact that they are started by the framework very early in the Activity lifecycle. Recall from part 1 that Transitions must capture both the start and end state of its target views in order to build a properly functioning animation. Thus, if the framework starts the shared element transition before its shared elements are given their final size and position and size within the called Activity, the transition will capture the incorrect end values for its shared elements and the resulting animation will fail completely (see Video 3.3 for an example of what the failed enter transition might look like).

A shared element transition determines how shared element views—also called hero views—are animated from one Activity/Fragment to another during a scene transition. Shared elements are animated by the called Activity/Fragment’s enter and return shared element transitions,¹ each of which can be specified using the following Window and Fragment methods:

• setSharedElementEnterTransition() - B’s enter shared element transition animates shared element views from their starting positions in A to their final positions in B.
• setSharedElementReturnTransition() - B’s return shared element transition animates shared element views from their starting positions in B to their final positions in A.

A content transition determines how the non-shared views—called transitioning views—enter or exit the scene during an Activity or Fragment transition. Motivated by Google’s new Material Design language, content transitions allow us to coordinate the entrance and exit of each Activity/Fragment’s views, making the act of switching between screens smooth and effortless. Beginning with Android Lollipop, content transitions can be set programatically by calling the following Window and Fragment methods:

• setExitTransition() - A’s exit transition animates transitioning views out of the scene when A starts B.
• setEnterTransition() - B’s enter transition animates transitioning views into the scene when A starts B.
• setReturnTransition() - B’s return transition animates transitioning views out of the scene when B returns to A.
• setReenterTransition() - A’s reenter transition animates transitioning views into the scene when B returns to A.

Activity and Fragment transitions in Lollipop are built on top of a relatively new feature in Android called Transitions. Introduced in KitKat, the transition framework provides a convenient API for animating between different UI states in an application. The framework is built around two key concepts: scenes and transitions. A scene defines a given state of an application’s UI, whereas a transition defines the animated change between two scenes.

When a scene changes, a Transition has two main responsibilities:

1. Capture the state of each view in both the start and end scenes, and
2. Create an Animator based on the differences that will animate the views from one scene to the other.