https://www.flickr.com/photos/the-money-pit/5900474232 Kotlin opened up a new world for us. Developers write less code than before in world. And Kotlin’s interoperability with Java made it easy to incorporate it into existing and new apps, while still having the freedom of using our favourite Java libraries. Java However, as these libraries are written in Java, consuming them in Kotlin often results in Java-like syntax. This does not mean we need to reinvent the wheel and write a Kotlin version of that library (something I see a lot nowadays). But maybe we can write some Kotlin layers around it. A good example is by which took away the ugliness in using Mockito in Kotlin — something that was badly needed Kotlin Mockito Niek Haarman Often it’s not that bad as with Mockito, and so we keep going.But we should not! We should take a deep breath and see if we can improve it. When it comes to dependency , I am not the biggest fan of Dagger due to the ridiculous amount of boilerplate code required to set it up. In addition it’s not really good for testing. And for me testing is one of the reasons for dependency injection in the first place. So I like the approach of . Started as a project at Groupon (an app with tens of millions of downloads) by open source hero and his colleague it was meant as a fresh approach to Dependency Injection some time ago, avoiding much of the boilerplate of Dagger 1+2. One of it’s strength is testing, it was built with testing in mind. injection Toothpick Stephane Nicolas Daniel Molinero Reguera But using it in Kotlin project lead me to the point where I needed to improve it as my eyes where hurting. Let’s look how we bind some classes to a module: val module = Module()module. (Repository::class. ). (DbRepository::class. )    module. (Scheduler::class. ). (DefaultScheduler())module. (Api::class. ). (ApiProvider()) bind java to java bind java toInstance bind java toProviderInstance Toothpick can bind a class to either another class or an exiting instance or a provider class that can create the class needed at runtime. Let’s first make this a bit nicer with Kotlin: val module = Module(). {bind(Repository::class. ).to(DataBaseRepository::class. )bind(Scheduler::class. ).toInstance(DefaultScheduler())bind(Api::class. ).toProviderInstance(ApiProvider())} apply java java java java Some things that should bother us: is an existing extension function to create instance of . As of the same name it’s really easy to mess this up here without even noticing. Your binding might not bind a thing but just create an unused instance to Pair Pair So we need to write it like this to make sure we get the right function: to bind(Repository::class. ).`to`(DataBaseRepository::class. ) java java And soon we are in the centre of ugly code ;) So let us improve step by step. First: it would be nicer to not pass the type but use generics: bind<Repository>().`to`(DataBaseRepository::class. ) java to call the original method we need the java instance. In Kotlin it is possible to get this from a generic type if we mark the type reified (works only for functions declares as inline, which makes sense) bind() Class inline fun <reified T> Module.bind(): Binding<T> = bind(T::class. java) This way we added a new bind to the Module as extension function. But now we have an empty method call. We should use that instead of just having it to call next method. So let’s build something so we can call it like this: <Repository>(DataBaseRepository::class. ) bindClass java It’s not that hard either: import kotlin.to as toPair inline fun <reified T> Module.bindClass(target: Class<out T>): Binding<T> = <T>(). { to(target) } bind apply So we are calling the other bind method we just created and use apply to add a call to to() on it. The import changes the name of the kotlin to function so no conflict exists here. Now we still pass the Java class version. Do we need to? I don’t think so. So it should be: <Repository>(DataBaseRepository::class) bindClass The implementation is very similar. We just need to take a KClass: inline fun <reified T> Module.bindClass(target: ): Binding<T> = <T>(). { } KClass<out Any> bind apply to(target. as Class<T>) java So this works nice when passing class names. When looking at the other variants, wouldn’t it be nice to pass a lambda? <Scheduler> DefaultScheduler() bindInstance { } It is very easy. This syntax can be uses if the last parameter of the function is a lambda: inline fun <reified T> Module.bindInstance(target: ): Binding<T> = <T>(). { } () -> T bind apply toInstance(target()) This brings me to the next idea. When we use a provider we are writing lots of boilerplate: class ApiProvider : Provider<Api> {override fun get(): Api {return RestApi()}} bind(Api::class. ).toProviderInstance(ApiProvider()) java Can we pass a lambda here too? Probably! But let’s go step by step: Applying what we did above would lead us to: bindProviderInstance<Api>(ApiProvider()) Actually the generic can be omitted here as Provider already defined the generic, the amazing feature of at work. type inference But instead of writing the provider, what we want is to write a lambda like this: <Api> RestApi() bindProviderInstance { } The code behind it would be: inline fun <reified T> Module.bindProviderInstance(target: ): Binding<T> = <T>(). {toProviderInstance(target. )) } () -> T bind apply ( asProvider where is another extension method that hides creating the provider boilerplate: asProvider() fun <T> . (): Provider<T> {return object : Provider<T> {override fun get(): T {return ()}}} (() -> T) asProvider invoke Let’s look at all the variations first in Java style: class ApiProvider : Provider<Api> {override fun get(): Api {return RestApi()}}val module = Module()module. (Repository::class. ). (DbRepository::class. )    module. (Scheduler::class. ). (DefaultScheduler())module. (Api::class. ). (ApiProvider()) bind java to java bind java toInstance bind java toProviderInstance and now in our new style val module = Module(). {bind<Repository>(DataBaseRepository::class)bindInstance<Scheduler>(DefaultScheduler())bindProviderInstance<Api>{ RestApi() }} apply But although is nice way here, it often gives the hint that we are working on a Java class too. So let’s improve this: apply() val module = module {bind<Repository>(DataBaseRepository::class)bindInstance<Scheduler>(DefaultScheduler())bindProviderInstance<Api>{ RestApi() }} This definition is easy too. A function module that takes a lambda that runs in context of Module and returns a module: fun module(bindings: ) = Module(). { bindings() } Module.() -> Binding<*> : Module apply And if you just have one module, let’s put this right in the scope: val scope = simpleScope(SCOPE) {bind<Repository>(DataBaseRepository::class)bindInstance<Scheduler>(DefaultScheduler())bindProviderInstance<Api>{ RestApi() }} where: fun simpleScope(scopeName: Any, bindings: Module.() -> Binding<*>?) = . {Module(). { bindings() }} : Scope openScope(scopeName) apply apply So it is very easy to improve an API that was designed for Java for Kotlin And as sharing is caring. Feel free to import all of this directly from . here Like I said in my previous post: if something is bothering you, improve it! #lifelong #learner

Too Long; Didn't Read

Making security fun one episode at a time

Java libraries with Kotlin. The case of dependency injection frameworks

Too Long; Didn't Read

Danny Preussler

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Java libraries with Kotlin. The case of dependency injection frameworks

Too Long; Didn't Read

Danny Preussler

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES