Compose Multiplatform support
Skaldebane opened this issue · comments
Hi there! This library is truly amazing as it fills a big gap left in Compose.
However, it's only built for Android, so it can't be used in Compose Multiplatform for now.
Can this be implemented for other Compose targets, while providing a shared modifier that delegates to sensible platform-specific implementations?
Aside from project configuration etc, I think the implementations should be rather straightforward as Desktop/iOS platforms don't have the same limitations Android has on blur in older API versions, so a blur-based implementation could be easily done for them (and Skia is directly accessible in both).
As for web, I'm not sure how is the situation there, but it also uses Skia under-the-hood.
I'm ready to help with anything regarding this.
Thanks!
Hi, at first thanks for this feature request.
I checked your proposal, and it seems valid, but also I checked the CMP approach (basic app structure) and it seems quite obvious in the approach (similar to the Flutter). But I didn't find any examples of the UI CMP library, if you have any, please share them (in the meantime I am going to explore them as well).
As for the Skia implementation, yes, it is also possible, but I have 0 knowledge of it, and I would prefer a native approach for each platform.
So, I see this plan as the following. We can create a structure of interfaces that will cover common (shared) features with some extra properties for each platform if needed. As far as I see it, we can provide a new Modifier (.cmShadow(...)) that will have a Configurator class, where you can specify the desired shadow for each platform with the sealed class (because on the Web it could be multiple implementations, while on iOS only one).
So yeah, basically, we need to collect info on what types of shadows are supported in each platform, then design a cmShadow(...) structure, and then drive the actual implementation.
Regarding the implementation, I can lead the Android part, as for the iOS/Desktop/Web, I will just review/test it, so they approaches are aligned and the desired result is satisfied.
Gather your fellows to help us with this.
What do you think?
Thanks for the thorough response!
I didn't find any examples of the UI CMP library, if you have any, please share them
If you mean existing UI CMP libraries, there are quite a few, two examples that come to mind are Kamel, a lazy image loading library, and material3-windowsizeclass-multiplatform, which is a CMP port of the Android-only Material 3 Size class library in androidx.
As for CMP apps, there are some examples in the CMP repo, as well as many community projects.
As for the Skia implementation, yes, it is also possible, but I have 0 knowledge of it, and I would prefer a native approach for each platform.
Yeah indeed, a higher-level approach would be preferable. It's not more "native" than using Skia itself since that's what Compose Desktop/iOS/Web themselves use under-the-hood, through Skiko (Skia bindings in Kotlin), which is automatically imported with Compose itself.
Android itself uses Skia under-the-hood, but doesn't expose it directly, so Compose relies on what's exposed through the Android SDK.
In any case, a basic blur-based implementation for all three platforms could be very similar, if not identical, especially if we rely on high-level constructs (and in that case, it may as well be similar to the Android implementation). I'll begin experimenting with this at least on Desktop/Web and report my findings.
When it comes to naming the Modifier, I think it would be better if it keeps the same name, shadowsPlus, to not break expectations of Android developers moving to CMP, and keep all documentation consistent.
Side note: if we're going with a name change anyways, I would love to name it boxShadow on all platforms. While this name is very generic, the Compose team shows no interest in implementing box shadows anytime soon, so this library could be the de-facto implementation to serve everyone, and such a generic name would be easy to remember and reason about.
Allowing multiple implementation is a great idea, and we could pass a reasonable default as a default parameter.
Regarding the implementation, I can lead the Android part, as for the iOS/Desktop/Web, I will just review/test it, so they approaches are aligned and the desired result is satisfied.
I can code and test the Desktop/Web versions, as well as general Kotlin MP project configuration/structure and wiring things up. As for iOS, I don't have a Mac, so I can't really test that (but if the implementation is identical between these, you can test if it works as expected).
Let's go for it!
Hi, good thoughts. Thanks for the resources. So the next step is to create a new feature branch and work there. Then create another library module for CMP approach. And then experiment with it. Currently, I am a little bit busy at work & free time.
Creating a separate library module is a good idea, as it will give us time to experiment with this and get feedback before merging everything back together (maybe as a v2.0 if we make breaking API changes for existing Android users).
I'm also a little busy currently, but we can take this slowly, as time allows.
For now, create a separate branch for this, which I'll then fork and contribute to through PRs.
We'll start by setting up the basic KMP library structure as found on other libraries, and making sure the Android side works as intended, then we can add implementations for other platforms and see how to design the shared API properly.
After some time, I won't do it. This KMP is mehhh.