I'm always a little surprised when I see people using

AndroidView

directly in their apps, and maybe it's because we made the API too pleasant to use or maybe it's because we never really communicated the intent to the community. 🤷. Certainly I never expected to see people remembering the view and then just referencing that view in the

viewBlock

, I suppose no API survives first encounter with the user. Composables are epitomized by their convenient declarative APIs. The older android Views often have imperative APIs with sometimes surprising semantics that need to be papered over, and this wallpaper isn't always straight forward to get right. The intent/expectation was that users would write a composable function who's sole purpose was to wrap a particular Android View, and would provide this wallpaper, such that the widget was pleasant to use in the rest of their application. Maybe we need to make AndroidView have some more boilerplate and look uglier 😛 😉🤣

Main (and I think only) reason I use it for right now is including Google Map in an app.....don't think there's any other way of doing that right now?

But keep in mind that there still many things missing in compose

So if I want to use some 3rdParty EditText library, Do I need to rewrite it as Composable widget?

Sorry, I did not mean to suggest that there is no place for AndroidView in the hierarchy. I just meant that using the API directly was not the intent. The intent was that people would wrap them with a composable before using them.

But I try with simple EditText. The issue still happen. Can you suggest solution? 😢

I would not expect

AndroidView

to ever have any siblings within a given widget. I would expect it to ALWAYS be of the form:

@Composable
fun EditText(text: String, onChange: (newValue: String)->Unit, ...) {
    AndroidView(
        viewBlock={
           android.widget.EditText(context)
            .apply {
                layoutParams = ViewGroup.LayoutParams(MATCH_PARENT, WRAP_CONTENT)
            }
        },
        editBlock={
            // Deal with logic to add/remove change listeners, etc.
        }
    )
}

Now EditText looks like a composable function and has a declarative API, hiding the details of adding/updating change listeners, etc. It now provides an API that makes it look much more like a native composable.

Thanks, It’s help code to be look better but my issue about backspace still remaining

Yeah, that's why I made this a separate thread instead of clogging up the thread where you asked your question. Sorry to hear about the backspace thing, not sure what's goign on there.

I can reproduce in this case Pixel2XL Android11 -> Keyboard ManMan But in below list. It’s work fine Pixel2XL Android11 -> GKeyboard Oneplus7t Pro Android10 -> Keyboard ManMan Oneplus7t Pro Android10 -> GKeyboard

You should probably add that information (and create a bug & link it) to your original question so it doesn't get lost.

👍

We use a framework that tries to force you to work with Android views in a declarative way, and yea, we have been bitten many times by weird little surprises everywhere. All our interop between Android views and compose is expected to happen at very well defined, explicit boundaries and I think we’ll probably try pretty hard to discourage any other integration. So whatever this api ends up being, we only need to wrap it in one place. I think the AndroidView api makes sense and pretty elegant, but I would probably be excited if you decided to make it higher-friction if that extra friction also made it harder to use incorrectly and helped reduce potential bugs. It would actually make my job easier.

I'm thinking of writing a custom lint rule to prevent my team from using an AndroidView directly and guide them towards creating a wrapper composable.

@jim I'm pretty sure we have that remember+AndroidView usage in at least one of our sample apps; @nickbutcher we should revisit those, those sample usages probably date back to an older version of the AndroidView API with a different shape

I believe the google maps issue tracker is here: issuetracker.google.com/issues/new?component=188870&template=788712 . 😂😆

I use it just to wrap GLSurfaceView (for ARCore). Am I justified? 😄

We'll be working with the other various SDK teams at Google over time for further compose support, same as we've worked with them to support the view system

+1 to the lint rule...is this even possible though? How would you be able recognize idiomatic vs. abusive? 🙂

I don't know... but I can try!