Why JellyBeanMR2ViewGroupUtils use sceneRoot.getOverlay()?

[futurexiong]

In ViewOverlayPreJeelybean, we find frame layout with id 'android.R.id.content' and then add the same size framelayout to add overlayView, when use Visibility Transition, the overlayView animation can be drawn out of the sceneRoot's bounds. But in JellyBeanMR2ViewGroupUtils we use sceneRoot.getOverlay(), the overlay bound is the same as sceneRoot's , thus Visibility Transition can not be drawn out of the sceneRoot's bound. I have to download the source code and change sceneRoot.getOverlay() to the top parent framelayout's overlay to achieve my PM's requirement.
Any ideas ? Thanks.

[andkulikov]

Probably we should add clipping with sceneRoot's bounds for views in overlay in that case. I will take a look

[andkulikov]

But wait. Basically its bug in realisation before JellyBeanMR2. So it should be clipped by design, View can move only inside parent bounds. Can you show some more details why do you need it to be drawn outside the sceneRoot's bounds?

[futurexiong]

Thanks for reply. I need an ImageView to do a scale+alpha+translation animation, translation animation need to cross the parent's bounds and then the sibling views do changeBounds transition. because I want to reuse this parent layout, I don't want to mix this view with other layout.

[futurexiong]

When use ViewOverlay to do these kind of animations, I always need to get parent's parent's overlay for a bigger bounds to draw these animations. With your library, do I need to write a custom transition that extends Transition and also write another ViewGroupOverlayUtils? Any suggestions?

[andkulikov]

I can suggest you to put your ImageView in a proper layout. Because child can't be drawn somewhere outside parent's bounds. It's just a contract that child must be inside parent(even just only for animation purposes)

[futurexiong]

Thanks. I can not find a proper way to position my ImageView, because I must group it with other ImageViews in a fixed height parent. This parent layout can be reuse in many other cases. Maybe I should find another way to solve this problem.