Loading...

Shared element activity transition glitch

9,545 views

Loading...

Loading...

Loading...

Rating is available when the video has been rented.
This feature is not available right now. Please try again later.
Published on Oct 29, 2014

This video is an example illustrating a common problem that can happen during shared element activity transitions. The glitch occurs at 0:09 when the grid item is clicked for the second time.

Notice how the clicked grid item abruptly pops out from underneath the application's ActionBar and the system status bar before the exit transition begins.

This behavior is jarring and should be avoided... ideally the grid item would slide out from underneath the status/action bars instead of immediately popping out from underneath them when the transition begins.

Link to related Google+ post: https://plus.google.com/1007516098911...

Comments • 21

Alex Lockwood
Dealing with shared elements that draw on top of the system UI One of the more annoying glitches I've encountered with Activity transitions so far has to do with shared elements that are partially covered by the Status/Navigation/Action Bar: once the transition begins, the shared elements will abruptly "pop up" from underneath the system UI. This jarring behavior is demonstrated at http://youtu.be/yAbDPjhftlQ?t=0m09s in the example video below. For more info on the new Lollipop shared element transitions, check out my series of blog posts here: http://www.androiddesignpatterns.com/2014/12/activity-fragment-transitions-in-android-lollipop-part1.html THE PROBLEM The reason why this behavior occurs stems from the fact that by default shared elements are drawn in the decor view's ViewOverlay, on top of the entire window's View hierarchy. This default behavior ensures that the shared elements will always be the central focus of the Activity transition, as it makes it impossible for non-shared elements--in both the called and calling Activity's view hierarchies--to accidentally draw on top of the views that are being shared across Activities. Unfortunately, this behavior also means that shared elements can now potentially be drawn on top of the application's Action Bar, Status Bar background, and/or Navigation Bar background if you aren't careful, something we definitely need to avoid.  THE SOLUTION Fortunately, there are two solutions I've found that can prevent this undesirable behavior from happening: (1) Disable the overlay by setting android:windowSharedElementsUseOverlay="false" in your XML. When disabled, the shared elements will be drawn as part of the called Activity's view hierarchy, making it impossible for the shared elements to accidentally overlap on top of the system UI bars. Unfortunately, disabling this behavior might end up introducing new problems as well... for example, you might find that non-shared views in either Activity begin to clip the shared elements as they transition into place. In most cases you can prevent this from happening by setting android:cliptoChildren="false" and "android:clipToPadding="false" for each shared element's parent in your XML, although additional configuration might be required depending on the specific use case. (2) Another way to solve this problem is to add the Action Bar, Status Bar background, and Navigation Bar background as additional shared elements in your Activity transition. By making the system bars shared elements, you can ensure that both the original shared elements and the system UI are drawn at the same level on top of the rest of the window's View hierarchy. To obtain a reference to these views, you can use the following code: View decor = getWindow().getDecorView(); View statusBar = decor.findViewById(android.R.id.statusBarBackground); View navBar = decor.findViewById(android.R.id.navigationBarBackground); View actionBar = decor.findViewById(getResources().getIdentifier(         "action_bar_container", "id", "android")); (Note: if you use the appcompat support library, you can and should reference R.id.action_bar_container directly instead of extracting the ID from the application resources using the code above.) Of the two approaches above, I personally found that the second approach overall was much easier/simpler to implement than the first (disabling the shared element view overlay ended up causing too many undesirable side-effects in my case). This is a topic I will definitely be covering in a future (more detailed) blog post, but until then hopefully this information helps. :) Link to video: http://youtu.be/yAbDPjhftlQ #androiddev #activitytransitions
View all 17 replies
Hide replies
Evangelos Tsigaridas
Problem still exists
Bharat Dodeja
@Alex Lockwook, did you write a detailed blog post on the same? If yes, could you please share the link?
周龙
how can i set the shared element transition disabled when the shared element is invisible? It may happens the called activity can be scrolled vertical.
When autoplay is enabled, a suggested video will automatically play next.

Up next


to add this to Watch Later

Add to

Loading playlists...