Lucas Schiavini

    Lucas Schiavini

    5 months ago
    Damn this kind of breaks both my legs
    I'm gonna test this out to see if it matches my needs https://johnoreilly.dev/posts/kotlinmultiplatform-swift-combine_publisher-flow/
    John O'Reilly

    John O'Reilly

    5 months ago
    Hi Lucas, It may not suit your needs but more recently I've switched to using new async/await etc provided in Swift 5.5. along with following library https://github.com/rickclephas/KMP-NativeCoroutines
    (also btw using new K/N memory model now in most projects)
    wrote a bit about using that library in https://johnoreilly.dev/posts/kmp-native-coroutines/
    r

    Rick Clephas

    5 months ago
    Unfortunately concurrency interop is one of the biggest limitations (especially now we have Swift concurrency). IMO using wrappers is currently best “solution”. And… what @John O'Reilly said 😂 😇
    John O'Reilly

    John O'Reilly

    5 months ago
    a good number of the samples at following are using that library now https://github.com/joreilly
    Lucas Schiavini

    Lucas Schiavini

    5 months ago
    @John O'Reilly Do you think this library for kmp coroutines is production ready?
    John O'Reilly

    John O'Reilly

    5 months ago
    @Rick Clephas , as library author, can probably comment in more detail 🙂 , but fwiw seems to work great here. The integration with new swift async/await, AsyncStream etc is really nice ....particularly when mapping to flow in shared code and using appropriate hooks in SwiftUI to invoke async code along with automatic cancellation. you get (which is propagated down to flow)
    Personally I'm hoping this library could get integrated in to core Kotlin/Native offering as it, along with use now of new memory model, would make interop so much more seamless (any Jetbrains folks out there that can comment on whether this could happen? 🙂 )
    r

    Rick Clephas

    5 months ago
    I would say that the core of the library is production ready (meaning the way Flows/suspend functions are mapped to Swift types). However the compiler plugin that automatically generates the wrapper functions has some issues (it can cause recursion errors during compilation), but there are workarounds. Besides that there is only 1 thing I would really like to improve before officially calling it production ready: https://github.com/rickclephas/KMP-NativeCoroutines/pull/49 I have actually started tracking the these things here: https://github.com/rickclephas/KMP-NativeCoroutines/milestone/1
    Definitely hoping that we can integrated this in the Kotlin/Native ObjC interop. Unfortunately I am not that familiar with LLVM, etc. But I would definitely say that it is possible!
    Lucas Schiavini

    Lucas Schiavini

    5 months ago
    @Rick Clephas I'm curious to know what would it take to create the llvm bridge
    r

    Rick Clephas

    5 months ago
    Well there is 1 big challenge and that is the absence of kotlinx.coroutines (which is currently used to run/collect suspend functions and flows). Besides that it should be fairly straightforward (I think). During the ObjC header export coroutines functions/properties should be transformed into lambdas. After that the invocation of such declarations should should be intercepted and “transformed” into invocations to the wrapper functions (like nativeSuspend).
    I mean suspend functions are already transformed into functions with completion handlers, so they “just” need to be transformed a little differently.
    That is for Kotlin to Swift interop. Swift to Kotlin interop is a whole other story 😇
    rudolf.hladik

    rudolf.hladik

    5 months ago
    You can also check out Arkitekt library . It wraps flows and suspend functions in UseCases. I don't really see the point of wrapping flow to another stream 🤷
    r

    Rick Clephas

    5 months ago
    I think it just depends on the project and your requirements. The goal of KMP-NativeCoroutines is to improve the interop between Kotlin and Swift in terms of async code. Allowing Swift developers to use Kotlin async code in a "native" way, without making any assumptions about the application architecture. You could even use it with UseCases if you like.