jim

    jim

    1 year ago
    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

    John O'Reilly

    1 year ago
    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

    Timo Drick

    1 year ago
    But keep in mind that there still many things missing in compose
    j

    judrummer

    1 year ago
    So if I want to use some 3rdParty EditText library, Do I need to rewrite it as Composable widget?
    In my case. I need to use this PinView Libraryhttps://github.com/ChaosLeung/PinView
    jim

    jim

    1 year ago
    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.
    j

    judrummer

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

    jim

    1 year ago
    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.
    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.
    j

    judrummer

    1 year ago
    Thanks, It’s help code to be look better but my issue about backspace still remaining
    I try to reproduce more . it’s happens on some device , keyboard
    jim

    jim

    1 year ago
    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.
    j

    judrummer

    1 year ago
    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

    jim

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

    judrummer

    1 year ago
    👍
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    1 year ago
    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

    Colton Idle

    1 year ago
    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

    Adam Powell

    1 year ago
    @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

    jim

    1 year ago
    I believe the google maps issue tracker is here: issuetracker.google.com/issues/new?component=188870&template=788712 . 😂😆
    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

    pawegio

    1 year ago
    I use it just to wrap GLSurfaceView (for ARCore). Am I justified? 😄
    Adam Powell

    Adam Powell

    1 year ago
    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

    kenkyee

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

    Colton Idle

    1 year ago
    I don't know... but I can try!