Home Articles

自己的SDK架构 - Kotlin中的异步方法API

Asked
Viewed 87 times
3

我们正在为我们的产品构建一个公共SDK . 它是用Kotlin构建的,在内部我们使用协同程序 . 但是,我们希望发布一个可用于JAVA的API,这就是为什么不能将可挂起的函数作为公共API提供的原因 .

我们没问题,如果Java中的可用性不如Kotlin那么舒服,那是非常期待的 .

因此,例如,我们正在寻找以下异步方法的返回类型:

class Sdk {
    fun getPlace(): ___
}

我们考虑过的事情:

  • 使用RX Java作为接口 . 我们不喜欢这个解决方案,Rx非常复杂,我们希望尽可能少地添加其他依赖项 . 一般来说,我们会选择返回Single . 但是,Rx java我们不想解决的事情(哪个线程应该完成的工作)和Rx不能解决我们想要解决的问题(如果可能的话),例如生命周期和观察者 - Android架构组件中解决的问题 .

  • Java 8 Future . 这似乎是最合适的,但不可能,因为我们需要针对较旧的机器人(至少4.1) .

  • Android架构LiveData . 返回一个LiveData似乎没问题,还有一个observeForever()方法使它可以在后台线程中使用 . 另一方面,api表明它可能会重复返回多个结果 . 但我们只想省略结果或一个例外 . 但是,在Kotlin中,我们可以实现扩展函数,这将使它非常适用于 sdk.getPlace().await() .

  • 自定义解决方案:返回一个简单的Result对象,您可以通过提供回调 sdk.getPlace().observe(Observe { onSucccess(data: Place) {} onFailure(e: Throwable) {} }) 来为结果提供subsrcibe;我们将提供等待的扩展功能 .

问题:

  • 我们错过了一些重要方面/图书馆/可能性吗?

  • 我们应该选择哪种解决方案以及原因 .

1 Answer

  • 3

    我不确定这个问题是否有具体的答案 . 所以以下只是我的意见 . 你可以同意也可以不同意 . 有很多不同的方法来实现OP所要求的 .

    就个人而言,我不会在使用LiveData的Rx或Architecture Components中包含任何依赖项 . 虽然很多现代应用程序都使用这些依赖项,但我认为在SDK中拥有大量第三方依赖项并不是一个好主意 . 其他开发人员可以覆盖它们,这可能会导致不可预测的结果 .

    我看到2个解决方案:

    • 问问自己是否可以使此方法非异步并让客户弄清楚如何使用它们 . 它可能听起来不是非常用户友好,但作为开发人员,您知道他们可能最终会在SDK回调周围使用自己的异步包装器 .

    • 使用自定义回调 . 这是在Android世界中提供公共API的非常简单和常见的方式 . 如果其他开发人员使用Rx,那么他们知道如何包装这些方法以跟随他们的流 . LiveData用户也是如此 .

    如果我是你,我也会考虑为Java / Kotlin用户公开不同的API方法 . Kotlin用户会感谢您提供更清洁的方式,例如:协同程序,调用SDK的方法 .

Related