Consider the following layout:
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:background="@drawable/bg1" >
<View
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="@drawable/bg2" />
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="horizontal" >
<!-- some views here -->
</LinearLayout>
</FrameLayout>
I'm using it to have bg2
on top of bg1
while bg2
remains completely independent, such that I can apply e.g. a tween alpha animation to it without affecting anything else.
bg1
and bg2
are XML drawables. Obviously, they're supposed to be scaled to their respective View's dimensions. This is normally the case and it doesn't seem to make much sense to specify their dimensions explicitly.
Unfortunately, on Android versions prior to 3/API 11, it looks as if the size of bg2
will be zero. Maybe the two-phase layout measurement is buggy (note how bg2
is supposed to inherit its height from its parent, which in turn needs to adjust to the LinearLayout
´s height and propagate that information to the View containing bg2
). Or maybe the View won't accept its parent's height (although I tried ImageView
which changed nothing).
The Layout you see is really used for items in a list.
The XML drawables are stateful and use gradients.
Can you think of an approach which would also work for Android API 8 to 10?
A bit of testing (subclassing
View
, overridingonMeasure()
andonLayout()
) reveals thatFrameLayout
is broken in this respect in older Android versions.Since
FrameLayout
fails to pass its own height down the hierarchy in this scenario (theView
will always see0
both withonMeasure()
andonLayout()
) there is no obvious way to work around this problem by subclassing.The question then was, is there another way to overlay the two views which Android 2.2 aka API 8 can handle correctly.
And alas, there is. The same can be achieved with a
RelativeLayout
, which involves much more overhead of course, though the actual increase in rendering effort should be limited.