-1

I am building an Android SDK in Kotlin that would be consumed by both Kotlin and Java users. It relies of common language patterns for Java & Kotlin like callbacks for async operations. In order to improve DX for Kotlin coroutines users I want to add modified versions of various callback operations to use Kotlin's suspending functions, Flows, etc.

I see that the common pattern, used by e.g. Android KTX or OkHttp, is to put coroutines overloads in a separate package, often named xxx-ktx or xxx-coroutines.

1. Are there any downsides of including coroutines support in the main library package?

Afaik it might increase method count, which might DEX method limit, but this could be addressed by proper Pro-guard config to allow removing unused coroutine related methods.

2. Are there any other considerations for adding coroutines to the main package vs having it in a separate package?

Maciej Jastrzebski
  • 3,674
  • 3
  • 22
  • 28

1 Answers1

1

1. Are there any downsides of including coroutines support in the main library package?

Apart from what you have mentioned, adding the additional dependency in your main library also exposes the new Coroutines related methods as public API surface from your main library. Which will make harder for you to evolve your library. If it would have separate library you can opt for different compatibility schemes for the add-on library

Also since these dependency will also be added as a transitive dependency for the client, it will can also make their project setup difficult. One example could be let's say you add Room database then client app also has to configure the kapt.

2. Are there any other considerations for adding coroutines to the main package vs having it in a separate package?

In my personal opinion, you should always design your library as abstracted as possible and design all the nice to have integration as seperate libraries. You can expose adapters where any external implementation can hook itself. Similar to the designs followed by Retrofit

AndroidEngineX
  • 975
  • 1
  • 9
  • 22
  • Retrofit seems a curious case, as they do include Kotlin extensions in the main lib, while having external adapters for RxJava2, 3, etc. – Maciej Jastrzebski Nov 07 '22 at 09:26
  • can you explain the "configure the kapt" piece a bit more? If my library does not have any annotations will it affect its users is any way? – Maciej Jastrzebski Nov 07 '22 at 09:27
  • Hi @MaciejJastrzebski regarding "configure the kapt", I am just giving one example. So basically adding additional library comes with their own baggage. And if you want to keep your library lean, you have decouple your all the other extensions of your library as separate library. To answer your *If my library does not have any annotations will it affect its users is any way?* no in that case your client will not need to configure the kapt – AndroidEngineX Nov 07 '22 at 18:27