Skip to content
Lightweight, minimalistic dependency injection library for Android & Kotlin (JVM)
Branch: master
Clone or download
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
android-example Prepare 1.6.1 release Apr 23, 2019
android Update documentation regarding AndroidX ViewModel Apr 23, 2019
androidx-viewmodel Upgrade Gradle to 5.3.1 Apr 2, 2019
buildSrc Update missed Kotlin references Apr 23, 2019
core Upgrade Gradle to 5.3.1 Apr 2, 2019
gradle/wrapper Update dependencies (Kotlin 1.3.30) Apr 23, 2019
speed-comparison Upgrade Gradle to 5.3.1 Apr 2, 2019
.gitignore Convert Android artifact to library project Dec 13, 2018
.travis.yml
CHANGELOG.md Prepare 1.6.1 release Apr 23, 2019
LICENSE Update installation steps in README.md Jan 21, 2019
README.md
TODO.md Update TODO.md Dec 19, 2018
build.gradle.kts Prepare 1.6.1 release Apr 23, 2019
gradle.properties Update Kotlin version to 1.3.20 Jan 25, 2019
gradlew Update dependencies (Kotlin 1.3.30) Apr 23, 2019
gradlew.bat Update dependencies (Kotlin 1.3.30) Apr 23, 2019
proguard-rules.pro Add AndroidX ViewModel support Mar 18, 2019
publishing.gradle.kts Update URLs Feb 6, 2019
settings.gradle.kts Add AndroidX ViewModel support Mar 18, 2019

README.md

Build Status Release Kotlin Android Arsenal

Katana

Katana is a lightweight, minimalistic dependency injection library (similar to the service locator pattern) for Kotlin on the JVM, designed especially with Android in mind.

  • Extremely lightweight footprint (only ~15KB in classes and 128 methods after ProGuard), plain Kotlin, no third-party dependencies
  • It's fast (also see this comparison)
  • "Less is more", therefore:
    • No global singleton state. Likelihood of memory leaks is greatly reduced unless YOU are doing something wrong ;P
    • No reflection (see this regarding type erasure)
    • No code generation (unless inline functions count)
    • No dependency overrides possible (see Overrides)

Getting started

Katana consists of two core concepts: modules and components.

Module

A module describes how dependencies are provided. Each module should represent a logical unit. For instance there might be a module for every feature of your application.

val myModule = Module {

  // A "factory" declaration means that this dependency is instantiated every time when it's requested
  factory { MyDependency() }
  
  // A "singleton" declaration means that this dependency is only instantiated once (per component) 
  singleton { AnotherDependency() }
  
  // See how transitive dependencies can be injected with get() within the module's scope
  factory { YetAnotherDependency(get<MyDependency>(), get<AnotherDependency>()) }
  
  // Use named bindings when the type is not unique (there might be more Strings)
  singleton(name = "globalId") { "SOME_GLOBAL_ID" }
  
  // Use "eagerSingleton" for singleton instances which are instantiated as soon as the component
  // is created and not lazily the first time it's requested
  eagerSingleton { SomeEagerDependency() }
}

Component

A component is composed of one or more modules. It performs the actual injection and is also responsible for holding instances of dependencies which have been declared as singletons. This concept is important to understand! As long as the same component reference is used, the same singleton instances will be provided by this component. The developer is responsible for holding component references and releasing them when necessary. Only when the component is eligible for garbage collection will it's singletons be GC'd, too. This applies for module instances which were passed to a component, too. Module instances should only be held by a component and not stored anywhere else. Especially when the module provides object instances outside of it's own scope which were passed to the module during creation.

The component pattern has been introduced so that – especially in an Android environment – it is possible to inject objects that should be released when the view has been destroyed, like for example the current Context.

val component = Component(modules = listOf(myModuleA, myModuleB))

val myDependency: MyDependency by component.inject()

By default injection is performed lazily with the inject() delegate. Dependencies can also be injected immediately with injectNow(). Latter should rarely be used!

