:compose-multiplatform: <https://github.com/JetBra...

# compose

[Daria Voronina [JB]]

K Compose Multiplatform 1.6.0-beta01 is now available! K

This release is based on Jetpack Compose 1.6-rc01 and brings enhancements for many framework capabilities. Here are some of the highlights:

🌟 The experimental resources library has received a number of major improvements, including:
- Compile-time checking of resources through a generated Res class.
- New support for font and string resources.
- Support for various screen densities, multiple languages and regions, and light and dark themes.
🌟 Experimental support is available for tests in common code.
🌟 Compose Multiplatform for Web artifacts are now available in Maven Central.
🌟 The TextField component now exhibits more native caret behavior on iOS with a single or long tap.
🌟 Support for text trimming with the LineHeightStyle.Trim parameter is available.
🌟 System fonts can be loaded by name on desktop and web platforms.

kodee walking Learn about other improvements in this release and update to 1.6.0-beta01 for a better developer experience! ⤵️

[Garret Yoder]

Were you able to get the Res object to generate? I tried updating one of my projects and the Res object never generated, so Im not sure if theres a gradle task im missing for it.

[Garret Yoder]

the other interesting thing is its not telling me that I need to mark the resources dependency as optin for experimental

[Garret Yoder]

Hmm. I did the same and still no dice.

[Garret Yoder]

Huh, I just got it to work. No idea what I did beyond refreshing the gradle project for the 4th or 5th time.

[Todd]

Does the generation happen during sync? I assume you have to build first

[Konstantin Tskhovrebov]

to generate the Res file you are supposed to reimport a project

[Garret Yoder]

Thanks, that makes more sense. I was able to reproduce and then get it to work again by doing a cache invalidate, then a build clean, then a resync

[Garret Yoder]

Is there any mention of when this will get merged into multiplatform? https://issuetracker.google.com/issues/320819734

This is crashing a handful of libraries that haven't updated yet. Looks like upstream already patched it

[Ivan Matkov]

already - https://github.com/JetBrains/compose-multiplatform-core/pull/1015

[Garret Yoder]

Wow, that was fast. I assume that it'll get pushed w/ the next dev build today or monday? since beta01 was the most recent and it's obviously present there

[Ivan Matkov]

it'll get pushed w/ the next dev build

yes

today or monday

ci is scheduled at night between monday and tuesday

[Garret Yoder]

Awesome, thanks!

[Garret Yoder]

Unfortunately it looks like 1.6.0-dev1397 didn't fix this yet

[Ivan Matkov]

сс @Igor Demin

[Igor Demin]

Apologies, we didn't complete the merge yet. This completes it.

As a workaround, you can include the 1.6.0 version yourself:

androidMain {
    implementation("androidx.compose.foundation:foundation:1.6.0")
}

[Garret Yoder]

Wouldn't that only solve the issue on android though, since the build targets for jvm/ios wouldn't exist?

I've subbed to that PR though so I'll wait for the next dev build after that gets merged. Thanks!

[Igor Demin]

Does it happen on iOS/desktop in 1.6.0-dev1397?

[Garret Yoder]

I haven't tested iOS but it happens on desktop yeah. Let me do an ios build quick

[Igor Demin]

ios/desktop/web should already contain Jetpack Compose 1.6.0 fixes in 1.6.0-dev1397.

If it still happens - it means it is a different issue, or some weird platform difference.

[Garret Yoder]

Not happening on iOS interestingly, but is still happening on JVM

[Garret Yoder]

Just confirmed on android too, both android and JVM are still getting the java.lang.NoSuchMethodError: No virtual method getTextAlign-buA522U() error, only iOS seems unaffected.

[Igor Demin]

Do you have any public project with the issue we can look at?

[Garret Yoder]

I don't, but I can make a minimum reproducible sample if it helps. Give me about 20 minutes and I'll upload something

[Garret Yoder]

I've been encountering the issue specifically with https://github.com/MohamedRejeb/Compose-Rich-Editor since this only affects using libraries that haven't been updated yet

[Garret Yoder]

Sorry this took so long, I spent the last couple hours debugging some wild inconsistent behavior before I figured this out. I'd have it reproducing, and then I'd clean the project up to publish and it'd start working. So it took me a bit to figure out it was a combination of two libraries. I was going line by line through the gradle files adding stuff back to see what the culprit was.

https://github.com/garretyoder/ReproduceSample

So it seems like it's not the exact same issue, but it's tangentially related and produces the same outcome. This only happens when two specific libraries are used together - though I'm sure theres far more combinations based on the methods they call.

[Garret Yoder]

It seems like it's still related to the backwards compat for that method though, as it produces the exact same error output and behavior for the exact same method. I'm assuming some method naming is still conflicting.

[Igor Demin]

https://github.com/garretyoder/ReproduceSample

This is because some library already uses 1.6.0-beta01.
And when you use 1.6.0-dev1397, Gradle chooses 1.6.0-beta01 instead.

To check that everything is fixed, you can force this version:

configurations.all {
    resolutionStrategy.eachDependency {
        if (
            requested.group.startsWith("org.jetbrains.compose.runtime") ||
            requested.group.startsWith("org.jetbrains.compose.ui") ||
            requested.group.startsWith("org.jetbrains.compose.foundation") ||
            requested.group.startsWith("org.jetbrains.compose.material") ||
            requested.group.startsWith("org.jetbrains.compose.material3")
        ) {
            useVersion("1.6.0-dev1397")
        }
    }
}

[Garret Yoder]

Yup that was it, and that makes sense. Thats interesting behavior from gradle, I thought it'd always choose whatever the newest version was. Either way, thanks a ton!

[Marco Pierucci]

What's the reasoning of having the generated Res class internal? I'm sure there is a really good one which am too dumb to see but if the file wasn't internal couldn't we just define all our resources in a core module and use it in a multi module project?

[Konstantin Tskhovrebov]

https://github.com/JetBrains/compose-multiplatform/issues/4327#issuecomment-1964492518

[Javier]

@Konstantin Tskhovrebov I think the main issue here is almost all companies use something like lokalize, and that means having only module for resources and rest of modules depend on it.

I think the use case of generating a public API should be interesting for a lot of people.

[Marco Pierucci]

It also means that multi module app cant start adopting composeResources yet?
Yes I know that multi module work is on the pipeline but maybe exposing the generated class would allow early adopters to integrate the library?

[Marco Pierucci]

(That or the POC im going for which is exposing every resource from the core module which obviously does not scales )

[Konstantin Tskhovrebov]

move the discussion to the github, please