I am migrating an existing view, planning to do A/B test activtiy for XML and Compose, In one of th...

# compose

[Djaka Pradana Jaya Priambudi]

I am migrating an existing view, planning to do A/B test activtiy for XML and Compose,

In one of the composable, I am using interopability API to render android view in compose, it's a very complex view. The android view had a recyclerview on it (but it's not recycling, it's expected).

The problem is, when I render that view with same inputs, somehow inside the AndroidView it's bugged, some recyclerview item occupy fullscreen causing lot of blank spaces, but if I run it in XML the problem doesn't happen.

Does anyone know any clues how can this possibly happened?

XML
LinearLayout
- LinearLayout
- CustomViewThatVeryComplex -> render correctly

Compose
Column
- Column
- AndroidView
-- CustomViewThatVeryComplex -> render incorrectly

[Djaka Pradana Jaya Priambudi]

I've been debuging this for few days now, still no clue how can this happen

I can't make small reproducable repo because I don't what causing this wrong calculation and it's impossible to duplicate the entire view to another repo because it's super complex

I want a little bit of light in this darkness....a little bit of guess on why this can happen would be really helpful

[Djaka Pradana Jaya Priambudi]

Constructoin view logic:

val widget = remember(param) {
        foo.createWidget(context, param)
    } 
AndroidView(
        factory = {
            widget.getView()
        },
        modifier
    )

[chanjungskim]

I think using AndroidView is kind of meaningless if you still use XML.

[Djaka Pradana Jaya Priambudi]

I'm not just using xml, the entire activity is in compose except for that complex widget (since it's impossible to migrate for now)

I had two activtiy doing the same thing, one made with XML and other is Compose

The bug only happen in compose

[chanjungskim]

Yeah, So, better not to migrate until you have enough time to migrate.

[Djaka Pradana Jaya Priambudi]

thats not an option, the app is so big, if we didn't migrate partially we will need months or years of no feature development

[chanjungskim]

Hmm. I don't know how big it is but fully migrating can be the fastest solution..

[Sean Proctor]

Maybe you should start with migrating the very complex component. I haven't used AndroidView much, I've noticed it's a bit quirky. If you're planning to eventually do the migration, it might be faster to just do that instead of figuring out why your current widget is not rendering properly.

[chanjungskim]

One idea I come up with is, If you can set the initial size of the space, maybe set it to 0 or small value. This might needs some change in XML version.

[Djaka Pradana Jaya Priambudi]

@Sean Proctor yeah that possible, but it would mean to delay compose adoption to next year, I want to avoid those if possible by utilizing the interopability API

@chanjungskim what do you mean set initial size? initial size of the each recyclerview item?

[chanjungskim]

The spaces

[chanjungskim]

You will need to explain more about the view for the exact solution.

[Sean Proctor]

I don't think it takes as long as you think to migrate something to compose. I migrated a fairly large app a couple of years ago in 2 months. It's 35 screens now, it wasn't quite that many at the time.