Java – Own SDK architecture – asynchronous method API in Kotlin

We are building a public SDK for our product. It is built in Kotlin and we use coroutines internally. HOWEVER, WE WANT TO PUBLISH AN API THAT CAN BE USED IN JAVA, WHICH IS WHY WE CAN’T PROVIDE SUSPENDABLE FUNCTIONS AS PUBLIC APIS.

We’re okay, it’s to be expected if Java isn’t as comfortable as Kotlin.

For example, we are looking for the return type of the following asynchronous method:

class Sdk {
    fun getPlace(): ___
}

Things we’ve considered:

1. Use RX Java as an interface. We don’t like this solution, Rx is very complex and we want to add as few other dependencies as possible. Generally, we choose to return to Single. However, Rx java things we don’t want to solve (which thread should do the work) and Rx don’t solve things we want to solve (if possible), such as lifecycle and observer-things solved in Android architecture components.

2. The future of Java 8. This seems like the most appropriate but not possible, since we need to target older Android (at least 4.1).

3. Android architecture LiveData. Returning a LiveData seems fine, and there is also an observeForever() method that can be used in a background thread. The API, on the other hand, indicates that it may return multiple results repeatedly. But we definitely want to omit only when the result or an exception is made. In Kotlin, though, we can implement an extension function that would make it as useful as sdk.getPlace().await().

4. Custom solution: return a simple result object by providing the callback sdk.getPlace().observe(Observe { onSucccess(data: Place) {} onFailure(e:throwable) {} }); We will provide the extension function that waits.

Question:

1. Are we missing some important aspects/libraries/possibilities?
2. Which solution we should choose and why.

I’m not sure if there is a specific answer to this question. So all of the following is just my opinion. You can agree or disagree. There are many different ways to implement the requirements of an OP.

Personally, I don’t put any dependencies on Rx or schema components in LiveData. While many modern applications use these dependencies, I don’t think it’s a good idea to include a lot of third-party dependencies in your SDK. Other developers can override them, which can lead to unpredictable results.

I see 2 solutions :

1. Ask yourself if you can make this method non-asynchronous and let the customer figure out how to use them. This may not sound very user-friendly, but as a developer, you know they might end up using their own asynchronous wrappers around SDK callbacks.
2. Use custom callbacks. This is a very straightforward and commonly used way to provide public APIs in the Android world. If other developers use Rx, then they know how to wrap these methods to follow their flow. The same goes for LiveData users.

If I were you, I would also consider exposing different API methods for Java/Kotlin users. Kotlin users will appreciate more concise ways, such as coroutines, to call the SDK’s methods.