How does Compose relate to current View system? I mean, Android UI Compose. Is there somewhere down the stack an actual Android View used? From the ADS talk I assume that for at least some of the components there is (for example WebView, MapView maybe TextView?). If so then where is this layer in the stack that was showed on ADS presentation? Are there Compose Components that are completely independent of current View system that are written completely from scratch using Compose? And last question is about @GenerateView annotation - what does it do? Does it translate Compose code into View code under the hood? Or maybe it generates an xml or something?

Are there Compose Components that are completely independent of current View system that are written completely from scratch using Compose?

Yes, most of them, except very complex like WebView and MapView

Thanks! If some of Compose components are using Views under the hoods, then I guess I’ll be another way to do a step by step migration of an existing app to Compose. For going Compose->View there is @GenerateView but as mentioned in ADS talk we need a mechanism that can do it in the opposite way View->Compose. So if there is an API that allows to easily create a Compose component that uses a View under the hoods then we could use that maybe.

using Views under the hoods

They do not use Views under the hood, it’s just a way to render Android view as part of Composable components

You also have to keep in mind that

View -> Compose

means you lost a lot of the goal of “not relying on `View`” (e.g. that custom view has it’s source of truth) might be gone. The existing mechanism of

View -> Compose

seems to be really really really only intended for stuff that uses

SurfaceView

.

It make sense for any complicated View

Yes I understand that but there are lots of valuable open source projects or even sdks that provide views, so to make adoption faster it would be good to have some temporary way of wrapping existing code so that it becomes Compose friendly.

@louis993546 and custom views you might not want to rewrite

Writing custom views with declarative ui is fun so I suspect there will be a lot of new open source libraries, like it is in Flutter ecosystem. What I like about declarative ui is that if there is some component that doesn’t have the functionality I want, then I can just look what other components it uses under the hoods and go layer by layer until I get to the point where I can reuse everything that sits below and then just write the top layer myself. There is a lot less copying involved compared to inheritance based system we have now.

Does this mean that Jetpack Compose isn't a good fit for instant apps?

Why?

Flutter brings a complete ecosystem to its aab. which means it takes up a lot of the 4mb allowed. Is this the same with Jetpack Compose?

No, it’s just a new UI framework, not a whole rendering engine 🙂

Ah, great!!! Thx!

We reuse the rendering engine and text stack of the platform, both contain a large amount of native code.

Also flutter includes whole runtime of Dart, not only rendering engine

Yeah so assuming your app doesn't use Kotlin then you have to take Kotlin size into account.

I thought you didn't need to bundle the stdlib with your app?

You pay only stdlib size (about 1 mb), also it can be significantly reduced with r8

You do need the Kotlin stdlib, yes, though Andrey is correct

So going back to my original question - what does @GenerateView do (or will do) under the hoods?

The exact details are TBD, but the short answer is "produce a view that renders a Compose hierarchy" - this is how we render our hierarchies today, via

AndroidComposeView

Oh I understand, makes sense thank you!