Can I render a

@Composable

outside of

setContent {}

so that I could get the size of one child

Composable

within? I don’t care doing that in the UI thread right now, just want to know if it’s possible!

You may want to make a layout where you can measure that child directly and get its size?

Thanks I’ll have a look at that

Hmm, I don’t think you can get this sort of data outside of the “setContent” (which gets you a @Composable context), afaik you need to be inside that context at least. I know we’re getting a notion of “composable as a value” soon in the new alphas, but I don’t think even that provides the size of the composable for example. The only way I have successfully worked with doing such things have been with

layout{}

and doing everything inside that block. One term I’ve heard thrown around in this slack has been “SubComposition” which I don’t know what it is but maybe this potentially helps solve your problem in some way? And another less optimal way I’ve seen people do something like this has been by laying it out normally and using

onGloballyPositioned

to get data about it’s place/size? If none of the above, I am not quite sure myself, maybe someone else might have another idea. Or maybe you should reconsider what you’re trying to achieve and go about it with a different approach?

I’m trying to know what the size of an image will be on screen to prefetch an image in advance so when it will be effectively shown on the screen, the image of the right size will be waiting in the in-memory cache of images

Modifier.onSizeChanged

is likely to be an efficient answer to what you're trying to do here. Alternatively, we've worked with the Coil library authors to help with this case in the past as well, that might be an easy drop-in solution

@Adam Powell Thanks for the info! I’m doing the following, but I don’t think the composition is running, any idea why?

var imageSize: IntSize? = null
                ComposeView(context).apply {
                    compositionContext = Recomposer(<http://Dispatchers.IO|Dispatchers.IO>)
                    setContent {
                        HouzzTheme {
                            AdItem(ad = safeAd) { imageSize = it }
                        }
                    }
                    measure(ViewMeasureUtils.exact(width), ViewMeasureUtils.exact(height))
                    layout(0, 0, width, width)
                }
                delay(5000)
                logger().d("HomeFeedComposedAdFetcher", "ImageSize = $imageSize")

Several, but I'm more interested in why you're creating a whole recomposer and ComposeView to get the measurement of a single layout element to load an image 🙂

The idea here is to load the image to be ready in memory in a cache at the exact size its view will have so there’s no loading time for those images in ads when the user scrolls the screen

what are you using to determine what size its view will have?

That’s a good point. At first I tried passing to the ViewModel the IntSize the

LazyColumn

would get in its

onSizeChanged

modifier:

).onSizeChanged {
     homeFeedViewModel.screenSize = it
}

Ugly, I know, but I have to make this work at any price. I thought this was working but got lots of

null

at the time I am trying to run the snippet above, so I just used constants to go forward for now:

val width = 1080
val height = 2400

Not pretty as well, I agree….

It won't recompose unless you call

runRecomposeAndApplyChanges

on the recomposer, but I still think this is overkill for the problem space. If you know what the size of your container is in your main composition there should be no need for this parallel universe

The issue is that indeed I do not know the size of the image, and there’s no way to get that size before being rendered in its LazyColumn, right? The image in the old UI ToolKit is setup inside another layout, with 3 hierarchies, like this:

<com.company.app.views.MyImageView
    android:id="@+id/image"
    style="@style/image_bg_gray"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"/>

So the width depends on the parent layout which has a parent layout which has another parent layout. I’ve made the equivalent in Compose like this:

CustomImage(
    placeHolder = defaultPlaceholder(),
    imageDescriptor = someData.imageDescriptor(), // image descriptor is url + enum for a size
    modifier = Modifier
        .fillMaxWidth()
        .onSizeChanged {
            onImageSizeChanged?.invoke(it)        
    }
)

I think you’re getting my point, I can’t just say “its the width of the list minus 4 dp for margins and that’ll be the final size…” I wish! Nothing here would beat getting it calculated by the view itself, and using that exact size to prefetch that image way in advance, when the data is loaded, to be ready for the image to show itself directly when the user scrolls. Let’s be clear here, I also think it’s overkill but that’s the requirement set up for this, sadly.

this may or may not have other side effects for what you're doing but it might be worth trying since it's small and a lot less complex/overhead:

fun Modifier.invisible() = layout { measurable, constraints ->
    val placeable = measurable.measure(constraints)
    layout(placeable.width, placeable.height) {
        // Do not place
    }
}

@Adam Powell Thank you so much for your input! 🤯 Yes it’s a workaround and it would be amazing to have an API to calculate sizes or even render of Composables offscreen (thinking about taking view screenshots), or as you mentioned some control on items before showing them in

LazyColumn

. Using your snippet I’ve come to build it in a modifier, which I think looks quite good:

fun Modifier.prefetchAdsImages(
    scope: CoroutineScope,
    ads: List<Ad>,
) = composed {
    // remember the types of Ads we already calculated the size to not recompose that again
    val composedAdTypes by remember { mutableStateOf(mutableListOf<AdType>()) }
    // run on all the ads
    ads.forEach { ad ->
        // only when not already composed we'll compose
        if (!composedAdTypes.contains(ad.Type)) {
            composedAdTypes.add(ad.Type)
            // setup a basic layout to be able to calculate the size of the image inside the adItem
            Box(modifier = Modifier.fillMaxSize()) {
                LazyColumn(modifier = Modifier.fillMaxSize()) {
                    items(listOf(ad)) { item ->
                        AdItem(
                            ad = item,
                            imageModifier = Modifier
                                .onSizeSet { size ->
                                    scope.launchOnBackground {
                                        AndroidCore
                                            .services()
                                            .imageLoaderTaskManager()
                                            .prefetch(ad.AdSpace.image1Descriptor(), size.width, size.height, false, null)
                                    }
                                }
                        )
                    }
                }
            }
        }
    }
    this
}

onSizeSet {}

is just a modifier to not get a size change twice

fun Modifier.onSizeSet(
    onSizeSet: (IntSize) -> Unit
) = composed {
    var isSet by remember { mutableStateOf(false) }
    return@composed onSizeChanged {
        if (!isSet && it.width > 0 && it.height > 0) {
            isSet = true
            onSizeSet(it)
        }
    }
}

What do you think? Maybe there’s a perf issue with this that I don’t see yet?

Haven’t read everything you posted, but as a nit in your code snippet regarding this:

val composedAdTypes by remember { mutableStateOf(mutableListOf<AdType>()) }

it may not be doing what you want it to. Please read this article, to see why.

Avoid emitting UI in a

Modifier.composed

- the behavior of this will not be what you want and is more or less undefined. We'll likely use the new applier inference feature to make the snippet above a compiler error. Using a

LazyColumn

in your speculative layout will have the same issues you're facing in your original problem - things that don't fit won't be composed because the layout is lazy.

Hmmm I see, thanks

https://android-review.googlesource.com/c/platform/frameworks/support/+/1772992 is the change that was merged, the commit message has some of the description, as well as the docs on the ComposableTarget annotation: https://android-review.googlesource.com/c/platform/frameworks/support/+/1772992/23/compose/r[…]n/kotlin/androidx/compose/runtime/ComposableTarget.kt