Animation / Animation Set / Transition / ViewOverlay

Manual Layout Transitions – Part 4

Layout transitions are an important aspect of Material design as they help to indicate the user flow through an app, and help to tie visual components together as the user navigates. Two important tools for achieving this are Activity Transitions (which we’ll cover in the future) and Layout Transitions which we have covered on Styling Android before. However Layout Transitions are only supported in API 19 and later. Previously we created two distinct layout states and were able to toggle between them transitioning nicely, but there was a hard requirement of our implementation that any Views in our starting layout must have corresponding Views in the destination layout and vice versa. In this article we’ll look at removing that restriction.

The big complication of having differing View sets in our two layouts is easily recognised when we consider the case of a particular View which appears in our starting layout but does not appear in the destination layout:

In this layout we have the CardView with the ID translation, and in this layout it is missing:

The problem that we have is that when our OnPreDraw() method gets call just before the new layout is drawn we there simply isn’t a View in the new layout for us to animate. There was in the old layout, but that has now been destroyed, so we can’t do anything with it. There’s a way around this if we’re targeting API 18 and later – we can use ViewOverlay which provides a mechanism for doing precisely what we need, but we’ve set minSdkVersion="15" on this project so we can’t use that. However, if we understand what ViewOverlay actually does, we can roll our own quite easily.

ViewOverlay is essentially a lightweight ViewGroup which is rendered on top of the current layout. By lightweight I mean that it does not perform the normal measure and layout passes for its children which most ViewGroups do. Instead it create a Bitmap representation of any View that gets promoted to the ViewOverlay. We can then perform animations on this Bitmap representation within the ViewOverlay even if the original View, from which the Bitmap was created, has since been destroyed.

With that understanding we can construct our own fairly easy. In our onPreDraw() callback we create a FrameLayout which we add to the parent layout. This will act as our ViewOverlay:

As well as creating the overlay, the other important thing in here is the handling of a View which does not exist in the new layout – so we call addOverlayView() to add it to the overlay. More on this later.

Now that we have out ViewOverlay set up we need to think about how to get Bitmap representations of our Views. We need to do this before the Views in the old layout get destroyed, so we’ll add this to the ViewState:

This has got a little more complex because we need to deal also with null View objects being passed in – this will happen in cases where a View exists in the new layout but not the old one. We will have a View object that we can animate in new layout, but won’t have a starting ViewState. Therefore we’ll create an empty state which will mimic a View which was not visible in the old layout.

The other obvious thing is that we now store a Bitmap representation of the View which we’ll use later on. This is created within the getBitmap() method. We create a Bitmap matching the dimension of the View, create a Canvas which will allow us to draw to that Bitmap, and then draw the View on to the Canvas. Voilà we have a Bitmap representation of our View. This gets stored in the ViewState along with absolute left and top co-ordinates. The reason for this is that if we call getLeft() and getTop() on the View itself, it will return co-ordinates relative to the immediate parent of the View. That layout may be in a different location in the new layout (or may not exist at all) so a relative position is of little use. By getting an absolute position here we can ensure that we position things correctly in the overlay.

So back to the addOverlayView() method which we saw earlier:

This creates an ImageView which gets positioned according to the absolute position of the original View relative to the overlay, and then adds it to the overlay. We return this View as the one which we’re going to animate. We call setAdjustViewBounds(true) to automatically determine the width and height of the ImageView when we set the Bitmap and, of course, we use the Bitmap representation of the old View which we created earlier.

We’re almost there, the only thing that remains is to look at a slight difference in how the TransitionAnimator is actually created, Rather than passing in View objects, we now pass in an array of ID resources and find the Views. This is because of the case where Views which exist in the destination layout but not in the current layout. By passing an ID we can cope with a missing View much better:

There are a few null and state checks which have also been added, but I won’t bother covering them here as we’ve covered the important techniques – they are all in the source code.

So if we run that we can see that things work as before, but we now correctly handle Views which don’t appear in both layouts:

One final thing worth mentioning is that the input_done button appears in both layouts with different visibilites. The reason for this is that we want it to move within the parent layout which itself moves in its own transition. If we remove it from the layout where it is not visible, then it won’t be associated with the moving parent layout when it is fading out, so won’t move with it. By keeping it in both layouts we get the movement we require.

That concludes out look at manually performing transitions. Of course there are a number of use-cases which we haven’t covered here (such as dismissing list items) but the basic techniques are still the same: track the start state of the Views, apply the new layout, track the end state of the Views, calculate and run animators between the two states.

The source code for this article is available here.

© 2015, Mark Allison. All rights reserved.

CC BY-NC-SA 4.0 Manual Layout Transitions – Part 4 by Styling Android is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Permissions beyond the scope of this license may be available at http://blog.stylingandroid.com/license-information.

Leave a Reply

Your email address will not be published. Required fields are marked *