Hello hello! I have some issue with text input and auto complete on an Android 6 device:

OutlinedTextField(
            value = viewState.userName ?: "",
            onValueChange = viewModel::updateUserName,
            modifier = Modifier.fillMaxWidth(),
            label = { Text("User name") }
        )

If I check the onValueChange callback, it is actually returning the wrong texts already (so I do not blame my own code behind it) It does look like it has to do with the autocomplete functionality on my other device with Android 8 it works fine

Hey! assuming I have two (Outlined)TextFields, how can I switch focus from the first to the second after

imeActionPerformed

?

What is the best place to browse Compose Samples? I can’t see them on cs.android.com In code I can see following path:

androidx.compose.animation.samples.AnimateContent

where can I find this sample?

Any tips on improving the performance of

LazyColumnFor

? Even when the items are really flat the scrolling feels really jaggy. Is performance something that will be looked before the final release or am I holding it wrong?

Tried to upgrade my project to dev-16 and I’m running into this error:

e: java.lang.IllegalStateException: Symbol for public kotlin/Function3|null[0] is unbound

Are there any known workarounds?

I tried

ViewGroup.setContent

extension inside a

BottomSheetDialog

and it threw this exception

java.lang.IllegalStateException: Composed into the View which doesn't propagate ViewTreeLifecycleOwner!

Is this a known issue?

When is compose going to support this type of slider?

Look behind the toolbar. The first visible item disappears as soon as it goes partially out of the screen

Hey! Is Container composable gone?

Why are there so many Compose artifacts? It's a bit confusing. Is it not possible to put the whole Jetpack Compose library in one artifact?

About image loading:

onCommit(url)

part is causing infinite rendering loop. It’s weird because

url

doesn’t change.

onCommit(1)

or

onCommit("a")

works fine though. The weirdest thing is this is a reusable component, and it doesn’t occur on another screen. Any idea what’s wrong here?

Is a TextField not able to be used in a Dialog? Hitting this after adding characters

is there a scheduled date for dev17? 😬

I set up my code like this, with a viewModel which is platform-independent:

class MainActivity : AppCompatActivity() {

    val viewModel = MyViewModel()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            MyTextComponent(viewModel.state)
        }
    }
}

@Composable
@ExperimentalCoroutinesApi
fun MyTextComponent(stateFlow: StateFlow<DataModel>) {
    val state by stateFlow.collectAsState()
    Text(text = state.mytext)
}

But on configuration changes (e.g. device rotation), the Activity gets destroyed, and so the viewModel. Is it better to tie the viewModel to the App class, or which other strategy do you suggest?

@Adam Powell I’m excited that

onPreCommit

and

onCommit

are being merged! They were pretty confusing.

Is there a way to remove focus and the cursor from a textfield when the keyboard edit is done?

@Composable
    override fun TextFieldWithHint(
        text: String,
        hint: @Composable() () -> Unit,
        onDone: (String) -> Unit,
        backgroundColor: Color,
        textColor : Color,
        fontSize: TextUnit,
        keyboardType: KeyboardType,
        visualTransformation: VisualTransformation,
        cursorColor : Color
    ) {
        val state = state { TextFieldValue(text) } //, textRange) }
        Surface(color = backgroundColor) { //}, border = Border(5.dp, Color.White)) {
            //Row {
            Box(
                modifier = Modifier.fillMaxSize(),
                padding = 10.dp,
                gravity = ContentGravity.CenterStart
            ) { //, padding = 15.dp) {
                Stack(Modifier.weight(1f)) {
                    TextField(
                        //modifier = Modifier.fillMaxSize(),
                        value = state.value,
                        textStyle = TextStyle (
                            color = textColor,
                            fontSize = fontSize
                        ),
                        //textColor = textColor,
                        keyboardType = keyboardType,
                        imeAction = ImeAction.Done,
                        onValueChange = { state.value = it },
                        onImeActionPerformed = {
                            if (it == ImeAction.Done) {
                                //todo remove hack when android fixes it
                                //On older phones the shift key shows up as 00 in the string
                                val char : Char = 0x00.toChar()
                                var str = state.value.text.replace("${char}", "")
                                onDone(str) //.text.substring(state.value.selection))
                                hideKeyboard()
                            }
                        },
                        cursorColor = cursorColor,
                        visualTransformation = visualTransformation
                    )
                    if (state.value.text.isEmpty()) hint()
                }
            }
        }
    }

I'm getting a compilation exception on my project.

e: org.jetbrains.kotlin.codegen.CompilationException: Back-end (JVM) Internal error: Couldn't transform method node:
NewItem (Lkotlin/jvm/functions/Function1;Landroidx/compose/ui/Modifier;Landroidx/compose/runtime/Composer;III)V:

It is hard for me to pinpoint exactly where it goes wrong because the stacktrace is rather large and there are no warnings on Android Studio. I'm sharing a gist which includes the whole stacktrace. https://gist.github.com/halilozercan/303908615b54f1bc29e6355515545018

For the Compose accessibility support, do we have a road map or a timeline in hand?

Will compose attempt to handle navigation, backstack etc -- or will a "screen" framework be needed?

Thinking a bit about the implications of having a codebase that uses Compose with more than one type of

Applier

. Since composable functions carry no compile-time information about which “type of composition” they can be used in, it seems like it would be a real headache, in a large codebase, to try and keep functions for each different composition type separate. And the penalty for getting that wrong could only be, AFAIK, a runtime crash. It seems like it would be very useful for composable functions to effectively include the type of composition they can be used with in their actual type. This would both serve as documentation (“ah,

foo()

is a UI function, and

bar()

is a function for managing a 3D scene graph”), and for the compiler to actually do type checking. I’d be really curious to know what thoughts the Compose team has about this potential issue, and how to mitigate it.

