Hello! The latest Jetpack Compose minor release, dev11, was released today! You can get it now on Google’s Maven Repository. Release notes are available at https://developer.android.com/jetpack/androidx/releases/compose and https://developer.android.com/jetpack/androidx/releases/ui. As always, feedback is welcome; please log issues at https://issuetracker.google.com/issues/new?component=612128!

I see

@Preview

already has a fair amount of options. Aer there any plans for having orientation be one of them? So one can preview one's component both in portrait and landscape? That'd be pretty dope. 😎

Going through the merges in the release notes. What does “CL” mean?

The CL adds a padding(horizontal, vertical) overload which adds

symmetric padding. The CL also cleans up the padding-related deprecated

API.

It’s our term for PR

“Change List”

(and it existed before PR :p)

Great going 😄 happy soon to be Friday

And as a follow up, why? 2️⃣ seems much more discoverable to me, but 1️⃣ is more consistent with core compose APIs.

I would encourage you to think of Composables as Widgets, which is to say, as Nouns. You aren't drawing foo, you are placing a widget that happens to utilize foo. There are several reasons this is useful abstraction, but I'm not sure I have a super compelling/satisfying answer, other than to say the pattern generally feels better. People like to talk about a "Search Result" or a "DatePicker" or a "Box". Having it as a noun gives you a word to describe a thing on a page, and point to it and say "see, I mean this thing". I think this mental model tends to work better for the way that people think about the modules that make up a page/screen, especially as the widgets start having their own concerns like handling user inputs or driving animations. Another, maybe less compelling answer is that there are multiple ways a piece of data could be exposed. For instance, suppose you are implementing a bookstore and foo is a Book. You might have a search results page that renders several BookSearchResult(book) and another page that renders a BookDetailsPane(book) and another page that renders an AdminModeBookEditor(book). They're all valid views/representations of a book, so there isn't a single way to draw a book. Sure, you could implement all of them as extension functions if you wanted, but it would be something like

.drawBookAsSearchResult()

and

.drawBookAsAdminModeBookEditor()

or something. You're forcing the noun form into a verb, which begs the question: why? Ultimately, it's just kotlin, and maybe you will discover a pattern that is better than what we've come up with. Feel free to share what you find/think!

I use the word Component when my brain slips into the mode from back when I was an engineer on the React.js core team. I try to prefer the word Widget when I'm talking to Android developers because that's the word that has historically been used on Android, and is slightly more accepted as the industry term for a graphics thing on a page.

A subcomposition allows you to continue the composition in a separate root. This is useful for things like a dialog, where the dialog is conceptually inside the current composition (you want data, themes, ambients, etc) to propagate from the current composition into the new root, but the new root isn't a direct child of the current composition.

Then use structured concurrency constructs from within that scope

Do these transactions affect `CompositionReference`s at all? I'm wondering if some weird behavior I've been trying to figure out had to do with using a reference before the composition it referred to was committed. (Separate thread since this question isn't related to that thread at all.) https://kotlinlang.slack.com/archives/CJLTWPH7S/p1590088448025900?thread_ts=1590086405.023000&cid=CJLTWPH7S

Hey, I was digging into concept of Frames/Records and was curious if there are some sources to read about them. For now as I got it, we have a Frame to observe changes and Records to remember all writes happening during particular Frame before recomposition. However, it would be amazing to have more details on that :)

Hi, I’m trying to update compose version from

0.1.0-dev08

to

0.1.0-dev11

and I’m getting an IllegalStateException exception when I try to build the project. I’m using Android Studio 4.1 Canary 9, Kotlin version

1.3.72

. I set my build.gradle for compose:

buildFeatures {
        compose = true
    }

    composeOptions {
        kotlinCompilerVersion = "1.3.70-dev-withExperimentalGoogleExtensions-20200424"
        kotlinCompilerExtensionVersion = AndroidX.Versions.compose
    }

And my gradle properties looks like this:

# Gradle
org.gradle.jvmargs=-Xmx4g -XX:MaxPermSize=2g -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
org.gradle.parallel=false

# Kotlin
kotlin.incremental.multiplatform=true
<http://kotlin.parallel.tasks.in|kotlin.parallel.tasks.in>.project=true
kotlin.code.style=official

# Android
android.useAndroidX=true
android.enableJetifier=true

Did I miss anything? 🤔

in

dev10

i have used

Draw

after migrate to

dev11

i can’t find them, what should i do?

Why Box accepts padding with this description: * The specified [padding] will be applied inside the [Box]. In order to apply padding outside * the [Box], the [androidx.ui.layout.LayoutPadding] modifier should be used. applying the padding

inside

or

outside

isn't just about the order of

padding

and

preferredSize

modifiers? IMHO these padding parameters implies that the

Box

is different from other layout composables.

It's not. The point is if you want the padded space to be inside the border that can be created with the other parameters or not

is there a way to resize ImageAsset to specific size to draw them at Canvas ?

Shouldn't the padding around box be called margin? Just thinking out loud..

@Leland Richardson [G] for the details

I'm trying that ☝️

But when I run the app I get this error

The minimal diff to fix the error is to add a line above the ListeItem that says 

val context = ContextAmbient.current

 and then use the 

context

 variable instead of reading from the ambient inside the onClick handler. But know that every time you read from an Ambient, I cry a little inside.  Please don't structure your code that way.  Not only are you depending on an API that makes your widget impossible to unit-test, but you're also depending on ambients for something that isn't actually ubiquitous, which is an antipattern IMO, and you're baking implicit app knowledge into your widgets. Instead, pass a handler down into whichever composable is rendering your list item, and have the lambda contain a reference to the Context which was passed down from the current Activity.  It's hard to be more specific, because I can't see the rest of your code, but basically your composable functions should ideally know nothing about Context, and just call a function handler that was passed in when a relevant event occur.  Widgets should generally accept lambdas instead of "knowing how to perform bespoke actions, like launching a specific activity".

I made this assumption based on my little knowledge about compose, to be perfect solution to server rendering but I want hear your thoughts

Hello everyone Is there an "expected" date to Compose go Beta?

Can I say the old deprecated @Model seems less verbose?🙂

I’m still getting this

LinkageError: loader constraint violation

error in previews with dev12 and coroutines 1.3.6 in Android Studio canary 8. Do we need to use a newer version of AS? I’m still on canary 8.

any ideas to animate changes in list order? for example: shuffling a list

Is it possible to achieve such slide animation with compose? https://images.app.goo.gl/KEKPjYqXGwJAKMnB9