Components can depend on other components. In this case the current component combines it's own dependency declarations with those from the parent components. Parent components should always have a scope (lifetime) which is equal or greater than the current component or else memory leaks could be introduced. Imagine a component A and a component B. Component A declares B as a dependent component. B should be released but if A has a greater scope and is still referenced somewhere B will remain in memory.

val component = Component(
  modules = listOf(myModule),
  dependsOn = listOf(parentComponentA, parentComponentB)
)

A word on type erasure

Katana doesn't use reflection. Therefor it cannot circumvent Java's type erasure. During runtime Katana will not be able to distinguish between MyProvider<Int> and MyProvider<String> when both dependencies are declared. The following code will result in an OverrideException:

Module {
    
    factory { MyProvider<Int>(1337) }
    
    factory { MyProvider<String>("Hello world") }
    
    factory { MyDependency(get(), get()) }
}

Luckily Katana provides a solution for this! Just use named injection :)

enum class Names { IntProvider, StringProvider }

Module {
    
    factory(name = Names.IntProvider) { MyProvider<Int>(1337) }
    
    factory(name = Names.StringProvider) { MyProvider<String>("Hello world") }
    
    factory { MyDependency(get(Names.IntProvider), get(Names.StringProvider)) }
}

Overrides

Redeclarations of dependencies within modules, which would override existing declarations, are by design not possible in Katana. We believe that overrides, especially when they happen silently, are a source of subtle bugs. If you require an override for example in a test scope, you should instead structure your modules in a way that overrides are not necessary. For example:

val commonModule = Module {
    
    singleton { MyCommonDependency() }
}

val engineModule = Module {
    
    factory<MyEngine> { MyEngineImpl(get<MyCommonDependency>()) }
}

val testEngineModule = Module {
    
    factory<MyEngine> { MyTestEngine(get<MyCommonDependency>()) }
}

val productionComponent = Component(commonModule, engineModule)
val testComponent = Component(commonModule, testEngineModule)

Circular dependencies

You should avoid circular dependencies. Let's imagine the following setup:

class A(b: B)

class B(a: A)

val module = Module {

    singleton { A(get()) }

    singleton { B(get()) }
}

val component = Component(module)

val a: A by component.inject()

This will result in an StackOverflowError once Katana tries to provide an instance of A. When Katana executes the provider function of A it will try to solve the transitive dependency B which is required for A's constructor. B however requires an instance of A and such an endless cycle is born.

The solution to this problem is to structure the classes in a way that a circular dependency is not necessary. For instance by creating a third class C which holds the functionality which both A and B require.

If there's no easy fix to this problem Katana provides a workaround. Instead of get() use lazy() to provide a Lazy version of the dependency.

class A2(b2: Lazy<B2>)

class B2(a2: A2)

val module = Module {

    // See how lazy() is used here instead of get()
    singleton { A2(lazy()) }

    singleton { B2(get()) }
}

val component = Component(module)

val a: A by component.inject()

Logging

Katana provides a bit of information about dependency declarations and injections during runtime which might help in debugging DI-related issues. To enable logging pass an implementation of Katana.Logger to the Katana.logger property of the Katana singleton.

Installation & Setup

Katana is published on JCenter. If you haven't already done it, add JCenter as a repository to your project. Then add the following dependencies:

dependencies {
    implementation 'org.rewedigital.katana:katana-core:1.6.1'
    // Use this artifact for Katana on Android
    implementation 'org.rewedigital.katana:katana-android:1.6.1'
}

All artifacts are signed with a GPG key for opensource@rewe-digital.com. You can download the public key here. The fingerprint is 0772 2AB2 25D7 BC94 54C2 1ED2 3AC1 25FD 1FB3 DA35.

Also have a look at the Android-specific setup steps.

Help & contribution

If you found a bug or want to suggest a feature, please create an issue.
If you need help, visit our Slack channel.

Further reading

License

The MIT license (MIT)

Copyright (c) 2019 REWE Digital GmbH

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

You can’t perform that action at this time.