Do you guys have already defined how (or if) Compo...

# compose

[Breno]

Do you guys have already defined how (or if) Compose will work along with MotionLayout? I ask this because both seem to be walking in opposite directions: While Compose is aiming to eliminate XML altogether, MotionLayout (wich is also awesome) is relying in describing behavior through XML in spite of Code.

[themishkun]

As far as I’m concern, Compose is aiming to not to simply eliminate XML, but to eliminate the entire View/ViewGroup/Fragment

[gildor]

still the engine of MotionLayout/ConstraintLayout is very powerful and Compose need something like this for layout, because current hierarchy support is very simple and basic

[themishkun]

I think that they will make some animations framework to operate on ui tree changes and make them smooth and beautiful

[themishkun]

I’ve played with YogaLayout in a while and found it at the same powerlevel as ConstraintLayout. You can do everything with nested flexbox-like structures and you get natural composability for free

[gildor]

ConstraintLayout supports much more than flexbox-like layouts

[Breno]

hmmm I see your point... Anyway, if that's the full picture, it seems like a waste of resources investing in developing MotionLayout AND the visual editor for animations (wich is gonna be a huge feature of Android Studio) just to throw it all away sometime in the future, doesn't it?

[gildor]

{a joke about competing teams and products inside Google}

[Breno]

😅

[gildor]

anyway, compose is long term project and not even alpha, MotionLayout already beta

[Andrey Kulikov]

we are going to have an analogue of ConstraintLayout/MotionLayout in Compose in some way. the exact implementation is to be defined by the team

[Hadi Tok]

At one of the presentations Romain said they will talk with the ConstraintLayout team after the I/O. I think the intention is to migrate them somehow. I am really curious about how we will do ConstraintLayout with code with compose.

[Andrey Kulikov]

yes, we will work together with ConstraintLayout team to see what is the best way to do so

[romainguy]

We have some ideas on how to get constraint layout to work

[Nicolas Roard]

I'd add that to me, the key aspect of ConstraintLayout/MotionLayout isn't the fact that we use XML -- it's that you can declare statically very rich behavior. As it's static, 1/ we can build UI tools for it much easier than if we had to run / interpret this in kotlin 2/ it also is easier to reason / work with it from a dev perspective, as you can think in terms of composable high level concepts and don't have to think about side effects like a pure code solution would bring (of course, there's still a place for introducing code-driven layout or animation when you get out of the area covered by those concepts, but all the work we've been doing has been in making those situations as rare as possible).

[Nicolas Roard]

One thing we want to explore as a transition path is to have a Compose ConstraintLayout/MotionLayout that can simply read those XML descriptions (the MotionScene XML file for MotionLayout, but actually ConstraintLayout supports that as well, we just haven't communicated much on it). So your layout XML will only contains your views, pointing to another XML file describes layout constraints or motion; when switching to Compose we could convert automatically for you the layout XML into a kotlin Composable, pointing to the XML descriptions.

[Nicolas Roard]

Later on you also may be able to move those XML descriptions to embedded kotlin code if you so choose, though that might make you lose the GUI editors then, but we're still exploring this.

[Nicolas Roard]

Anyway, all this is still relatively early explorations, and likely to change 🙂