I went through this tutorial tonight on using a MVVM (model, view, viewmodel) architecture with SwiftUI and Combine tonight https://www.raywenderlich.com/4161005-mvvm-with-combine-tutorial-for-ios. Very compelling way to build apps. Decouples the UI from the state nicely in a redux/vuex kind of way while being 100% reactive and declarative with minimal boilerplate. I’d love to see something similar with Compose/Coroutines once it’s released 🙂

Extending the above point, Flutter has a lot of state management "choices" and there was not really a recommended way to manage state until last Google IO where speakers recommended something called

Provider

(https://pub.dev/packages/provider) pattern. Would you guys prefer/recommend any specific state management technique for Compose when it gets released?

Composing

Wrap

and

Container

result in a 0 sized child. is this the expected behavior?

Hm, that smells to me like a potential problem with the api. It is always confusing when different parts of a dsl are executed at different times. I had a lot of trouble with gradle for that reason.

I’d love to see some monthly summaries on medium what’s happening on compose and what are the approaches / directions, compose is taking

Yeah, but some kind of nightly builds would be even more awesome!

I just listened to the benchmark episode on the backstage podcast and there was a brief mention of compose and the benchmark lib. Can you tell us a little about these tests? Also about that insight you learned?

Any highlight about app architecture with Jetpack Compose? We’ll stay with MVVM+LiveData or something new like Flutter and their “block” architecture?

I tried animations in Compose and met one serious problem - I really didnt find easy way to set animation time. What about adding

duration

to

fun <T> Transition

function for example?

Do you still have to setup the androidx toolchain to test out compose? I thought I read about it being available in pre-alpha stages through the normal development process but I could be wrong.

Is compose dev branch broken? I get an error message when trying to run

uploadArchives

to install latest compose in local maven repo. I’m trying to build commit dcc1de2983b53d51988bef191cbea7a722edaf08

Love SwiftUI / Combine Framework where UI is a function of state ... Never going back to UIKit. Seeing Compose feel like removing XML, RecyclerView, PagingLib, ViewModel, Room etc ... whenever possible. Thank you for building Jetpack compose in opensource so I can follow the evolution. I am tempted to release all my apps on Compose with Kotlin Flow.

I'm not familiar with Flutter, so may I ask what that gives you over

Padding(16.dp) { Text(text = "Hello, world!") }

I wish Kotlin had support for custom operators like F# lol.

@alexsullivan114 Perhaps I can speak to that one, as I was one of the engineers building React.js at Facebook and was also the person who designed it differently when I proposed building Compose at Google. Creating real views during every composition would be prohibitively expensive. Just as creating HTML elements in browsers can be expensive (although this is improving dramatically in recent years), creating Views on Android is not cheap. To recreate a real view hierarchy on every update would be a non-starter. React and Flutter both use a VirtualDOM, and your `render`/`build` functions return VDOM elements. This worked, and was a relatively revolutionary design decision at the time, and their continued success is a testament to this model. I considered a similar approach for Compose. However, there were a few drawbacks to this approach. 1. Performance. Although the VDOM is orders of magnitude faster than creating real DOM/Views, modern view frameworks are highly optimized, and the VDOM allocations and garbage collection become bottlenecks. Furthermore, creating new VDOM elements means the VDOM elements are no longer referentially equal, which makes them more expensive to compare in the common case where the particular node doesn't change, which becomes the second performance bottleneck. Our approach makes it possible to avoid the allocations (present day) and comparisons (future work), which should allow us to achieve a better performance profile once we start optimizing aggressively (we're still just getting everything working at this point). Furthermore, VDOM makes it harder to statically reason about hierarchy invariants, which make it harder to do some more advanced compile-time optimizations. 2. Readability. The VDOM encouraged a bunch of patterns that made the code less maintainable. For example, users would build up VDOM trees, pass them around, and use them as input to other functions that would return modified VDOM. I personally consider these patterns to be antipatterns, and the Compose style takes them completely off the table because you don't get access to the VDOM elements, so you can't abuse them. 3. Control Flow Ergonomics. Because you need to produce/return VDOM elements, doing control flow becomes awkward. If you want to iterate over nested lists, then you either need to have

list.map { it.map { ... }}

or you need to create a mutable list with nested

for

loops that mutate the list. Those approaches are both perfectly doable, but not super ergonomic. The Compose method ends up handling

if

statements and

for

loops in a more natural way. To be clear, other declarative frameworks like React, Flutter, Vue, and Ember are great frameworks, so please don't take the above as a criticism of them. The various frameworks have different constraints and environments, and these decisions are all just a series of tradeoffs. We as an ecosystem are still learning and experimenting and iterating. We opted to do more work at compile time instead of at runtime with a VDOM, which has both pros and cons. Hopefully we will find that the pros outweigh the cons in our environment, but only time will tell.

What's the story behind the

0.1.0-dev01

Jetpack Compose artifacts that landed in the Google Maven repo? The

androidx.compose

ones seem to be empty, and the

androidx.ui

ones transitively depend on the empty

compose-runtime

one. 🧐

https://developer.android.com/dev-summit/schedule/day1 11:20 -12:00 on October 23 What's New in Jetpack Compose Adam Powell, Clara Bayarri, Romain Guy Jetpack Compose was announced at Google I/O and the team has been hard at work ever since. This talk introduces Compose to new audiences, including what the project is and how it is taking shape. The talk also updates people who already know about Jetpack Compose, including how the project has evolved. ~ So excited I am not sure I can sleep the night before 🎄 ... camping out to be first in line ... LOL

Really awesome, tried to add the new artifacts and render a Hello, World! view and omg, didn't even need to apply a plugin, it just worked, and this hook-like syntax using destructuring for the state is so concise, I'll start playing with this rn 😁.

//MainActivity.kt
setContent {
    val (text, setText) = +state { "Hello, World!" }
    MaterialTheme {
        Column(modifier = padding(8.dp)) {
            Text(text = text)
            Button(text = "Click me", onClick = { setText("Button Clicked!") })
        }
    }
}

I think this question has been already answered, but I am gonna ask it again 😄 Why

val (text, setText) = +state { "Hello, World!" }

And not

var text by State("Hello, World!")

Same questions for

@Composable

actually

@Composable
fun MyComponent() {}

Instead of

fun MyComponent = composable { }

Maybe I should wait for an article about this?

How can I create a Compose Image from a Bitmap? found this function

fun imageFromResource(res: Resources, resId: Int): Image

to create one from a resource and noticed that it uses an

AndroidImage

class that does exactly what I need, but it's internal. Is there a way to do this right now? Or should we copy paste the class or create our implementation of Image what uses a Bitmap?

Spotted ConstraintLayout in Compose: https://android-review.googlesource.com/c/platform/frameworks/support/+/1137175

most/all core components will accept modifiers as far as I understand it, but not all have been refactored to do so yet

but making a Padding composable for yourself to use is pretty trivial

Which one is more kotliner: A “Builder” object functions should (1️⃣return this ) or (2️⃣let me use with/apply etc and don’t return this)

Just saw in some sample floating online that compose needs

kapt

and

kotlin.reflect

now. Will it be permanent requirements or a subject to change?

With compose will there be any use case for fragments (compose only projects)?

Try

./gradlew studio

Hey just a question why the compose runtime is using the kotlin multiplatform plugin are they planning to make the library multiplatform ?