KMP experiment

[PaulDGillis]

Hi, ive worked as an android dev for a few years. I'm familar with the old/new android apis. I'm potentially interested in trying to make the Artemis client a KMP app (iOS/Desktop/Android). It'd be an experiment to see if it's even possible for an app like this, and if it'd be performant enough. I thought it'd be an interesting challenge, and if it works out it might make maintaining the client a bit easier. I wanted to ask a few questions for clarity before attempting if you dont mind.

Most of the app is in Java I noticed and uses XML for UI. Is this for a legacy code reason or performance one?

It'd have to use the compose UI framework on android/desktop, as well as made into Java -> kotlin. Do you know of any pitfalls I might encounter before attempting?

I've worked with video pipelines meant for camera effects before on macOS/windows. Do you know what the android NDK is being leveraged for? EDIT: NVM, seems the a lot of the video code is written in C. I'm looking into how its being used in code base, Its been awhile since I've done C but I have some C/C++ experience.

Any files in the code base you'd say should look into for better understanding of the app?

Do you think this is even worth attempting or are there obvious pitfalls I'm missing making it not worth attempting?

Thanks for your work on apollo/artemis, any info u can provide would be super helpful, thanks!

EDIT: After some investigation more C NDK code is more used then I originally thought. I'll probably start migrating the UI from XML to compose and Java to Kotlin. Then testing if the app is still performant enough to try and migrate some of its C NDK code into Kotlin.

[ClassicOldSong]

I have thoughts about completely rewriting the UI for all clients for a more unified and user friendly design but I don't have time yet. I suggest keep things as is before there's absolute necessity to rewrite all clients, at least before we have the design for the reconstruction ready.

I'm not really into Kotlin yet, since runtime overhead is absolutely bigger than using Java directly, and packaged sizes must increase. Also there're other active forks exist, so changing way too much may make picking changes from other forks or from upstream much harder.

Thanks for your interest in helping to make the project better!

[PaulDGillis]

Design for reconstruction? I may just be out of the loop, is there major client/server communication changes coming down the pipe?

My interest is in the unified cross platform code base, which requires a rewrite regardless. I don't intend this to become official client, but one that works the same across platforms sharing 95% of the code base between iOS/Android/Desktop like other KMP apps ive made.

Kotlin lang is nice to work in, but I don't even know if this kmp tech stack will work, hence why I thought a fork made more sense. I just wanted to pick your brain on places in the code base to familarize myself with.

Thanks for getting back to me so fast! I've been rapidly reading through the codebase and think I have a general idea of the project's structure, mostly trying to understand the CPP ndk code

[ClassicOldSong]

Unified code base is hard and sometimes very impractical, the cost for cross platform is too big to be worth a consideration for me. Only core logic can be shared, but not UI/peripheral parts. Core logic is already shared via moonlight-common-c.

Communication protocol may change (and already has) when necessary.

[PaulDGillis]

Understandable, I've had similar struggle in cross platform apps. Ive actually only ever had success in KMP projects. It isn't without problems sure, kmp has just had a decent interop with the platforms Ive used it on. Ive had projects have a shared kotlin core and is consumed by SwiftUI/Compose. Knowing the code is already shared in moonlight common c actually helps a bit.

I'll look into a different project for doing cross platform research as it is unwanted. It also is seeming that more code is already shared than i thought between platforms and less necessary.

[ClassicOldSong]

Sure, have fun experimenting!