I'm always a little surprised when I see people us...

# compose

[jim]

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 😛 😉🤣

[John O'Reilly]

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?

[Timo Drick]

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

[judrummer]

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

[judrummer]

In my case. I need to use this PinView Library
https://github.com/ChaosLeung/PinView

[jim]

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.

[judrummer]

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

[jim]

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.

[jim]

There is an inherent impedance mismatch when crossing between declarative and imperative APIs. The intent was that people would deal with that impedance mismatch within a tightly-scoped composable that encapsulates/hides the ugly details, and would provide only an idiomatic declarative API to callers.

[judrummer]

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

[judrummer]

I try to reproduce more . it’s happens on some device , keyboard

[jim]

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.

[judrummer]

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

[jim]

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

[judrummer]

👍

[Zach Klippenstein (he/him) [MOD]]

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.

[Colton Idle]

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.

[Adam Powell]

@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

[jim]

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

[jim]

I haven't seen it on any roadmaps, and we don't have the domain specific expertise (maps) to vend such a complex widget on behalf of another team. It would at the very least need the participation of that team for us to create an official API. I think it would likely happen eventually, but in the mean time, feel free to let that team know you want it and feel free to share your own wrapper on github.

[pawegio]

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

[Adam Powell]

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

[kenkyee]

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

[Colton Idle]

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