A modern programming language that makes developers happier.

kotlinlang

Passing `Resources` into a composable as a parameter?

:thumbsup: or :thumbsdown:

In this case, I have a composable that is putting three `Image`s next to each other + a piece of text. Image takes a `bitmap = imageFromResource(resources, R.drawable.image1)`

Which is weird since the same composable also has Text() with `text = stringResource(id = R.string.mystring)`

So really only images require a Resource

If that's just the android framework `Resources` object I wouldn't bother over just doing `AmbientContext.current.resources` where you need it. The benefits you'd usually get from making it a parameter can't really materialize since both Context and Resources objects in Android are so weird and tied to requirements that the system gives you one and you can't meaningfully construct your own to alter behavior like other dependencies

If this is your own resources type that gives you a different abstraction over what you need, the answer changes

One thing some teams at Google are finding is that there's a measurable performance difference between doing one off resource loads from the simple compose loading functions vs the batch `context.obtainStyledAttributes` calls that views perform at construction. The batch operations have less overhead

In most cases it's fine but it's a question of how it scales

So if you had a type specific to your app that performed the batch load instead, you'd get a bit of a perf bump on the whole and a more compose friendly dependency to work with

All of these things are things we'd like to explore further for compose android APIs, but some of the things we'd like to do would be better accomplished in closer collaboration with the aapt and resource tooling in the long run, so some of the existing APIs are of the, "simplest thing that can work" variety, leaving the door open to more in the future

&gt;  If that's just the android framework `Resources` object I wouldn't bother over just doing
Yep. It's just the android framework Resources

I'm going to give AmbientContext.current.resources a shot.
I was trying to only pass in Resources because I was trying to write a unit test for this simple composable that basically just displays a string + some images, but thought that surfacing the Resources as a param would be best.

I would move to create a slot (lambda) to create the Image in a way they want

Yeah. I 've thought about that, but at this point this is almost to the point where this entire composable is like a ContactUsScreen composable. So the screen is crazy simple and I just want the composable to be able to set everything up itself. but maybe Im over thinking it for now and I should just ship it. :smile:

Adam Powells answer of using the Ambient makes sense for now.