Open StefanOltmann opened 3 years ago
This is something which I've been looking into over the past couple of weeks and would definitely love to support. I've been a bit busy doing some other projects and adding automated tests for this library but I'll probably start working on this sometime next week. I'll probably do something similar to what you mentioned about the android specific stuff and then should just be able to put the rest of the code into common section. I was also thinking of providing desktop specific implementations for the date and time pickers as the Material spec gives a slightly extended design for them when displaying on wider screens.
Just a little update on this topic both for anyone interested and for myself to refer back to. I've done some work on the stuff mentioned and have currently got a working template for the module structure for the library with common, android and desktop targets for each module. I've had a look into the Dialog
API for both Android and desktop versions and it looks like there are some minor differences in the parameters that they take. I think it should be possible to make an expect
dialog composable in the common module and add their actual
implementations for them in the android and desktop modules. As far as I could tell except for this the rest of the code can just be copied pasted into the respective common modules as it shouldn't be dependent on any platform specific composables (except for a couple of functions which have android specific stuff mentioned above).
While setting up the new project I also realised that the compose android dependency is a Jetbrains built one and not the same as the one supplied by Google. I found some discussions on the compose-desktop slack channel about unifying the dependencies but this very much seems like something which will be introduced farther down the line. Unfortunately this does mean that I'm going to have to make separate releases for the Google/Android specific build and a Jetbrains multi-platform build. I'll create a branch in the next week or so with the stuff I've done so far so that anyone who is interested can keep an eye on it.
When is this happening , If you'd like some help , I can try to convert them for you to kotlin multiplatform and make a pull request if I succeed
@wakaztahir I'm extremely busy at the moment so feel free to pick this up and submit a pull request. I already got started on this in the compose-jb
branch if I remember correctly but that will probably be quite outdated at this point. Good luck and let me know if you have any questions.
Hi @vanpra , So I have made the modules but still I need to make LocalDate and LocalTime multiplatform I have tried my best to not avoid introducing any breaking changes.
https://github.com/timeline-notes/compose-material-dialogs/tree/multiplatform
Here's the list of changes on Android
stringResource()
I have changed all the entries , I will slowly convert those entries to stringResource
function in the demo android module
That's all the changes in the api
Bugs :
TODO :
Thanks for working on this. I'll try and take a look at it over the next couple weeks.
I did my own port of Compose Material Dialogs to Compose Multiplatform https://github.com/Syer10/compose-material-dialogs Feel free to take from it as well.
I have ported version 0.20.0 of Accompanist to Compose Multiplatform(future versions are blocked because of the Snapper library) and use it in this port.
I only care for Jvm variants so I didnt use other multiplatform things like porting LocalDate to Kotlin.
I did use some stuff from @wakaztahir's fork because he did do some heavy lifting that I felt was worth it.
I havent tested anything yet, its a straght port that I will be using in my Desktop/to-be-android application, so hopefully nothing is broken.
have you published accompanist , I would like to use it...
Yep, just click one of the links in the readme and it will show you the implementation instructions
I cannot access any class in the library in my commonMain , I can access them in Android & in my jvm but not in my commonMain
Currently my Accompanist and material dialog forks use a shared Jvm main, so nothing is exposed to common. My application does the same so I haven't put in the work to use expect/actual in them. I'll look into it but currently my forks fit my needs so no promises.
New update out for the multiplatform dialogs, fixed many bugs on desktop and added support for icons and window titles
Thanks but I already made a port of accompanist multiplatform !
Got some time today to work on my forks, Accompanist and Compose Material Dialogs(other than DateTime) use CommonMain. I am waiting on LocalTime support in KotlinX-datetime to port the datetime module
@Syer10, could you please update your fork to the latest 0.7.0 version?
@Syer10, could you please update your fork to the latest 0.7.0 version?
Done 👍
@Syer10 a new stable multiplatform compose Version 1.2.0 has been released. Can you please update your libraries?
I guess I could when I have time. Its not really priority since I already had them using the 1.2.0 alpha builds and they work fine on my 1.2.0 application.
Thank you for making this nice components for Jetpack Compose! 👍
I would like to use the date picker on a project using JetBrains fork compose-jb.
Currently it can't be used for some reasons in "commonMain" and is filtered out. I don't understand right now how this filtering works there.
I tried to copy the classes to my project and see if it works this way. Thereby I figured out that most (nearly all) of the code compiles and seems to be compatible already. Just some Android specialities like the
@StringRes
annotation do not work.I was thinking that you could strip out Android helper methods and special stuff to an additional package and have a package that's purely compose and would work for compose-jb also.
What do you think?