-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kotlin Multiplatform support #447
Comments
I'm not sure if this library even has any code or dependencies that currently rules out its use on specific platforms. What exactly would we need to change? |
Migrate to OkHttp v5.x and wait for them to bring other platforms' support, or choose the Ktor Client, rewrite all the networking code on another framework, and not wait for Square to bring multiplatform support for OkHttp. Both paths are time-consuming. |
When previously rewriting the Streaming API, I already had the idea to go for ktor and with it go for I don’t know how to write suspending Kotlin code that has good interoperability with Java code so I had put the idea on hold for the time being. |
We need to adapt only the Java-exclusive bigbone-rx module to Kotlin coroutines, don't we? |
@bpavuk Mhm, not entirely. At least from feedback we had gotten in the past, it seems like (some) people are also using the library called from “vanilla” Java without RxJava. Having a Coroutines<>RxJava bridge would, for example, be possible via That being said, I would still very much like to give ktor a try. Even if just for how much easier testing with it looks, especially for WebSockets which we use for the streaming portion of the Mastodon APIs. |
Fast googling suggests we cannot call Coroutines from pure Java code. |
I don’t see how we could keep that intact. We would then need to maintain both versions. With ktor not being Coroutines-friendly but Coroutines-“based”, I don’t really see a way here. We would have to handle methods and functions as We’d likely have to think about how to move forward here and how we want to structure BigBone anyway. Do we want to keep on supporting pure Java? Do we want to introduce different modules to the library where users could, for example, use only our types but do the calls themselves, and then have the API calls as easy-to-call methods like we currently provide them, but in a separate module you could add a dependency for? Either way, we’ll have to talk about it if we want to move forward with either KMP support or even just Coroutines. |
Kotlin Multiplatform is slowly rising, many major libraries are either migrating or already support KMP. Google announced their official support of KMP, by the way. I know that there is a Mastodonk library, but the last commit was like 10 months ago
The text was updated successfully, but these errors were encountered: