recompose
recompose copied to clipboard
Support FrameLayout
View: https://developer.android.com/reference/android/widget/FrameLayout
Composable:
Maybe we can just translate it to a Box()
with children?
Hi, @pocmo I am thinking that Stack
would be a better option here especially for FrameLayout
with children.
https://developer.android.com/reference/kotlin/androidx/compose/foundation/layout/package-summary#stack
looks like all good first start
issues have finished for, I might be interested in working on this one.
Yes, you are right, Stack
looks like a great fit! I'll assign you to the issue. :)
@pocmo I need help here. How would you suggest I handle a case of android:gravity="top|start"
where we have two raw values separated by |
?.
I have verified that the gravity is added as Modifier
to any View or ViewGroup. so if I have top|start
, it should recompose to Alignment.TopStart
for gravity modifier.
Here's an idea...
Android uses bit masks internally.
So top|start
is equivalent to Gravity.TOP or Gravity.START
in Kotlin code.
Gravity.TOP
is 0x00000030
Gravity.START
is 0x00800003
(which is actually LEFT
or RELATIVE_LAYOUT_DIRECTION
)
So the combined value is 0x00800033 (Gravity.TOP or Gravity.START`).
If we map the parsed gravity values to their actual values in the Gravity class and if we map the available Alignment
values to the same combined values, then we should be able to translate between them, e.g.:
Gravity.TOP
(0x00000030
) or
Gravity.START
is 0x00800003
= Alignment.TopStart
(0x00800033
).
Does this make sense? We would need to keep a map from gravity to Int and from Int to Alignment. Do you think that could work?
FYI: Jetpack Compose 1.0.0-alpha04 just got released,
Stack was renamed to Box. The previously existing Box will be deprecated in favor of the new Box in compose.foundation.layout. The behavior of the new Box is to stack children one on top of another when it has multiple children - this is different from the previous Box, which was behaving similar to a Column
Thanks for the heads up. I will check out the new Box then.
Here's an idea...
Android uses bit masks internally.
So
top|start
is equivalent toGravity.TOP or Gravity.START
in Kotlin code.
Gravity.TOP
is0x00000030
Gravity.START
is0x00800003
(which is actuallyLEFT
orRELATIVE_LAYOUT_DIRECTION
)So the combined value is 0x00800033 (Gravity.TOP or Gravity.START`).
If we map the parsed gravity values to their actual values in the Gravity class and if we map the available
Alignment
values to the same combined values, then we should be able to translate between them, e.g.:
Gravity.TOP
(0x00000030
)or
Gravity.START
is0x00800003
=Alignment.TopStart
(0x00800033
).Does this make sense? We would need to keep a map from gravity to Int and from Int to Alignment. Do you think that could work?
Yes, this could work. I observed that gravity attributes: android:gravity
and android:layout_gravity
can be used in any View or ViewGroup as necessary. I suppose we have to add it as a View/ViewGroup attribute so that it can apply for FrameLayout with multiple children.
Also, I observed that when you have a known ViewGroup as the root of the XML to be parsed, the ViewGroup attribute is not parsed while that of the children is parsed.
I found out why the observed issue in the last paragraph was happening, I did not add val rowModifier = ModifierBuilder(node)
to the function visiting FrameLayout
. It is fine now.
Since we added basic support for FrameLayout
I am going to close this issue and will open a new one for adding support for gravity.