In compose 1.6.0 beta 1 we have a new Gradle resou...

# compose

[Joel Denke]

In compose 1.6.0 beta 1 we have a new Gradle resource plugin:
https://github.com/JetBrains/compose-multiplatform/pull/3961
Trying to follow code but I dont follow. The generated Res class, is it possible to use that multi Gradle module? In similar way in Android R class thing.
In my case reference same Res without using shared module. Because need have smaller modules that shared depends on, where I also want to use Res. That includes ideally having compose preview work in Android.

[Ivan Matkov]

https://kotlinlang.slack.com/archives/C0346LWVBJ4/p1705052701059339?thread_ts=1705044569.082869&cid=C0346LWVBJ4

[Joel Denke]

Thanks! 🙂 So ok still cant use this plugin properly in multiplatform manner. I have so many hacks around this already, cant hurt adding more.
I hope Jetbrains could add better sample demo show how to use this in multiplatform across multiple modules 🙂

For now as explained in thread, I guess go for a full blown enum in my core module reference to the generated references in shared 😛 Or refer directly to the painterResource, stringResource etc, but I guess those enforce Res class to be used now?

[Ivan Matkov]

cc @Konstantin Tskhovrebov

[Ivan Matkov]

I hope Jetbrains could add better sample demo show how to use this in multiplatform

Docs are on the way, it will be ready by 1.6 release

[Joel Denke]

We had another thread about similar topic, but was from API 1.5.11 release we discussed. For now I can stick with the 1.5.11 release.
But really would like to know how the resources is loaded on each target and how to make same myself.
Thats another API change I suggested, to be able to fetch the path on a resource and not only the ByteArray.
As I need to support more file types than this plugin does 🙂

[Joel Denke]

And I prefer not having multiple resource class implementations if possible .P

[Joel Denke]

Right now I have ImageResource, TextResource, VideoResource and Resource(Jetbrains variants implement it) to support more types not yet supported by regular COmpose variants, to have custom COmposables and other frameworks. Such as video, audio, svg, gif etc.

[Joel Denke]

@Ivan Matkov On same topic btw, is there any kind of OTA or roadmap placeholders, similar like Kotlin releases for Compose multiplatform?
Like expected to release each quarter with this backlog or anything. At moment have no idea progress of anything, and feels like we always waiting on Google to release stable variants of androidx compose libs? I heard Jetbrains will take over androidx compose compiler at least.

[Ivan Matkov]

is there any kind of OTA or roadmap placeholders, similar like Kotlin releases for Compose multiplatform?

as far as I remember we had to publish it somewhere.. I'll find it a bit later

we always waiting on Google to release stable variants of androidx compose libs?

No, it's why (to avoid waiting) we did 1.5.10 feature release

[Joel Denke]

I know about https://blog.jetbrains.com/kotlin/2023/11/kotlin-multiplatform-development-roadmap-for-2024/ but a more general release schedule or something. Expecting to release lets say each quarter and align with androidx libs 🙂

[Ivan Matkov]

It's probably that, yes.

Expecting to release lets say each quarter and align with androidx libs 🙂

It's already like so, isn't it?

[Joel Denke]

@Ivan Matkov

No, it's why (to avoid waiting) we did 1.5.10 feature release

Yeah I remember that Accompanist did similar, but split the versions and try align version names with same Google using, to avoid confusion. To have both alpha, beta and stable releases aligned.
But it feels more and more need to move out so compose multiplatform and androidx compose is in the same repo or same owners or shared ownership. Making it painful also to align with Kotlin versions and compilers.

[Joel Denke]

It's already like so, isn't it?

Havent read so, as of example 1.5 was released in august 2023. Would then if per quarter expect next to be 1.6 in november 2023 and 1.7 in february 2024?

[Ivan Matkov]

try align version names with same Google using

1.6 -> 1.5.10
1.7 -> 1.6

[Joel Denke]

I dont mind its different each release, but missing public information to know whats going on, which APIs working on and some kind pf planning, to know ah I can wait refactor my code as this feature releasing, or avoid build this myself as will be added later on etc 🙂 But also not to much waiting, as then cannot give feedback what needed 😄

[Joel Denke]

Anyway thanks! 🙂 Will keep a look out for these new resource API changes and pray it will work in large scale apps with many gradle modules.

[Sean Proctor]

There's already moko resources that does a pretty similar thing. It supports multi-module projects. If you're using kotlin 1.9, make sure to use the 0.24 alphas, if you decide to try it.