Hello, since I upgraded my project to

0.1.0-dev16

Android Studio can’t seem to generate any preview. Any idea? I’ve checked all versions everywhere, it seems OK. Here’s the error I see in the preview messages:

java.lang.NoSuchMethodError: kotlin.jvm.internal.FunctionReferenceImpl.<init>(ILjava/lang/Object;Ljava/lang/Class;Ljava/lang/String;Ljava/lang/String;I)V
	at androidx.compose.runtime.FrameManager$writeObserver$1.<init>(FrameManager.kt)
	at androidx.compose.runtime.FrameManager.<clinit>(FrameManager.kt:176)
	at androidx.compose.ui.platform.WrapperKt.setContent(Wrapper.kt:201)
	at androidx.compose.ui.platform.WrapperKt.setContent$default(Wrapper.kt:196)
	at androidx.ui.tooling.preview.ComposeViewAdapter.init$ui_tooling_release(ComposeViewAdapter.kt:283)
	at androidx.ui.tooling.preview.ComposeViewAdapter.init(ComposeViewAdapter.kt:352)
	at androidx.ui.tooling.preview.ComposeViewAdapter.<init>(ComposeViewAdapter.kt:138)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at org.jetbrains.android.uipreview.ViewLoader.createNewInstance(ViewLoader.java:399)
	at org.jetbrains.android.uipreview.ViewLoader.loadClass(ViewLoader.java:189)
	at org.jetbrains.android.uipreview.ViewLoader.loadView(ViewLoader.java:147)
	at com.android.tools.idea.rendering.LayoutlibCallbackImpl.loadView(LayoutlibCallbackImpl.java:303)
	at android.view.BridgeInflater.loadCustomView(BridgeInflater.java:417)
	at android.view.BridgeInflater.loadCustomView(BridgeInflater.java:428)
	at android.view.BridgeInflater.createViewFromTag(BridgeInflater.java:332)
	at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:959)
	at android.view.LayoutInflater.inflate(LayoutInflater.java:657)
	at android.view.LayoutInflater.inflate(LayoutInflater.java:499)
	at com.android.layoutlib.bridge.impl.RenderSessionImpl.inflate(RenderSessionImpl.java:347)
	at com.android.layoutlib.bridge.Bridge.createSession(Bridge.java:435)
	at com.android.tools.idea.layoutlib.LayoutLibrary.createSession(LayoutLibrary.java:141)
	at com.android.tools.idea.rendering.RenderTask.createRenderSession(RenderTask.java:705)
	at com.android.tools.idea.rendering.RenderTask.lambda$inflate$6(RenderTask.java:860)
	at com.android.tools.idea.rendering.RenderExecutor$runAsyncActionWithTimeout$2.run(RenderExecutor.kt:170)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

I noticed that inside

ui-material

library

Typography

is a data class which then gets used like this:

internal val TypographyAmbient = staticAmbientOf { Typography() }

I wonder why does it need to be explicitly constructed, why not have an

object Typography

and then

staticAmbientOf { Typography }

? Asking because I'm making my own Typography object (non-material theme) and maybe I'll run into trouble with this.

Is there any friendly way to create a custom view (or a viewholder for an item) with compose in a project using the old fashioned xml style?

@Adam Powell Which of the two is the recommended way of accessing ambients inside composable functions?

1.
val density = DensityAmbient.current
//The code that uses density

2.
Providers(DensityAmbient provides density){
    // The code that use density
}

Where can I read about ambients? I feel like I know so little about them

Are there any recommendations on ways to extend the

ColorPalette

in

ui-material

? For example my app draws a lot of diagrams and they all are styled in additional colors not covered by material spec, both dark/light variants. Currently one can't just add a color to a

ColorPalette

, and then there's an internal

ObservableColorPalette

trick which makes me think that dummily providing additional colors through an ambient might be a performance issue.

I just started reading and experimenting with Compose. So far it looks awesome - thanks to everyone involved in this enormous effort ❤️ As expected, I have a lot of questions 😄 After doing Android development for more than 10 years it's really hard to switch to Compose 😊 1. I've been reading the examples and quite often they use a Composable called

Scaffold

but reading the docs doesn't really explain what it is. Judging by the samples, it looks to be something like a

CoordinatorLayout

, am I right? 2. All the samples I've been reading use hardcoded values for dimensions (using the extension function

Int.dp()

). Haven't read much about Theming yet, but is it possible to define something similar to custom attributes (

attrs.xml

) or dimensions and reference those instead of the hardcoded values? Same for Strings - is there an alternative to

strings.xml

/

plurals.xml

3. Are there any more complex examples of a complete application? I'm about to read and play with Chris Banes' Tivi, as I'd like to see some samples on how to handle large app with many different screens, what are the best practices to integrate Composables with ViewModel... 4. And last one for the time being - so far I haven't seen/read anything about handling configuration changes (the most common one being screen rotation). In Activity's world we have

onSaveInstanceState()

- is there an alternative in Compose (other than ViewModel's SaveState)?

As a beginner I had a resource-loading related thought today. Many built-in composables accept either

ImageAsset

or

VectorAsset

(for example

Icon

). And this is done using overloads. So if my composable has

Icon

as a child and I want to make the asset which I pass to it configurable, I have to introduce 2 overloads too. And this repeats up and up. The thought was: if

ImageAsset

and

VectorAsset

had some comon supertype this would be easier. For example some kind of

sealed class Resource { class ImageAsset; class VectorAsset }

. I suspect that current state of affairs had some reasoning behind it, does anyone know more?

Is there a way to get a screenshot of a specific Composable as a Bitmap or any other file?