Arquitectura del propio SDK – API de método asíncrono en Kotlin

Estamos construyendo un SDK público para nuestro producto. Está construido con Kotlin e internamente usamos corotines. Sin embargo, queremos publicar una API que sea utilizable a partir de JAVA, por eso no podemos proporcionar funciones suspendibles como API pública.

Estamos bien, si la usabilidad en Java será less cómoda que en Kotlin, eso es bastante esperado.

Entonces, por ejemplo, estamos buscando un tipo de devolución del siguiente método asíncrono:

class Sdk { fun getPlace(): ___ } 

Cosas que hemos considerado:

  1. Usando un RX Java como interfaz. No nos gustan estas soluciones, Rx es bastante complejo y queremos agregar la menor cantidad posible de otras dependencies. En general, nos gustaría ir con Single. Pero, Rx java cosas que no queremos resolver (qué hilo debe ser el trabajo realizado) y Rx no resuelven cosas que nos gustaría resolver (si es posible), por ejemplo, ciclo de vida y observador: las cosas resueltas en los componentes de la architecture de Android .

  2. Java 8 Future. Esto parece ser el más apropiado, pero no posible, ya que tenemos que apuntar a Androides más viejos (4.1 como mínimo).

  3. Arquitectura de Android LiveData. La devolución de un LiveData parece estar bien, también hay un método observeForever () que lo hace utilizable en hilos de backgrounds. Por otro lado, la api sugiere que puede devolver repetidamente múltiples resultados. Pero definitivamente queremos omitir solo el resultado o una exception. En Kotlin, sin embargo, podemos implementar funciones de extensión que lo harán bastante útil como sdk.getPlace().await() .

  4. Solución personalizada: devuelva un object Result simple, puede subscribir el resultado proporcionando una callback sdk.getPlace().observe(Observe { onSucccess(data: Place) {} onFailure(e: Throwable) {} }) ; proporcionaremos una function de extensión para esperar.

Las preguntas:

  1. ¿Perdimos algún aspecto / biblioteca / posibilidad importante?
  2. Qué solución deberíamos elegir y por qué.

No estoy seguro de si esta pregunta tiene una respuesta concreta. Entonces todo lo siguiente es solo mi opinión. Puedes estar de acuerdo o en desacuerdo. Hay muchas maneras diferentes de lograr lo que pidió el OP.

Personalmente, no includeía ninguna dependencia en Rx o Architecture Components con LiveData. Si bien muchas aplicaciones modernas usan estas dependencies, no creo que sea una buena idea tener muchas dependencies de terceros en tu SDK. Otros desarrolladores podrían anularlos y podría generar resultados impnetworkingecibles.

Veo 2 soluciones:

  1. Pregúntese si puede hacer que este método no sea asynchronous y permita que los clientes descubran cómo usarlos. Puede sonar no muy fácil de usar pero, como desarrolladores, sabes que probablemente terminen con su propio contenedor asíncrono en torno a las devoluciones de llamada del SDK.
  2. Use una callback personalizada. Esta es una forma bastante sencilla y común de proporcionar una API pública en el mundo de Android. Si otros desarrolladores usan Rx, entonces saben cómo ajustar estos methods para seguir sus flujos. Lo mismo es cierto para los usuarios de LiveData.

Si yo fuera tú, también pensaría en exponer diferentes methods API para usuarios de Java / Kotlin. Los usuarios de Kotlin le agradecerán que brinde una manera más limpia, por ejemplo, coroutines, para llamar a los methods del SDK.

  • 'x' no es una function al pasar parameters en Kotlin Javascript
  • Kotlin, estructura del proyecto
  • ¿Conversión de Kotlin SAM con una interfaz Java interna privada?
  • ¿Por qué algunos methods de configuration de Java se convierten automáticamente en properties de Kotlin pero otros no?
  • Kotlin utiliza la interfaz de callback de Java
  • Kotlin: cómo pasar la matriz a la anotación de Java
  • Pasar un object detector como un parámetro de function en kotlin
  • Llamar a kotlin funciones que son palabras key en java de java?
  • String :: toByteArray () no se comstack en Kotlin
  • Smart Cast no funciona como se esperaba
  • Kotlin Vertx Type Mismatch encontrado Future <Unit> expected Handler <AsyncResult <Void >>