`Topic:` Looking for guidance on building a Kotlin Multiplatform SDK

# multiplatform

[Chad Lung]

Topic: Looking for guidance on building a Kotlin Multiplatform SDK

[Chad Lung]

Hi. I'm looking for some project guidance. I'm new to Kotlin and Multiplatform and I need to write a Multiplatform SDK to support iOS and Android to interact with a REST based service (to make it easier for the customer to use basically). The SDK will be used by iOS and Android engineers that will then build all the UI and interactions from the SDK to their app. My piece (the SDK) has no visual aspect to it and boils down to making REST based calls and has a long polling call that will run the entire time the app is in use and when its not (keep going in the background). It will run a long polling for 2 minutes (if no response) then get disconnected and then re-connect. Also, it will reconnect if any data is returned. I'm using Ktor Client to make the calls and this is part working great. However, I have some questions and unfortunately couldn't find a lot of answers searching the internet.

1. To keep the long polling going through the life of the app it seems like running that in GlobalScope might be the only option but that looks like you have to be very careful not to leak memory, etc. While the long polling is going on they can still make requests to the SDK to fetch other endpoint's data. Is there another way that keeps this the long polling running even if the app isn't front and center? Options?

2. Passing data back from the SDK to the iOS or Android app. It looks like Flow, or State/Shared Flow is the usual way to do this. I want to pass back any data, status messages, etc. It looks like handing back a DTO of say a "Customer" object would be a good option as well. Otherwise, just passing simple strings would work for the other things. I found this article (https://johnoreilly.dev/posts/realm-kotlinmultiplatform/) and it kind of looks like what I'd want but without the DB aspect (I don't need to long or short term persist data).

Thanks.

[Kevin S]

I don’t have any insight on point 1.
For point 2: You could use serialization for the client calls and use that to pass data. Flows are usually the way to go, and for the iOS side there’s a popular library for converting them to a Combine version on iOS. You can also make your own like we’ve done at touchlab. I’ll have to find the version

[mbonnin]

Re: 1. I think it's nice to expose a .close() method in your SDK to free all resources:

val mySdk = createSdk()

mySdk.getUser(): User
mySdk.postStuff(stuff)

// later on
mySdk.close()

[mbonnin]

Then the caller is responsible for managing resources. If they want to keep your SDK running always and forget about cleanup they can. If they want to clean it up they can too

[mbonnin]

Re 2. the main question is whether your iOS devs will be using Swift or Kotlin. If they're using Kotlin, then a Flow<User> (or Flow of any other class you define is good)

[mbonnin]

If they're using Swift, Flow work too but it's a bit harder to call so either add Swift helpers or extra doc

[Kevin S]

https://github.com/rickclephas/KMP-NativeCoroutines here’s the library I was thinking of

[Chad Lung]

This is all really good information. Thank you for the help.