Архитектура собственного SDK – API асинхронного метода в Котлине

Мы создаем публичный SDK для нашего продукта. Он построен с Kotlin, и внутри мы используем сопрограммы. Тем не менее, мы хотим опубликовать API, который можно использовать в JAVA, поэтому не может предоставлять неприемлемые функции как открытый API.

Мы в порядке, если юзабилити в Java будет менее комфортно, чем в Котлине, это вполне ожидаемо.

Так, например, мы смотрим тип возврата следующего метода async:

class Sdk { fun getPlace(): ___ } 

Вещи, которые мы рассмотрели:

  1. Использование RX Java в качестве интерфейса. Нам не нравятся эти решения, Rx довольно сложный и мы хотим добавить как можно меньше других зависимостей. В общем, мы бы пошли с возвращением Single. Но, Rx java вещи, которые мы не хотим решать (какой поток должен выполняться), и Rx не решают, что мы хотели бы решить (если это возможно), например lifecycle & observer – все, что было решено в компонентах архитектуры Android ,

  2. Java 8 Будущее. Это кажется наиболее подходящим, но не возможным, поскольку нам нужно ориентироваться на старые андроиды (по крайней мере, 4.1).

  3. Android-архитектура LiveData. Возвращение LiveData, похоже, в порядке, также существует метод registerForever (), который делает его пригодным для использования в фоновых потоках. С другой стороны, api предполагает, что он может возвращать повторяющиеся множественные результаты. Но мы хотим, безусловно, опускать только результат или одно исключение. Однако в Котлине мы можем реализовать функции расширения, которые сделают его вполне пригодным для использования как sdk.getPlace().await() .

  4. Пользовательское решение: возвратите простой объект Result, вы можете подпросить результат, предоставив обратный вызов sdk.getPlace().observe(Observe { onSucccess(data: Place) {} onFailure(e: Throwable) {} }) ; мы предоставим функцию расширения для ожидания.

Вопросы:

  1. Пропустили ли мы какой-то важный аспект / библиотеку / возможность?
  2. Какое решение мы должны выбрать и почему.

Я не уверен, есть ли у этого вопроса конкретный ответ. Так что все следующее – это только мое мнение. Вы можете согласиться или не согласиться. Существует много разных способов добиться того, что задает ОП.

Лично я не буду включать никаких зависимостей от Rx или компонентов архитектуры с LiveData. Хотя многие современные приложения используют эти зависимости, я не думаю, что неплохо иметь много сторонних зависимостей в вашем SDK. Другие разработчики могут переопределить их, что может привести к непредсказуемым результатам.

Я вижу 2 решения:

  1. Спросите себя, можете ли вы сделать этот метод не асинхронным и позволить клиентам выяснить, как их использовать. Это может показаться не очень удобным для пользователей, но, как разработчики, вы знаете, что они, вероятно, получат свою собственную асинхронную оболочку вокруг обратных вызовов SDK.
  2. Используйте специальный обратный вызов. Это довольно простой и распространенный способ предоставления публичного API в мире Android. Если другие разработчики используют Rx, тогда они знают, как обернуть эти методы, чтобы следить за их потоками. То же самое верно для пользователей LiveData.

Если бы я был вами, я бы также подумал об экспорте различных методов API для пользователей Java / Kotlin. Пользователи Kotlin будут благодарить вас за предоставление более чистого способа, например сопрограммы, для вызова методов SDK.