Hmm got an idea how to semi get compose resources ...

# compose

[Joel Denke]

Hmm got an idea how to semi get compose resources being "multi module" supported without having real support for it. Want to check if this is an good idea or not:
• Create a StringsResources interface in my core common module all modules have access to
• Create new sealed interface, for lets say for strings called TextResource
• Having a JetbrainsTextResource implementation data class, refer to interface Resource in my core gradle module all my modules can access.
• Inside my shared module, with DI (In my case Koin) I implement the StringsResources refer to references of TextResource, as I want to support other things other than what Jetbrains support.
• And for each StringsResource I provide a key, like appText key = TextResource(Res.string.appText)
• With DI I inject this implementation
• The bad part, I need to re-inject the implementation in memory back with Koin in my root composable and using like LocalStringResources or such. Its still just references however in code, so maybe fine.
• Also I would need to duplicating jetbrains components resources dependency in core module, which will apply their plugin but not generating any Res for that. As I also will have same in shared module, but there expect it to be generating all Res. This is the case I am uncertain most about.
I am close to having most of this myself anyway now, but thinking about migrate to Jetbrains resources solution for strings to begin with. And it would be possible to interpolate this for fonts, images and such. Like rename StringResources, to like AppResources or such and refer everything in one place. I would ofc prefer to being able call TextResource(Res.string.value) from any module directly instead of duplicating all key references.
What I am uncertain of is the Resource interface itself will be uhm clean over time and always can trust future variants like DrawableResource and such will fulfill this for any type.

[Zoltan Demant]

And for each StringsResource I provide a key, like appText key = TextResource(Res.string.appText)

If I understand you correctly, by this you would do something like val ok = TextResource(Res.string.ok)? If thats the case, I think its a bad idea. Over time it gets very hard to keep these consistent, and you need to declare stuff twice all the time. I did this once and never again 😅

[Joel Denke]

Yes, its because I cannot use shared modules Res generated class yet. Jetbrains will support this I think, but not sure. So yeah I will re-declare keys in my strings.xml file for enum/interface dictionary in my core module. In general I am against the idea myself, but until Jetbrains supporting multi module I was thinking it could be okay to solution.
I need to duplicate this anyway in my own interface solution for resources. I mean I could fork Jetbrains solution and do this myself, but prefer not spend to much time reinvent wheels because I do not have the features I am missing.
Would be like override val ok = TextResource(Res.string.ok) in shared module, and inject the interface in DI level.
And in my actual code i compose it will be like MyText(MyAppTheme.resources.strings.ok) which will call stringResource(MyAppTheme.resources.strings.ok.resource) in my custom MyText composable using TextResource sealed interface for multiple types, like AnnotadedString, String and Android native types partly.

[Joel Denke]

Tried solution, by first let AI migrate all my code to using strings.xml and a new resource interface, was kind of nice get it generated for me as some amount of string references.
It all works fine, expect one thing, previews in androidMain cannot access the values/strings.xml which is used. I guess Jetbrains has some things to support this later on, as I think they working on commonMain Previews as well. Would expect they sync this internally 🙂