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.

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

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

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

ConstraintLayout supports much more than flexbox-like layouts

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?

{a joke about competing teams and products inside Google}

😅

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

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

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.

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

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

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).