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?
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