A window into transitions
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Weiss, Ben
This session will guide developers through Android's transition API. We'll get started with the basic set up and end at custom transitions and some pro-tips.
 Hi. Hi, my name is Ben. I was in Berlin for almost seven years before I moved on to London. I'm super happy to be here and see how on the one hand Android has grown, on the other hand how Berlin community and European community has grown to what it is today and continue thriving. Today I will give an introduction into the Android transitions API, but it's not going to just be an introduction. We will take stroll through the first couple of things that are basic principles, then go through an example and then there will be some advanced tips on how you can use the transitions API to make more delightful app for your user. So there's a lot of content to cover, so let's just jump right into it. First off, the basic principles. What is a transition? A transition kicks in whenever there's a scene change. So for example, if you switch activities or if you replace one fragment with another, but also if you want to change layouts, a transition is what happens in between that. It basically covers one thing or a couple of things which is what has changed, so from scene A to CUB, and then it animates these differences. So the core differences are being captured within a couple of methods. There's capture, start and end values to make sure that the views that are being transitioned from starting and ending view are available and that they're how they have changed and you can do a couple of things there, and then there's an animator being created and that animates the changes in between that. It's quite powerful. Most of you in the first place won't have to cover that and won't have to work with it, but it is a thing once you dive into the transitions to a level where you actually want to create your own, those are the methods that you will have to take a look at. Within the framework, we do have several transitions that are built in, so let's take a look at what we have there. KitKat onwards, we had a couple of transitions in there already, so change bounds which allows you to change the size of a view and also position, so it's X and Y values as well as the width and height. You can fade views, so disappear and reappear, and you have another transition which is being used within the framework as well, so if you work with, without actually having your own custom transitions, this is what happens. So views fade in, they change the bounds and then fade out as well. But from Lollipop onwards, there's even more. We added slide transition which allows you to slide views from either side of the view, from either side of the window, as well as some more advanced things like clip bounds, transformation and image transformation to change the bounds and transforms of those views as well. And also motion, because with material design, there's a lot of focus and motion, we do have several ways to control path motions. The most known one is the arc motion which you can see here is massively exaggerated, so please do not do this, this is just for demonstration purposes so you can see what happens. So there's a shadow element in this case that just goes all the way back and up in a curved motion, so you can see that there is something like a gravity that it works with. This is called arc motion, but you also can have a pattern path motion, so you could have views that move in a path other than just the arc that is most of the time the right thing to use. Also, we do have propagations and epicenters which allows you to move views in and out of scene with a start delay depending on where the view, where the screen has been touched. So we have the explode, which is very powerful with that. If it's used, you should use it wisely as well, like most of the transitions, because you can easily confuse the users, that's not what you're aiming for. So after going through the core API, the core classes that are available there, let's take a look into window transitions and what they actually are. So there's several types, so let's take a look at window content transitions. So window content transitions basically means, like I said before, if you change the scene from in this case one activity to another, the view fades in and slides from the bottom, which is straightforward, so everything within the window is being changed. Also, you can have a shared element transition to take one element out of the screen and move it to another scene. And of course, you can combine it to have a window content transition in combination with a shared element transition. So shared element transitions actually are somewhat magic and a little bit of sleigh of hand. What happens is it's not actually that the view itself gets moved to a new activity or a new scene, but what happens is the X and Y values as well as width and height and a couple of more values of the starting view gets sent over to the destination, which has in this case a matching ID with different properties. So it has to move from this one to the other one. So everything gets faded out. So all the views aside of the one that you're sharing gets faded out or gets transitioned in a different way. So this view gets faded out in the background and then gets moved to its new final position. And after that is done, it gets replaced with the one within the final scene. So talking about scenes, there's a couple of things within activity transitions. There is the exit and enter callbacks that you can set, which are the important ones. So window exit, window enter, shared element enter, shared element exit. If you have already, who have you already used transitions by the way? Wow, that's a lot. Cool. Keep it up. You might have noticed that for shared element transitions, you do have only a enter and the exit transition. So what happens is there's another pair of transitions, there's the return and the reenter. And if you don't set these, what will happen is that an exit transition on the way back will become the reenter transition. So you can just, for example, in the window, if you set only a window reenter transition, you also set a window exit transition. But you can, for bigger transitions, if you want to do that, can do different transitions on each and every type of that. So let's take a look at an example. The example source code is already shared, at least most of it already. Rest of it will be shared sometimes in the future. So let's take a look at what we're aiming for. This is an activity, this is an application that has a couple of images, a text view, and it has, on the next activity, it has some text as well to give you some more information on it. And it shares the element, it has an explode transition, it has a couple of more transitions. Which is pretty cool because it takes the user throughout the story so the user knows that they click on the starting view. And we take both the image as well as the author's title with us. This is what we're aiming for. But from default, this is what the system gives you. Which is, in itself, quite cool. But if you add a little bit of extra effort, you can get a lot more out of it. So if you want to set up your app to do this, you first of all need to go into your theme and add the window activity transitions flag and set that to true. Or you inherit from the material if you're API level 21 plus. Who just, who of you supports 21 plus only? As I thought. So this is where AppCompat kicks in. It inherits from theme.material for API level 21 plus and for other API levels does not. So you don't have to actively care for whether it is supported or not and have to have different styles for API levels. At least not for that. So let's get into the first thing that we want to do. So we want to share the image. In order to share the image, we have to set a transition name on both the source view as well as on the target view. We set the names. There are different ways to do it, but this is the best way to actually work with that. And then we start the activity as we already did with just the regular intent. We had a couple of more things to that. So we just set the activity options, which also is available in the Compat version. So if you are below 21, there will, nothing will be happening. So the options, the bundle that you create will not fail you at some point. But you have transitions and the nice things that you did for users that have these features available for users that don't have them, they won't notice the difference. So just instead of activity options, just go for activity options Compat and most of it has a Compat version. But what you do is you just say make scene transition animation. You pass it the activity, you pass it the starting image view as well as the name of the target view. So at the target views transition name. Straightforward, pretty cool. That's the way it works. So let's go and take a look at the next thing. So in order to explode the remaining items of the screen and get them back in, all we need to do is just say, hey, explode. That's it. Straightforward again. But we want to set this as the window exit transition for this activity. So we just set it in the theme for this one activity. This can of course be done in code as well. So within, say, get window and set it on there. But for the purpose of demonstration it's done like this. On the other end, we also want to take a look at what happens when you enter the activity. So we have the sliding in of the content from the bottom which is quite cool as well. Adds a little bit of more emotion and the user sees that there's new things coming in that they didn't already see and doesn't just fade. Which is cool. But we just wanted to go the extra mile. Doing this again is just a little bit of code that you need to add. You just say slide from the bottom which you can omit because that's the default behavior. You can use from start and top as well as the gravity to slide from. Then we set an interpolator. The interpolator in this case helps us to have the content ease in. So it starts at full speed and then gets slower as it reaches its final destination. You can use this without interpolators but if you take a little bit of care for motion and motion design, there's a couple of really good sessions on that as well from Google I.O. and a couple of other droid cons as well. Why this matters and how you can use them and which interpolators to use in which cases. Yeah. And then we just, like I said, you just say get window, set entry transition and then slide. Again, pretty cool, pretty straightforward. You can encapsulate transitions within other transitions as well so you can do pretty powerful things but for getting you started and getting a couple of features already up and done, just very little code in order to get this started. So since we already talked a little bit about motion, let's take a look at what you can do to set a curved motion. So the whole view just moved in a way while expanded. It moved in this motion, in this curved path so that it actually feels a little bit more natural again. So how we did this? A transition set which already contained the change balance, changing the size of the view and the position, transform the clip balance as well and the image transform. We just add to the change balance, we just add arc motion as another transition in there so that the change balance will actually apply this motion in there. So next up is sharing text so we don't just want to share the image but since the text already is in the starting activity, we take a look at how to actually move that from the starting activity to the target activity by growing it while we do that and changing the color. This is not built in but this is custom but it's also within the source code so you can take a look at how it actually is being done. To do this, we take the transition set that we already had so we just expand on that. We add a target ID which is the photo that we had in there already and it will not, this transition set, then will not be applied to any other views that don't have this ID on the screen. Then we add another transition set to just use the target ID of the target authority and set this transition that we created before and there you go, pretty cool, pretty awesome. Of course, there's another change balance in there to actually make the resize possible because otherwise it would not do that. Next up is what we did so far, we shared one element which is pretty cool, just say we pass in the image, we pass in the target name. If you're working with more than one shared element, you need to create pairs to actually let the system know that there's more than one. So the pair is basically the same thing that was with the image in the target down here. Basically you set the view that you want to use as well as the target views transition name for both of them or for as many as you like and then replace the initial values with the new ones. Pretty cool, pretty straightforward again. Let's get into a little bit more complex things. Yes, orientation changes are a fun thing if you handle them correctly when it comes to transitions. You can do transitions like that. So coming back from the initial activity and transitioning back from the view that you had in the first place after changing your orientation, which is a little bit more work because you actually have to think about what you share and how you share it. In order to get this done, there's a couple of small things that you need to do. Of course, you have to have the IDs which in this case have to be unique for each view within the hierarchy because otherwise the system will go through the layout hierarchy and ask who has this ID and the first view that responds within the hierarchy says yep, that's me and the system tries to map that. Also you have to save states during your orientation changes. You have to postpone transitions. Postponing transitions is a pretty powerful concept that helps you to do a little bit of magic before you actually do the transition. So let's take a look at how you do that. We have the source and the target transition name which are not unique per view hierarchy but per view in this case. So I just went on and used data binding to set a data ID which is the unique part to the transition of the starting view so that when we get back from our single layout on the detail view, we just go back to one that has one single ID so we know which system knows which ones to pass. Within the target activity, we have to, sorry, this is for the starting activity. We save the state of the pictures because otherwise the pictures would be reloaded or the system would try to recreate everything. So we save the images or at least the information on the images and within on create, we just get the instance back so that makes it easier for the system to, faster for the system to come back and recover from the orientation change. Also, before we do that, so before restoring the state, we postpone a transition which basically tells the system, your transition is cool, I'm going to accept it but not right now. If you just say postpone transition and don't do anything, of course, there is a competent version of that as well but if you just stop the transition and don't continue, then you will end in somewhat of a weird limbo state that during development can happen sometimes and you basically have to close the app and start it again because the system will not recover from that correctly. In order to get this, not coming to limbo is important to make something like this. On the view that you want to transition on, everything has been inflated and set up so we just put the images back in, created the adapter and everything is on the way that it can be drawn. We add up on pre-draw listener and within that, what we do is we first of all remove the on pre-draw listener because if you don't do that, this call will be executed every time the layout manager wants to redraw something within that view. Then we just say start postpone transition. So you can do a little bit of magic within those couple of milliseconds that you save from the re-inflation of everything that you want to have. That gives you a little bit more of a good feeling for a user as well so you can restore the images and come back to them. This is not just the only magic thing that you can do. You can also remap elements. Basically what happens, I introduce the view pager and what happens here is you slide through that on the way back, it comes back to a different element that is even cooler because it is one of the things that a lot of apps do, they have a gallery within a master activity, then they open it up to have view pagers and you slide through. To do this, you first have to request a result, then update the position within the response, then you have to digest that and you have to remap the elements manually. So let's get started with that. We already know this call, we built up on that. But we do a slight change in that which basically just says, oh, we started the activity for result. So we want the response from the target activity. Within finish or within a place that you deemed possible and necessary to do that, you just say on the way back, we just set the result. If the initial item is the same, I just say result okay so that my code on the other side will get called. And if the position has changed, so if the user actually browsed through the images or through the items, I then say, okay, this is the selected item position, I get the current item, set result okay, put the intent there so that the starting activity can digest that. Within on activity reenter, which is one of the methods that has been introduced within API level 21, you do the postpone transition dance and do the on pre draw dance again. And then you're all set with that. And you're doing that. So this listener will get called once the system is in a state where it actually will draw. So this is not being fired immediately. So what we then do is we set the shared element exit callback. Recall earlier reenter and exit are the same thing. So what will happen is in that, you get the chance to override one of the methods, which is map shared elements. In this case, what I do is I remove all the elements that are obsolete, so all the elements that are not being shared. And I remap the elements to match the currently selected one. So basically what I do is I take out the names, I take out the shared elements and put in new ones. Pretty cool. So this is what we get from all that. A couple of lines of code. I'm quite happy with that. So this state will be shared soon. There's got to be a couple of slight reviews in that. But after that's done, we'll share that to get up again. Link is at the end of the presentation. So let's go to a couple of more things. A couple of pro tips here. So let's go for window decorations. So within Android, you can also take care of status bar navigation bar. If you just say, oh, slide the whole content in from the bottom, what will happen is that also your status bar navigation bar will slide up all the way and down with the content. So there's various ways to deal with this. Either you say, oh, that's fine because it's transparent and nobody will notice anyways, then just let the system take care of it. But if you actually notice this and if you slow down the transitions, which I highly recommend during development, slowing down transitions, so you can feel, you can actually get the feel for things that are a little bit odd and off. So you will see that and you will notice that the view will slide in or out or within explode just moves away and it should feel a little bit odd. So what you can do is within the slide, you can either just say, oh yeah, exclude the status bar background and the navigation bar background. You get those from the system directly. There were just one of the ways you can do that. You also can do the same thing in code. Just say exclude the targets for this transition so that the transition will not be run on those two views. Or on the other hand, you can add it to a shared element transition. So we add another couple of pairs. So to do this, we get the decor view. We find status and navigation bar backgrounds. Sometimes, sometimes devices don't have a navigation bar background because they have hardware navigation bars. So you want to make sure that this view actually has been found because to make sure that your app doesn't crash or you try to do something that doesn't work. But after that, you just create new pairs, add them to your start call and you get to go with that as well. So there's one more thing. I recently found a question on Stack Overflow which deals with reparenting. Reparenting is pretty cool if you do it right. It's pretty easy to shoot yourself in the foot again because magic is happening there somehow. So if you want to move one view from, if you want to move views between layouts, what you can do is in this case we have one activity, two layouts and one view that we want to move from one part to the other. In order to do this, we need to make sure that the child view is not being clipped during the transition. But if you transition, if you have child clipping off for the entire time this screen is being shown, it will happen every time there's a layout passed. It's going to be massively expensive for a system to make sure that everything is within its bounds. So straight forward again, it is one method that I wrote for this which just takes the scene which is for the second layout there. You have the container, you have the layout ready for that. You create the transition, you set a repair listener which is dynamically turning on and off clipping. So at the start of the transition, what we'll do is it turns off clipping for the view hierarchies that you're dealing with and at the end or cancelling of transitions it will turn it all back. So that was faster than I expected but there's all the source code is on Google samples, Android.dash on splash. There's a couple of more transitions, animation samples and material design samples that you definitely should take a look at. Nick butchers' platform is amazing. It's been talked about today as well. One of the great, really good apps that is very powerful and make sure that you take a look at that as well as Topeka is another app that is slightly less complicated and does the same thing as well. Also take a look at the training for transitions. Thank you very much and I'll open the floor to all the questions that you might have. Thank you, Ben. APPLAUSE Yes. Hey, thanks for your talk. In the beginning you mentioned that on the theme you have to go and activate the transitions. Yes, when I'm talking transitions. Do we also have to do that if I extend from the app combat theme? No, that's why I removed it. App combat inherits from material, at least on API 21 plus and the material theme has those transitions already enabled. Okay, so I don't need to do anything there. You just need to inherit from app combat on API level 21 plus. You will get window activity transitions directly. Okay, thanks. Thank you. Who else? Hi, thanks for the presentation. What about fragments? Yes. Is there an API for fragments? Yes, sure. So lots of things work with fragments as well. You just have to make sure that you replace fragments because it doesn't work if you just add and remove them because some of the calls don't get called. The documentation is very clear about this. So make sure that for all the methods you make sure to read what will happen, what will get called. Not all the transitions, callbacks will be a fragment transition. But if you go to the all street sample that is focused on making sure that transitions work for fragments as well. Thanks. Any more questions for Ben? This is not the case. Ben, thanks again for your inspiring talk. Thank you very much.
 Hi. Hi, my name is Ben. I was in Berlin for almost seven years before I moved on to London.  I'm super happy to be here and see how on the one hand Android has grown, on the other  hand how Berlin community and European community has grown to what it is today and continue  thriving. Today I will give an introduction into the Android transitions API, but it's  not going to just be an introduction. We will take stroll through the first couple of things  that are basic principles, then go through an example and then there will be some advanced  tips on how you can use the transitions API to make more delightful app for your user.  So there's a lot of content to cover, so let's just jump right into it. First off, the basic  principles. What is a transition? A transition kicks in whenever there's a scene change.  So for example, if you switch activities or if you replace one fragment with another,  but also if you want to change layouts, a transition is what happens in between that. It basically  covers one thing or a couple of things which is what has changed, so from scene A to CUB,  and then it animates these differences. So the core differences are being captured within  a couple of methods. There's capture, start and end values to make sure that the views  that are being transitioned from starting and ending view are available and that they're  how they have changed and you can do a couple of things there, and then there's an animator  being created and that animates the changes in between that. It's quite powerful. Most  of you in the first place won't have to cover that and won't have to work with it, but it  is a thing once you dive into the transitions to a level where you actually want to create  your own, those are the methods that you will have to take a look at. Within the framework,  we do have several transitions that are built in, so let's take a look at what we have there.  KitKat onwards, we had a couple of transitions in there already, so change bounds which allows  you to change the size of a view and also position, so it's X and Y values as well as  the width and height. You can fade views, so disappear and reappear, and you have another  transition which is being used within the framework as well, so if you work with, without  actually having your own custom transitions, this is what happens. So views fade in, they  change the bounds and then fade out as well. But from Lollipop onwards, there's even more.  We added slide transition which allows you to slide views from either side of the view,  from either side of the window, as well as some more advanced things like clip bounds,  transformation and image transformation to change the bounds and transforms of those  views as well. And also motion, because with material design, there's a lot of focus and  motion, we do have several ways to control path motions. The most known one is the arc  motion which you can see here is massively exaggerated, so please do not do this, this  is just for demonstration purposes so you can see what happens. So there's a shadow  element in this case that just goes all the way back and up in a curved motion, so you  can see that there is something like a gravity that it works with. This is called arc motion,  but you also can have a pattern path motion, so you could have views that move in a path  other than just the arc that is most of the time the right thing to use. Also, we do have  propagations and epicenters which allows you to move views in and out of scene with a start  delay depending on where the view, where the screen has been touched. So we have the explode,  which is very powerful with that. If it's used, you should use it wisely as well, like  most of the transitions, because you can easily confuse the users, that's not what you're  aiming for. So after going through the core API, the core classes that are available there,  let's take a look into window transitions and what they actually are. So there's several  types, so let's take a look at window content transitions. So window content transitions  basically means, like I said before, if you change the scene from in this case one activity  to another, the view fades in and slides from the bottom, which is straightforward, so  everything within the window is being changed. Also, you can have a shared element transition  to take one element out of the screen and move it to another scene. And of course, you  can combine it to have a window content transition in combination with a shared element transition.  So shared element transitions actually are somewhat magic and a little bit of sleigh of  hand. What happens is it's not actually that the view itself gets moved to a new activity  or a new scene, but what happens is the X and Y values as well as width and height and  a couple of more values of the starting view gets sent over to the destination, which has  in this case a matching ID with different properties. So it has to move from this one  to the other one. So everything gets faded out. So all the views aside of the one that  you're sharing gets faded out or gets transitioned in a different way. So this view gets faded  out in the background and then gets moved to its new final position. And after that  is done, it gets replaced with the one within the final scene. So talking about scenes,  there's a couple of things within activity transitions. There is the exit and enter callbacks  that you can set, which are the important ones. So window exit, window enter, shared  element enter, shared element exit. If you have already, who have you already used transitions  by the way? Wow, that's a lot. Cool. Keep it up. You might have noticed that for shared  element transitions, you do have only a enter and the exit transition. So what happens is  there's another pair of transitions, there's the return and the reenter. And if you don't  set these, what will happen is that an exit transition on the way back will become the  reenter transition. So you can just, for example, in the window, if you set only a window reenter  transition, you also set a window exit transition. But you can, for bigger transitions, if you  want to do that, can do different transitions on each and every type of that.  So let's take a look at an example. The example source code is already shared, at least most  of it already. Rest of it will be shared sometimes in the future. So let's take a look at what  we're aiming for. This is an activity, this is an application that has a couple of images,  a text view, and it has, on the next activity, it has some text as well to give you some  more information on it. And it shares the element, it has an explode transition, it  has a couple of more transitions. Which is pretty cool because it takes the user throughout  the story so the user knows that they click on the starting view. And we take both the  image as well as the author's title with us. This is what we're aiming for. But from default,  this is what the system gives you. Which is, in itself, quite cool. But if you add a little  bit of extra effort, you can get a lot more out of it. So if you want to set up your app  to do this, you first of all need to go into your theme and add the window activity transitions  flag and set that to true. Or you inherit from the material if you're API level 21 plus.  Who just, who of you supports 21 plus only? As I thought. So this is where AppCompat kicks  in. It inherits from theme.material for API level 21 plus and for other API levels does  not. So you don't have to actively care for whether it is supported or not and have to  have different styles for API levels. At least not for that. So let's get into the first  thing that we want to do. So we want to share the image. In order to share the image, we  have to set a transition name on both the source view as well as on the target view. We set  the names. There are different ways to do it, but this is the best way to actually work  with that. And then we start the activity as we already did with just the regular intent.  We had a couple of more things to that. So we just set the activity options, which also  is available in the Compat version. So if you are below 21, there will, nothing will  be happening. So the options, the bundle that you create will not fail you at some point.  But you have transitions and the nice things that you did for users that have these features  available for users that don't have them, they won't notice the difference. So just instead  of activity options, just go for activity options Compat and most of it has a Compat  version. But what you do is you just say make scene transition animation. You pass it the  activity, you pass it the starting image view as well as the name of the target view. So  at the target views transition name. Straightforward, pretty cool. That's the way it works. So  let's go and take a look at the next thing. So in order to explode the remaining items  of the screen and get them back in, all we need to do is just say, hey, explode. That's  it. Straightforward again. But we want to set this as the window exit transition for this  activity. So we just set it in the theme for this one activity. This can of course be done  in code as well. So within, say, get window and set it on there. But for the purpose of  demonstration it's done like this. On the other end, we also want to take a look at  what happens when you enter the activity. So we have the sliding in of the content from  the bottom which is quite cool as well. Adds a little bit of more emotion and the user  sees that there's new things coming in that they didn't already see and doesn't just fade.  Which is cool. But we just wanted to go the extra mile. Doing this again is just a little  bit of code that you need to add. You just say slide from the bottom which you can omit  because that's the default behavior. You can use from start and top as well as the gravity  to slide from. Then we set an interpolator. The interpolator in this case helps us to  have the content ease in. So it starts at full speed and then gets slower as it reaches  its final destination. You can use this without interpolators but if you take a little bit  of care for motion and motion design, there's a couple of really good sessions on that as  well from Google I.O. and a couple of other droid cons as well. Why this matters and how  you can use them and which interpolators to use in which cases. Yeah. And then we just,  like I said, you just say get window, set entry transition and then slide. Again, pretty  cool, pretty straightforward. You can encapsulate transitions within other transitions as well  so you can do pretty powerful things but for getting you started and getting a couple of  features already up and done, just very little code in order to get this started. So since  we already talked a little bit about motion, let's take a look at what you can do to set  a curved motion. So the whole view just moved in a way while expanded. It moved in this  motion, in this curved path so that it actually feels a little bit more natural again. So  how we did this? A transition set which already contained the change balance, changing the  size of the view and the position, transform the clip balance as well and the image transform.  We just add to the change balance, we just add arc motion as another transition in there  so that the change balance will actually apply this motion in there. So next up is sharing  text so we don't just want to share the image but since the text already is in the starting  activity, we take a look at how to actually move that from the starting activity to the  target activity by growing it while we do that and changing the color. This is not built  in but this is custom but it's also within the source code so you can take a look at  how it actually is being done. To do this, we take the transition set that we already  had so we just expand on that. We add a target ID which is the photo that we had in there  already and it will not, this transition set, then will not be applied to any other views  that don't have this ID on the screen. Then we add another transition set to just use  the target ID of the target authority and set this transition that we created before  and there you go, pretty cool, pretty awesome. Of course, there's another change balance  in there to actually make the resize possible because otherwise it would not do that. Next  up is what we did so far, we shared one element which is pretty cool, just say we pass in  the image, we pass in the target name. If you're working with more than one shared element,  you need to create pairs to actually let the system know that there's more than one. So  the pair is basically the same thing that was with the image in the target down here.  Basically you set the view that you want to use as well as the target views transition  name for both of them or for as many as you like and then replace the initial values with  the new ones. Pretty cool, pretty straightforward again. Let's get into a little bit more complex  things. Yes, orientation changes are a fun thing if you handle them correctly when it  comes to transitions. You can do transitions like that. So coming back from the initial  activity and transitioning back from the view that you had in the first place after changing  your orientation, which is a little bit more work because you actually have to think about  what you share and how you share it. In order to get this done, there's a couple of small  things that you need to do. Of course, you have to have the IDs which in this case have  to be unique for each view within the hierarchy because otherwise the system will go through  the layout hierarchy and ask who has this ID and the first view that responds within  the hierarchy says yep, that's me and the system tries to map that. Also you have to  save states during your orientation changes. You have to postpone transitions. Postponing  transitions is a pretty powerful concept that helps you to do a little bit of magic before  you actually do the transition. So let's take a look at how you do that. We have the source  and the target transition name which are not unique per view hierarchy but per view in  this case. So I just went on and used data binding to set a data ID which is the unique  part to the transition of the starting view so that when we get back from our single layout  on the detail view, we just go back to one that has one single ID so we know which system  knows which ones to pass. Within the target activity, we have to, sorry, this is for the  starting activity. We save the state of the pictures because otherwise the pictures would  be reloaded or the system would try to recreate everything. So we save the images or at least  the information on the images and within on create, we just get the instance back so that  makes it easier for the system to, faster for the system to come back and recover from  the orientation change. Also, before we do that, so before restoring the state, we postpone  a transition which basically tells the system, your transition is cool, I'm going to accept  it but not right now. If you just say postpone transition and don't do anything, of course,  there is a competent version of that as well but if you just stop the transition and don't  continue, then you will end in somewhat of a weird limbo state that during development  can happen sometimes and you basically have to close the app and start it again because  the system will not recover from that correctly. In order to get this, not coming to limbo  is important to make something like this. On the view that you want to transition on,  everything has been inflated and set up so we just put the images back in, created the  adapter and everything is on the way that it can be drawn. We add up on pre-draw listener  and within that, what we do is we first of all remove the on pre-draw listener because  if you don't do that, this call will be executed every time the layout manager wants to redraw  something within that view. Then we just say start postpone transition. So you can do  a little bit of magic within those couple of milliseconds that you save from the re-inflation  of everything that you want to have. That gives you a little bit more of a good feeling  for a user as well so you can restore the images and come back to them.  This is not just the only magic thing that you can do. You can also remap elements. Basically  what happens, I introduce the view pager and what happens here is you slide through that  on the way back, it comes back to a different element that is even cooler because it is  one of the things that a lot of apps do, they have a gallery within a master activity,  then they open it up to have view pagers and you slide through. To do this, you first have  to request a result, then update the position within the response, then you have to digest  that and you have to remap the elements manually. So let's get started with that. We already  know this call, we built up on that. But we do a slight change in that which basically  just says, oh, we started the activity for result. So we want the response from the target  activity. Within finish or within a place that you deemed possible and necessary to do  that, you just say on the way back, we just set the result. If the initial item is the  same, I just say result okay so that my code on the other side will get called. And if  the position has changed, so if the user actually browsed through the images or through the  items, I then say, okay, this is the selected item position, I get the current item, set  result okay, put the intent there so that the starting activity can digest that. Within  on activity reenter, which is one of the methods that has been introduced within API level 21,  you do the postpone transition dance and do the on pre draw dance again. And then you're  all set with that. And you're doing that. So this listener will get called once the system is in a  state where it actually will draw. So this is not being fired immediately. So what we  then do is we set the shared element exit callback. Recall earlier reenter and exit are the  same thing. So what will happen is in that, you get the chance to override one of the methods,  which is map shared elements. In this case, what I do is I remove all the elements that are  obsolete, so all the elements that are not being shared. And I remap the elements to match the  currently selected one. So basically what I do is I take out the names, I take out the shared  elements and put in new ones. Pretty cool. So this is what we get from all that. A couple of  lines of code. I'm quite happy with that. So this state will be shared soon. There's got to be a  couple of slight reviews in that. But after that's done, we'll share that to get up again. Link is  at the end of the presentation. So let's go to a couple of more things. A couple of pro tips here.  So let's go for window decorations. So within Android, you can also take care of status bar  navigation bar. If you just say, oh, slide the whole content in from the bottom, what will happen is  that also your status bar navigation bar will slide up all the way and down with the content. So  there's various ways to deal with this. Either you say, oh, that's fine because it's transparent and  nobody will notice anyways, then just let the system take care of it. But if you actually notice  this and if you slow down the transitions, which I highly recommend during development, slowing  down transitions, so you can feel, you can actually get the feel for things that are a little bit odd  and off. So you will see that and you will notice that the view will slide in or out or within  explode just moves away and it should feel a little bit odd. So what you can do is within the  slide, you can either just say, oh yeah, exclude the status bar background and the navigation bar  background. You get those from the system directly. There were just one of the ways you can do that.  You also can do the same thing in code. Just say exclude the targets for this transition so that  the transition will not be run on those two views. Or on the other hand, you can add it to a shared  element transition. So we add another couple of pairs. So to do this, we get the decor view. We  find status and navigation bar backgrounds. Sometimes, sometimes devices don't have a navigation  bar background because they have hardware navigation bars. So you want to make sure that this view  actually has been found because to make sure that your app doesn't crash or you try to do something  that doesn't work. But after that, you just create new pairs, add them to your start call and you  get to go with that as well. So there's one more thing. I recently found a question on Stack  Overflow which deals with reparenting. Reparenting is pretty cool if you do it right. It's pretty easy  to shoot yourself in the foot again because magic is happening there somehow. So if you want to  move one view from, if you want to move views between layouts, what you can do is in this case we  have one activity, two layouts and one view that we want to move from one part to the other. In  order to do this, we need to make sure that the child view is not being clipped during the transition.  But if you transition, if you have child clipping off for the entire time this screen is being  shown, it will happen every time there's a layout passed. It's going to be massively expensive for a  system to make sure that everything is within its bounds. So straight forward again, it is one  method that I wrote for this which just takes the scene which is for the second layout there. You  have the container, you have the layout ready for that. You create the transition, you set a repair  listener which is dynamically turning on and off clipping. So at the start of the transition, what  we'll do is it turns off clipping for the view hierarchies that you're dealing with and at the end  or cancelling of transitions it will turn it all back. So that was faster than I expected but  there's all the source code is on Google samples, Android.dash on splash. There's a couple of more  transitions, animation samples and material design samples that you definitely should take a look at.  Nick butchers' platform is amazing. It's been talked about today as well. One of the great, really  good apps that is very powerful and make sure that you take a look at that as well as Topeka is  another app that is slightly less complicated and does the same thing as well. Also take a look at the  training for transitions. Thank you very much and I'll open the floor to all the questions that you  might have.  Thank you, Ben.  APPLAUSE  Yes.  Hey, thanks for your talk. In the beginning you mentioned that on the theme you have to go and  activate the transitions.  Yes, when I'm talking transitions.  Do we also have to do that if I extend from the app combat theme?  No, that's why I removed it. App combat inherits from material, at least on API 21 plus and the  material theme has those transitions already enabled.  Okay, so I don't need to do anything there.  You just need to inherit from app combat on API level 21 plus. You will get window activity  transitions directly.  Okay, thanks.  Thank you. Who else?  Hi, thanks for the presentation.  What about fragments?  Yes.  Is there an API for fragments?  Yes, sure. So lots of things work with fragments as well. You just have to make sure that you replace  fragments because it doesn't work if you just add and remove them because some of the calls don't get  called. The documentation is very clear about this. So make sure that for all the methods you make  sure to read what will happen, what will get called. Not all the transitions, callbacks will be  a fragment transition. But if you go to the all street sample that is focused on making sure that  transitions work for fragments as well.  Thanks.  Any more questions for Ben? This is not the case. Ben, thanks again for your inspiring talk.  Thank you very much.
_droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_0_503.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_504_671.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_672_767.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_768_995.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_996_1151.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_1152_6887.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_6888_10271.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_10272_10583.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_10584_19031.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_19032_20663.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_20664_21467.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_21468_21659.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_21660_22271.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_22272_28067.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_28068_31391.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_31392_31451.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_31452_32975.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_32976_38471.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_38472_38759.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_38760_39119.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_39120_39455.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_39456_39587.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_39588_39779.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_39780_39899.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_39900_40247.png _droidconDE__Ben_Weiss___A_window_into_transitions_lEg3GhDZg2Y_40248_40342.png