Is it possible to declare string resources in a KM...

# multiplatform

[Mark]

Is it possible to declare string resources in a KMP module and access them as @StringRes Int in a Android library module that has the KMP module as a dependency.

I thought this might do it, but no luck so far:

experimentalProperties["android.experimental.kmp.enableAndroidResources"] = true

This is pretty important for incremental migration. Perhaps I could dynamically include the strings.xml of the KMP module in the resources of the Android module?

[Mark]

So it seems the strings.xml can be placed in androidMain and accessed by Android modules in the normal way. For strings.xml in commonMain, those are accessed via Res.string.foo but there seems to be no way to interop between the two?

I’ve got many classes (mostly enums) that have a property of type @StringRes Int so am looking for a good migration strategy. Presumably those should be type StringResource instead.

[Tim Karagosian]

@Mark unfortunately I ended up building my own strings utils class for KMP as I was getting frustrated with the number of times I needed to build for it to pickup my shared resources to use and I have to say, it's much simpler now.

There are some things in this space (due to it being so fresh and new) that just aren't where we expect them to be. Have you looked through any of the libraries available? I feel like there would be something developed to assist with this, but I haven't specifically seen anything yet.

If not, you could always manually do an expect/actual to use more native functions or id references if you explicitly need them. It will be just more code and more work. I know not what you're probably looking for, but it can get you by until something is further developed.

[Mark]

Thanks for that. Did you try Moko Resources? I was hoping that would no longer be necessary now that KMP has Res etc, but it seems not the case. I was hoping that resources could be declared in commonMain, and then there would be a simple way to auto-generate a legacy R class to support legacy Android code interop. My current strategy of adding a android-only module dependency mostly works for now.
https://kotlinlang.slack.com/archives/C3PQML5NU/p1747197830968499

[Tim Karagosian]

That’s sort of how it works with the native shared resources implementation. I haven’t used Moko, so it may be nicer than this. Currently you add your drawable resources, other files, or XML strings and then rebuild. When it completes, then you can access via Res.type.resourceName, example: Res.drawable.rocketimage. Currently it has some support limitations so I would do some research on your file types there for compatibility.

If you need help grind started, this is from Jetbrains https://www.jetbrains.com/help/kotlin-multiplatform-dev/compose-multiplatform-resources.html and if you're still struggling after, lookup a youtube video from philip lackner called "How to Share Resources in KMM (Strings, Images, etc.)" from about 2 years ago that can also fill in a few gaps (I’m not sure how deprecated the info is at this point though). Good luck!

[Mark]

Thanks again. That sounds much better than my workaround because, for me, the android resources are only available in Android land. The idea was that I gradually migrate the resources over to commonMain Res. More realistically, it would mean duplicating resources and gradually removing from android until done. The only Android resources remaining would be those used by androidMain as resource ids. The fact that moko creates Res resources is encouraging since that’s what I want to end up with anyway.