Thought this note from another thread may be of in...

# multiplatform

[darkmoon_uk]

Thought this note from another thread may be of interest:

We're starting to use Kotlin Multiplatform on an Android-only project at work.
Is anyone else doing this with a single platform project?
It just feels like a good insurance policy to stay as loosely-coupled to the platform as possible; since KMP and the increasingly number of KMP libraries makes it so easy!

[John O'Reilly]

You might be interested in https://github.com/handstandsam/kmp-ready

[darkmoon_uk]

Oh nice! I think we have a good handle on it but this is really interesting TY

[Joel Denke]

@John O'Reilly Wow nice, have missed that plugin! Thanks! 🙂

[Joel Denke]

@darkmoon_uk If only using Android and not intend to do anything, I mean sure you could prepare Gradle, Kotlin setup and such to can switch into Compose and/or Kotlin multiplatform, but in reality no real difference if only apply Android.
However its quite nice as some androidx libs using KMP, so Gradle will evaluate those automatic for you instead of have to use like libs-android on all libs all the time 😛

I think its always good to decouple code from SDK specifics.
Like avoid using androidx lifecycle and Context in Compose if thats what you using, will help prepare but also improve your code even in native Android imo.

Thats one thing I like as well, KMP pushing you re-think architecture and almost enforce using good DI and interface hexagonal structure kind a 😛 It makes code in my opinion much better and flexible. It also protected yourself from easy being able to switch frameworks over time.

Its very easy to enable one target at the time btw, if want to test wasmJs, js, desktop, iOS or such but not sure if works good or not. Its a very nice Gradle mechanism. And if you using Gradle convention plugins its even easier if having many Gradle modules, can apply everything for all modules in one place 🙂

[darkmoon_uk]

Yes, we already strictly adhere to clean architecture, most of the code is easy to transition - pulling out the Dagger is the only painful part, I recommend medical assistance for that.

[Joel Denke]

Hahaha using annotation based frameworks is always a pain in that sense 😄
I remember somewhat pain migrate from Glide to Coil when compose was new 😄 Or migrate from ButterKnife to Databinding when Kotlin was new. Or from RxJava/RxKotlin to Coroutines 😄

[darkmoon_uk]

We're in favour of Manual DI; we have a convention that's based only in Kotlin language and is much simpler to work with.

[Joel Denke]

Once going Kotlin and Kotlinx my life been easy in architecture speaking and migrate over time, such as KMP things 😄

[darkmoon_uk]

We used our manual DI pattern in an earlier Kotlin Multiplatform project of ours and there was not a single point during the year where anyone said "Gee this would have been easier with Dagger". Mostly, we just stopped thinking about DI at all - and that's the point.

[Joel Denke]

Its a two edges sword, its nice having Dagger annoations to have compile time safety, but also not nice using Kapt or Java annoations 😄 But using manual DI having circular deps or missing deps its much more painful if accidentially push to production and the entire app crashes 😄
To have a balance in KMP I recommend checkout eitehr Kotlin Inject or Koin for DI instead of manual, if want a middle thing 🙂

[darkmoon_uk]

Our pattern is compile-time safe.

[Joel Denke]

Cool, compile time safe as checking circular deps? 🙂

[darkmoon_uk]

No magic, just constructor parameters and object Modules, with a few extra tenets thrown in.

[Joel Denke]

Right, yeah with compile time safe I meant check the DI graph is satisfied and cant in runtime cause crashes.

[darkmoon_uk]

Even if that possibility is open, I'd rather deal with 'one more runtime bug', than what I consider the hell of annotation DI.

[darkmoon_uk]

It's not like it's a more bug prone area of architecture than anything else.

[Joel Denke]

Can also add that Jetbrains target group right now is Android apps want to try KMP/CMP, or Android devs kind a. So very easy take evetything you know in Gradle and JVM/Kotlin world and apply. Even Compose working in most cases out of the box.
I am right now evaluating target wasmJs and desktop, on top of Android and IOS I have now. Working really good.
Can use things like androidx collection, androidx datastore and Google working on androidx lifecycle KMP supported, which required to make the rest of androidx same 😄 Something tells me Google working on using KMP much more themselves.

[darkmoon_uk]

Yep, it's an incredibly powerful ecosystem already, and growing stronger. I actually think people are underestimating the potential of Compose/WASM as a way of developing for the browser just like 'another rich client'. I lost my tiny mind when I realised the potential.

[darkmoon_uk]

One Dev can target all channels.

[Joel Denke]

If want web support, like wasm I recommend wait however, as not many libraries supporting wasm yet, only some of them having alpha released with support for that. Mostly its desktop/jvm and Android. And in some cases iOS.
I looking forward having Auto, Wearables, TV for Apple and Android things soon 😄

[Joel Denke]

Imagine using KMP to support all Android platforms with one CMP codebase 😄

[darkmoon_uk]

Heh, I'm no stranger to the bleeding edge in that regard - JB Dev repo definitions all over the place in personal projects lol

[Joel Denke]

Wasm is however quite buggy in browser Safari and Edge, for Wasm Canvas APIs etc that is. But its working in most browsers. Using my own design system in compose in all platforms right now 😄

[darkmoon_uk]

I'm building a personal project in the expectation that by the time I finish it, those browsers will have 'caught up'

[darkmoon_uk]

and if they don't... well let's just say it won't keep me awake at night.

[Joel Denke]

I do see potential in merge Jetbrains things with AOSP repo, so we can get faster iteration of KMP and Compose things. That including androidx wearable and tv compose libs and also Glade. So can have adaptive compose layout components working in any platform. In end working in Apple TV as well 😄

[darkmoon_uk]

Yes.

[Joel Denke]

Ofc need to adapt into watches with circular screen 😄

[darkmoon_uk]

Just yesterday I went on an AI journey to know if I could run Java Swing only on a linux FrameBuffer driver without heavy Windowing.

[darkmoon_uk]

Because Compose for Desktop ultimately sits on Swing AFAIK (through Skia/JVM)

[darkmoon_uk]

It might be possible to put Compose on the SPI LCD screens you typically get on Rapberry Pi

[darkmoon_uk]

Or other small ARM embedded systems

[darkmoon_uk]

No real reason, it would just be cool to put Compose there.

[Joel Denke]

I remember these discussions from React Native and Flutter, everyone said Javascript working everywhere when worked on RPi and embedded things, but still no cigarr 😄
So I hope compose staying decoupled as its now, and not lock itself to much to support everything in same system, more a modular system with interop they doing now. Otherwise we will see fragmentation Xamarin style all over the place again 😄

[Joel Denke]

Compose fingerprint engines needed often quite large, like render on Canvas things like Skiko.

[Joel Denke]

We will see, but at current state I am optimistic at least supporting desktop, iOS and Android. For web I am not sure to be honest, but we will see. Dont like we have to depend on browser engines. Rather just use the OS browser running on like in desktop I think, if browsers could open up that instead would be easier 😛 Like render window directly from OS rendering engine inside browser, if thats possible, dont know.

[Joel Denke]

Anyway prepare for KMP is a good choice I think, so can easy switch in the future 🙂

[Jan Holešovský]

@darkmoon_uk I love your "Android-only, but KMP, to be prepared" approach. If you decide to release on iOS one day, we have a proprietary SDK that implements the Android API for lifecycle, widgets, layouts, etc. on iOS. Please DM me if you are interested in specifics, would be happy to talk.

[Michael Paus]

@darkmoon_uk Could you provide a few more details of your “manual DI pattern”?

[electrolobzik]

@darkmoon_uk I am also interested in more details about “manual DI pattern”. Could you please share some example?