I can't remember who was asking before about shari...
# confetti
j
I can't remember who was asking before about sharing Compose code (between Android and Desktop clients) but just fyi that I'm doing that right now (in branch) for Compose for iOS code I'm looking at and should be able to share same for Desktop as well (shared UI code still in
shared
module right now but we could have separate shared UI module if folks think that's better)
👍 3
m
I guess it was me. If you can create an initial module with the setup (kmm compose dependencies) for desktop, iOS and Android sharing code (maybe call it design-system or confetti-ui or something) and merge it to the main, I can contribute with extracting components.
I'm really lazy doing the KMM set-up, so once it is done I can help with the code part. 😂
j
I'm just doing a small bit of sharing of compose code right now ....specific to what I'm trying to add to iOS client. I've put code in existing
shared
module right now which seems to work ok but can move to separate module if we need
m
I was imagining to have a different module to make it easier to understand what goes where. For example, Wear OS imports shared but doesn't care about those UI components.
Anyway, I have created an issue to track it: https://github.com/joreilly/Confetti/issues/672
j
One thing I haven't got my head fully around is setup to pull in both frameworks then to iOS client (if we create separate one).....probably good thing to figure out but just not something I've looked at yet
m
Hm, I'm completely ignorant how KMM creates the iOS frameworks. That said, maybe we can import the UI in shared-ios, shared-android and shared-desktop, and include it in its artefacts?
That way, the shared-common (which is used by wear and Auto) doesn't include the common UI code?
Does it make any sense / is it possible? 🙃
j
Yeah, definitely worth exploring all right
@mbonnin I think we got a question as well about multi-module stuff.....be interesting to see what would be involved in dong that
c
I’ve started created a theme for Compose Multiplatform a while back based on a tweet da John sent: - https://github.com/cmota/multiplatform-theme It’s still really rough though
That said, maybe we can import the UI in shared-ios, shared-android and shared-desktop, and include it in its artefacts? (edited)
I believe you need to create a single framework that will contain all of them, otherwise what happens under the hood is that each framework that has dependencies on other frameworks will have it’s own copy of it (increasing the .ipa size)
j
Yeah, most of examples I've seen use single framework....I think it's possible to have multiple ones all but gets messy I think and may need for example "umbrella" framework to combine then.....we can start at least with single one and see how that goes
I started looking specifically at sharing part of screen (using Compose for IOS) as I think that will be interesting capability to have....ran in to following which I might have at least partial fix for https://twitter.com/joreilly/status/1652704240534429698?s=20
and @cafonsomota was actually going to start looking at pulling that in!
with part of screen using Compose for iOS as well I think it will allow nice comparison of how well the styles match!
c
was actually going to start looking at pulling that in!
I’ve started playing with it when I saw your tweet after kotlin conf 🙂
the limitation that I was currently facing and didn’t had enough time to overcome is - system font; I was using moko resources to load a custom one, but I think it only accepts loading one from
commonMain
and not from
androidMain
and
iosMain
m
Sorry, but what is the problem of using the Material theme and keeping the UI equal in the 3 platforms for now?
c
none, but I thought that Material Design would adapt to the platform itself, no? for instance, on iOS they use a different font, instead of using Product/Open Sans like we have on Android it should use the default for iOS I feel that users prefer to have an app that follows the system guidelines and not one that has the same look equal on all platforms (at least this in my case)
m
Got it. Sure, I agree. But we have that issue today anyway. I would, particularly, focus first in extracting the UI components and make them reusable across platforms. I think that is where we benefit most, as it reduces the UI we need to maintain. Once that is settled, I would dedicate time in making them platform specific (L&F).
Of course, not saying we need to do this, just sharing my point of view. (:
j
I think we can do that to some extent in parallel ....including for example using same shared module for now I think and then potentially look later at extracting to separate module
the theme stuff is mostly interesting I think in context of exploring sharing of Compose for iOS and in particular where only part of the screen includes shared UI (which I think is quite an interesting use case that very much differentiates it from other approaches.....in a similar way to which core KMP does for non-UI code)