One of my go-to utility classes

Bob Dahlberg
3 min readApr 14, 2017

I wrote an utility class (or micro-library) many years ago in ActionScript when I wanted to solve an issue of having inversion of control over my business logic modules. I wanted to be able to test them by injecting test- or mock modules during testing, have lazy initialisation support, centralised control, and be sure to always get the same instance of the modules from all over the application.

The library created was called Crib. When I later started working on Android I realised that I had many of the same issues with sharing modules over multiple views so I ported my library to Java and have been using it in every single Android application I’ve developed.

I’ve just no come to port it to Kotlin, which is my current language of choice for Android development, and thought that it might be time for my little class to be promoted and open sourced. It might be of some use for someone out there so why not. I’ve also simplified the implementation of the class to my current use.

These days we have a lot of trends in development and architecture of software. One of them is dependency injection which I’ve been interested in using in my applications, but I haven’t found an intuitive solution to use in android. Dagger2 which is the general solution of choice is not easy to incorporate into existing code bases. Compared to when I develop services in Scala where it’s hard not to use dependency injection and it’s a part of the framework.

So at the moment I get lot of the same benefits from my utility class as I would from the dependency injection frameworks I know about in Android. The difference is not getting my implementations injected, I have to ask for them instead.

At least thats how I’ve been using it until now. Thanks to Kotlin I can almost use it exactly as if it were injected into my implementations.

So how does it work?

In its most straightforward way you create an instance of Krib and store it somewhere centralized and reachable to all that want to use it. Bootstrap it with the modules you want it to control.

val krib = Krib()
krib.add( Clock::class, IClock::class )

Then when you need that instance of any of the module stored in the Krib you just require it via it’s interfaces.

val clock:IClock = krib.require( IClock::class )

Simple as that you can use your module from anywhere you can reach the krib-instance, and by using only interfaces you can easily test or change the implementation behind that interface without interfering with the implementations.

To make the Krib reachable I tend to use a Kotlin object to store the instance in together with an extension function. And to make it almost injected I now use delegation properties in Kotlin. I have my own implementation that uses the lazy delegate in kotlin so that my class declaration can look like this:

class Schedule() {
val clock by inject<IClock>()
...
}

To be able to make this possible I need a global way to reach the instance of crib from which I want to get the implementation from. Otherwise we need to provide the implementation to the inject-function like so:
val clock by inject<IClock>( krib )
and to make it even clearer I sometimes name the parameter from so I can call it like this: val clock by inject<IClock>( from = krib )

That last peace of code reads very nice I think, “value clock by injecting IClock from krib”.

Here’s the link to the repo in GitHub. Hope you find it useful, and if you use it, please let me know what if you think. The inject-extension functions are also in the repo so that you can use them if you want to.
https://github.com/dahlbergbob/krib

→ Bob

--

--

Bob Dahlberg

Lead Developer at Qvik, Coach, Agile Thinker, GDG Lead.