https://kotlinlang.org logo
Join Slack
Powered by
Puh ... really difficult to tell if compose-multip...
# compose-ios
j
Puh ... really difficult to tell if compose-multiplatform in its current state is a valid approach to use in production. Feels like that you have to figure out workarounds or build you own logic to make everything work and in the end thats taking most of the time and you loose focus on whats important. Some examples: • Currently there is no multiplatform navigation-component available. This means you have to use a third-party lib or you try to implement your own multiplatform navigation or use native navigation components on each platform (e.g. jetpack navigation component on android) • Some UI-Components are missing, e.g. I could not find something similar like an ExposedDropdownMenuBox. • All compose-multiplatform projects/apps I saw till now were just kind of "demos" (e.g. DroidCon NYC, NYTimes-KMP) and are hard to compare to real customer apps . Basically they just consist of a Screen and a DetailScreen • Documentation can be improved (lacks information) • Currently no roadmap. Its hard to tell what type of commitment it will get by community/jetbrains/google Maybe I have not peeked everything right now, but for me it seems like a risky bet to use compose-multiplatform in its current state. If I am wrong please correct me. I would be glad and still dream of true native multiplatform approach, buts these are currently my impressions.
o
I maybe sound like Captain Obvious, but iOS part is in alpha and is not meant to be used in production 🙂 Exactly because it generally “works” but missing a lot of parts, including those you listed
j
yes, I know and I do not want to blame anybody for that. Therefore it would be really helpful what is planned for now, for the future and what kind of commitment can be expected from jetbrains or other companies to make this a valid approach.
But it seems like that there is also stuff missing on android side, e.g. ExposedDropdownMenuBox. I thought that compose-multiplatform for android is just like jetpack-compose, but obviously there seems to be some kind of gap between these two which I was not aware of
a
That's technically impossible because compose multiplatform just delegates to jetpack artifacts on Android.
j
I do not question that, but I was not able to find something similiar to this in compose-multiplatform: https://m3.material.io/components/menus/overview#b1704de4-94b7-4177-9e96-b677ae767cb4
a
Yeah because it's not yet implemented on other platforms but you can definitely use it in Android source sets.
a
We’re definitely working to make compose-multiplatform a complete UI library that can be used in production. Currently some parts (desktop) are ahead of others (ios), but we are working on them. I don’t know if we’ll end up implementing a rich library of widgets, but I think even if we do, that’s still quite a while away. We will be implementing all the basics, though, that’s for sure.
Speaking unofficially, as a regular developer working on his own pet Compose desktop app -- while much is missing, the nature of compose makes it relatively easy to fill the gaps yourself. Where with other toolkits, you’d be stuck waiting for the devs, in Compose you can just do it yourself with not too much effort.
j
@Alexander Maryanovsky thanks for your response. @Albert Chang This https://developer.android.com/reference/kotlin/androidx/compose/material3/package-summary#ExposedDropdownMenuBox(kotl[…]i.Modifier,kotlin.Function1) is not available in compose-multiplatform 1.4.0 which is, as far as I know, the latest release on github.
a
You can sometimes get away by copy/pasting widgets from the desktop
and use expect/actual to use the right thing on each platform
j
is there an example for that somewhere?
a
of expect/actual?
j
no, I now the expect/actual usage. I mean the copy/pasting widgets and usage of expect/actual. Its not 100% clear what you mean
and regarding my ExposedDropDownMenuBox problem. What I am supposed to do? Do I have to build my own? I do not understand why I can not use it in compose-multiplatform if they are the same as jetpack compose
a
ExposedDropdownMenu is actually not even in desktop, but you can try to grab it from the android source in the same way.
What I mean is to just copy/paste the implementation from sources.
(assuming your licensing is compatible)
j
@Albert Chang ah, sorry. My mistake is that I tried to add it to a composable in commonMain. In androidMain its available
But then I ask myself what kind of approach I should use to have a commonMain composable for ios&android with a dropdown?
a
Implementation of window is platform-specific, so all the components that use a separate window (such as dialog or drop-down menu) are platform-specific, meaning that they need to be implemented for each platform. You can copy the source of other parts and modify the window part.
what kind of approach I should use if I want to display a screen for ios/android which which shares a common ui?
As Alexander said, expect/actual composable functions.
j
ok, I kinda get a glimpse of an idea. I would create an expect class MyDropDownMenu which uses an actual class with ExposedDropDownMenuBox on android side, but how to I solve it on iOS side? Is it going into this direction https://github.com/JetBrains/compose-multiplatform/blob/de2949c34df287a6b55d09fd2e[…]sMain/kotlin/example/imageviewer/view/LocationVisualizer.ios.kt ?
@Albert Chang @Alexander Maryanovsky thanks for the hints! I made it work with a commonMain composable and an expect/actual class for android. Any hints how to do that for iOS would be appreciated ...
a
@Dima Avdeev Can you help? I’m not familiar enough with the iOS part.
d
For now it is hard to do it by yourself. We will provide DropDown for iOS ourselves in the future.
c
To a couple of your other points: Compose is solely focused on the UI layer, and is not trying to define application architecture. Navigation, especially, is very much a problem of app architecture, so I highly doubt we’ll ever see an official navigation library. There are a few good libraries out there, such as Voyager, Decompose, or Ballast Navigation, but it’s also just as easy to build navigation yourself. And this is actually a good thing, in contrast to what’s typical of UI toolkits. Compose is simple and flexible enough that you aren’t locked into the navigation style offered by the toolkit. Larger apps are also not going to help much with Compose, since the Compose code is going to be the same as with smaller apps, so what changes is the architecture. App architecture is usually very specific to the needs of the app, and it’s not easy to build a large app in a way that its architecture can immediately be adopted for another use-case. And again, Compose is focused on the UI layer, not the architecture layer. So any large app codebases you’d find would be real production apps, and given iOS just came out and is still in alpha, it’s not likely we’ll see larger apps for a while. And to the point of lacking documentation: nearly everything you need is going to be in the official Android Compose docs. While they are specifically written for Android, Compose is similar enough on all targets that nearly every snippet can be used on other targets. And even if not, the principles themselves are the same on all platforms, so there doesn’t need to be a separate repository of documentation for each target. Even app the Android architecture docs are generic enough to be useful on non-Android targets, in many situations.
a
There’s some (mostly desktop) target-specific documentation here: https://github.com/JetBrains/compose-multiplatform/blob/master/tutorials/README.md
l
I had to write some expect/actuals for a prototype. I've attached a link to a file that allows me to create dropdowns. I also have basic Dialog, image loading, and video player. https://github.com/LandryNorris/FFmpegKitKotlinTestApp/blob/main/shared/src/iosMain/kotlin/com/example/ffmpegkittestapp/Spinner.kt
j
Thanks for all your responses. @Casey Brooks I will have a look at navigation. It seems that the ImageViewer example has very lightweight approach. @Landry Norris Will check this out and let you know if I made it work.
@Landry Norris thx for the link to that file. I made it work in iOS side. There was one issue with Kotlin 1.8.20 saying something like:
Copy code
Native compilation failure: Suspend functions should be lowered out at this point, but FUN LOCAL_FUNCTION_FOR_LAMBDA
See <https://youtrack.jetbrains.com/issue/KT-57875>
I could fix that by changing the onClick-call of the Modifier.expandable extension to:
Copy code
onClick(action = {
        onExpandedChange()
        true
    })
8 Views
Open in Slack
PreviousNext
Powered by