Kotlin Multiplatform support #554
Replies: 4 comments 5 replies
-
Why not create a module that uses both |
Beta Was this translation helpful? Give feedback.
-
I think it’s worth switching completely to Kotlinx.datetime has a convenient translation API to Java.datetime and back to the jvm target. You will get two options for Android calendar:compose:0.0.0 with Java.datetime and calendar:compose-multiplatform:0.0.0 with kotlinx.datetime |
Beta Was this translation helpful? Give feedback.
-
Published the first alpha for the multiplatform artifact today, it has the same API as the existing compose calendar, so the existing compose documentation should be sufficient to get started. Note that this is based on compose UI 1.7.0-beta03. commonMain.dependencies {
implementation("com.kizitonwose.calendar:compose-multiplatform:2.6.0-alpha02")
} Examples can be viewed online at: https://calendar.kizitonwose.dev, the source code is available in the multiplatform branch. |
Beta Was this translation helpful? Give feedback.
-
The multiplatform library code is now merged into the main branch in #561, this discussion will therefore be closed. |
Beta Was this translation helpful? Give feedback.
-
Edit: Kotlin multiplatform calendar library alpha release is now available.
Over the weekend, I had some time to investigate what is needed to add multiplatform support to the library, seeing that some users have requested it over the past few months. I was able to get a rough example of the existing compose
Example1Page
up and running. Screenshots from the desktop app and browser are shown below, next to theExample1Page
from the Android sample app. This iOS sample app also works, but I moved a bunch of source files around which broke the compilation and I did not want to spend time fixing it just for the demo.I have some thoughts on how to approach this, please feel free to chime in.
The library presently has support for the view system, and that is not going away. The current compose artifact is also not going away either as together with the view system library, they use the
java.time
APIs and I intend to keep them that way. Thekotlinx-datetime
library has come a long way, but it is not yet at the same level as thejava.time
APIs, so I do not want to force the library users to use thekotlinx-datetime
library, especially on pure Android projects without multiplatform setup.I am considering publishing the multiplatform library which will use the
kotlinx-datetime
library under a different module name, likecom.kizitonwose.calendar:compose-multiplatform
, so the Androidview
andcompose
libraries using thejava.time
APIs will keep existing in their modulescom.kizitonwose.calendar:view
andcom.kizitonwose.calendar:compose
respectively, but this means duplicating a lot of compose code, so I am still thinking about the right approach and open to suggestions.Regarding the timeline for when this could be out, at least in alpha, I can't give anything specific right now, but given my current schedule, maybe in 2-ish months.
I kindly ask you to refrain from posting comments solely asking about the release date, as such comments do not add any value.
Beta Was this translation helpful? Give feedback.
All reactions