Wow waited so long for this release 😄. The imageviewer demo show how to handle images in Android and Desktop. But it completely doubles the UI code for Android and Desktop. Are there any plans to introduce some platform independent resource handling? So you could write the UI once and use it in Android and Desktop. Or maybe at least write components that are platform independent. Maybe a library which loads images from streams and outputs an ImageAsset that will be decoded to DesktopImageAsset or AndroidImageAsset. So you only need to handle ImageAsset which is Platform independent.

This is definitely something we want to provide long term, but we are ruthlessly prioritizing for the Compose 1.0 release, and since this is solvable in user land, so it might not be available in the short term. In the mean time, we encourage the community to experiment in this space. Kotlin is great because it supports

expect

and

actual

, which you can use to implement your own unified resource system that calls the corresponding APIs on Android and Desktop. You can use your custom unified resource API in your own widgets, or share the API as a library for others to use in their widgets.

Ok thanks. I will work on this in the next days and will share my results. I do have implemented a small image cacheing and loading system for android compose. I will try to port it to compose-desktop.

@jim is it planned to change the package name so common sourcecode has no references to androidx or android?

There are currently no plans to change the package name but we are continuing to monitor community sentiment.

I think can be strange to know what is common and what is android if the package name is androidx. I think more people is thinking this too and it doesn't fit very well in a Multiplatform vision. I don't know exactly what name can have, now: - Google android version is named Jetpack Compose (including the common source code maintained by Google and JetBrains). - JetBrains compose for desktop based on JVM (I don't know if Google maintains this too). Meanwhile package names are mixed including all androidx but no Jetpack, Google or JetBrains. Maybe having a common suffix for the product (Jetpack Compose?) and a different suffix for each implementation (Google Compose or Android Compose for Google/Android projects and JetBrains Compose or JVM Compose for JVM/JetBrains project) could indicate the artifact naming too.