I'm sorry, I was late on today's Reddit Compose AMA. I just wanted to say thank you started to provide AMAs so often. This will strengthen the connection with the developer community. Keep it up. (and repost some questions 🤗_)_ My questions are: 1. Android App Widget, Notification, Slice. Does Compose soon or later will have support for them? 2. The state of Java in Android development? I love Kotlin. I understand that Compose is building on top of Kotlin compiler plugin API and Compose-Java interoperability is out of the question. But Android Java projects are doomed to use the legacy UI system. How do you see the future for the use of Java in android development? 3. The question that worries me a lot. Compose is positioned as an unbundled UI Framework which not depends on legacy

android.view.View

. It uses only

android.graphics.Canvas

to draw its own widgets. Which gives the ability to use the latest additions to the Compose Views on any android version. And it's basically true and fantastic to be free of some bugs on some android version in the legacy UI system. But... The only thing left unchanged, it is still blocking us to create rich UI experiences, the saturated elevation. It has Android API 28+ limitation 😞 Designers love to make rich UIs with a lot of fancy colorful shadows under the widgets. Ambient light, glow, neon, pulse... I have a hope Compose will provide the ability to implement its own Elevation provider as Modifier(or something else). Thank you.

2. Why an Android Java project can't have Kotlin files?

1. It’s too early to say but given how app widgets and notifications work, it would mean baking Compose in the platform, which would go against one of the main benefits of Compose, that of being decoupled from the platform. Slices could be built on top of Compose but there wouldn’t be much benefits?

They definitely can and do have. Many projects are mixes of legacy Java code and new features written in Kotlin. My question is more specific to the people who are wont or cant migrate to kotlin. For instance, Java 14 is pretty neat. And new Desugar in AS 4.2 allows to use modern Java. @Davide Giuseppe Farella

3. It’s a tradeoff. To lift platform-related limitations we’d have to bring our own rendering stack, which would be big (several megabytes). It would also limite interop between Views and Compose, or make it more complicated/expensive

I thought Jetpack Compose had minSdkVersion 21 ?

It does yes

1. You can do these and more with a custom Applier from the app side of things, @Leland Richardson [G] posted the basics of how in a tweet: https://twitter.com/intelligibabble/status/1273339533891788800 - we might do something more official with these in the future but you don't need to wait on us. 2. What @romainguy said; see

AbstractComposeView

for how to bridge Compose UIs so that they can be consumed as Views by other app code. 3. Since compose doesn't clip to parents by default this is also easier to do as a custom drawing modifier that draws behind an element and beyond its layout bounds. It won't necessarily look 100% like the platform shadows, but you can have more control over it.

@romainguy @Adam Powell much appreciated for your help

That answer for 1 confuses me: • Slice publishers do not describe a UI. They provide data and suggest a generalized template. I don't see how Compose fits here. I suppose you could replace the Slice builder API with some custom tree created with Compose but... to what end? • Anything tied to

RemoteViews

cannot really use Compose, insofar as Compose isn't working with views (by and large). How would an

Applier

address any of that? I can see a slice host using Compose for rendering slices. I can see rendering Compose to a

Bitmap

as a kinda-sorta way of using Compose with

RemoteViews

. And I can see

SurfaceControlViewHost

as being a potential long-term app widget/notification replacement option (and Compose should work with that). But I don't see the role of

Applier

for any of that either. I feel like I'm missing something, possibly sleep. 💤

@romainguy Recently looking through the AOSP code for the Elevation implementation, I found this interesting package: https://cs.android.com/android/platform/superproject/+/master:frameworks/layoutlib/bridge/src/android/view/shadow/HighQualityShadowPainter.java It looks like it does the same (or at least tries to) as Skia shadows render. I was wondering if this is some kind of experiment to simulate native shadow, but rendering at the framework level? 🤔

@Mark Murphy they do describe a tree, and compose can be used to reactively/declaratively maintain and update that tree. Same for RemoteViews. We did a very early experiment/proof of concept with RemoteViews last fall (before the surrounding APIs were made a lot nicer) and it worked startlingly well

Understood, thanks

@Adam Powell OK, I think the difference in our takes is the "Compose" vs. "Compose UI" distinction. When I see developers ask the sort of question that is 1, I assume that they are referring to Compose UI. Your answer is for Compose (building trees), and I was thinking in terms of Compose UI (using the supplied library of composables to draw stuff). Since we're still dealing with developers who like the bleeding edge, my Compose UI thinking probably was flawed -- sorry! (and I still need sleep)

no worries 🙂 in practice the distinction doesn't feel very different to the end developer; the programming model of compose remains the same but you end up with a different set of nouns in the API surface

So we can use compose to manage a tree of... Views? Not sure what the use case would be

It would give you a reactive programming model for the existing views

3. There was a discussion about custom shadows some time ago: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1594065063468800