To inject or not to inject: Dependency Injection with Kotlin (Droidcon Nairobi)

.droidconKe To Inject or not to Inject Dependency Injection with
Kotlin Danny Preussler sporttotal.tv @PreusslerBerlin

about:me • Java developer since 2003 • Talks about testing
and architecture on mobile since 2008 • Kotlin since 2016 • Google Developer Expert for Android and Kotlin • Worked for eBay, Groupon, Viacom

sporttotal.tv • We are streaming under-medialised sports • Looking for
Backend/Frontend Lead (Berlin) • Looking for iOS Developer (Berlin) • Looking for Designer (Köln, Berlin)

@PreusslerBerlin

Dependency Inversion Inversion of Control Dependency Injection ? ? ?
Service Locator

The Dependency Inversion Principle High level entities should not depend
on low level details.

Inversion of Control Who initiates a message Hollywood's Law: don't
call me, I'll call you.

Inversion of Control Stop using new

What? Why?

Inversion of Control Nothing says “implementation” more than the new
keyword

@PreusslerBerlin class MainActivity : Activity() { private val tracker =
GoogleAnalyticsTracker() override fun onCreate(state: Bundle?) { super.onCreate(state) setContentView(R.layout.activity_main) tracker.trackStarted() } }

GoogleAnalyticsTracker() override fun onCreate(state: Bundle?) { super.onCreate(state) setContentView(R.layout.activity_main) tracker.trackStarted() } } Not testable!

@PreusslerBerlin A voice out of the dark: Inversion of Control!

GoogleAnalyticsTracker() override fun onCreate(state: Bundle?) { super.onCreate(state) setContentView(R.layout.activity_main) tracker.trackStarted() } } Google Analytics is implementation detail Single Resposibility Not testable

Inversion of Control Common implementations: • Factory • Service Locator
• Dependency Injection

Inversion of Control Common implementations: • Factory tracker = Factory.createTracker()
• Service Locator • Dependency Injection

tracker = Locator.get(Tracker::class) • Dependency Injection

• Dependency Injection @Inject val tracker: Tracker

@PreusslerBerlin DI on Android

@PreusslerBerlin Dagger2 • Dagger1 by Square, Dagger2 by Google •
Most popular dependency injection library in Android • Very fast at runtime • Complete runtime validation

Why changing it then?

@PreusslerBerlin Annotation processing

@PreusslerBerlin @PreusslerBerlin

@PreusslerBerlin Annotation processing with code generation •Build time impact @PreusslerBerlin

@PreusslerBerlin Annotation processing •Came up to get around limitations of
Java as language @PreusslerBerlin

@PreusslerBerlin Problems of Dagger: • Complex • Hard learning curve
• Lot of boilerplate • Not very good for testing @PreusslerBerlin

@PreusslerBerlin How can Kotlin help? • Lazy • Delegates •
Type inference • Inlining (generic T) • Lambdas • Functional programming @PreusslerBerlin

@PreusslerBerlin Problems with Java DI and Kotlin

@PreusslerBerlin Constructors class PlayerViewModel( playlistUsecase: PlaylistUsecase )

@PreusslerBerlin Constructors class PlayerViewModel @Inject constructor( playlistUsecase: PlaylistUsecase )

@PreusslerBerlin Constructors class PlayerViewModel(playlistUsecase: PlaylistUsecase) {} vs class PlayerViewModel @Inject
constructor(playlistUsecase: PlaylistUsecase) {}

@PreusslerBerlin Default arguments class PlayerViewModel( val schedulers: RxSchedulers = DefaultSchedulers()
)

@PreusslerBerlin Default arguments class PlayerViewModel( val schedulers: RxSchedulers ) @Inject
constructor(): this(DefaultSchedulers())

@PreusslerBerlin Default arguments class PlayerViewModel( val schedulers: RxSchedulers = DefaultSchedulers())
vs class PlayerViewModel( val schedulers: RxSchedulers) @Inject constructor(): this(DefaultSchedulers())

@PreusslerBerlin Fields private val viewModel: ViewModel by lazy {… }
vs @Inject lateinit var viewModel: ViewModel

@PreusslerBerlin & vs Java DI

@PreusslerBerlin Injection (any Java DI) @Inject lateinit var binder :
BinderFactory

@PreusslerBerlin Injection (Kodein) val binder : BinderFactory by kodein.instance()

@PreusslerBerlin Injection (Koin) val binder : BinderFactory by inject()

@PreusslerBerlin Dependency Injection or Service Locator?

@PreusslerBerlin Injection

@PreusslerBerlin Service Locator

@PreusslerBerlin Martin says: • both provide fundamental decoupling • In
both: application code is independent of the concrete implementation

@PreusslerBerlin Martin says: important difference is about how implementation is
provided • With service locator: the class asks for it • With injection there is no explicit request • With a Service Locator every user has a dependency to the locator

@PreusslerBerlin Martin says: So the decision between locator and injector
depends on whether that dependency is a problem.

@PreusslerBerlin Injection (Koin) val binder : BinderFactory by inject()

@PreusslerBerlin inline fun <reified T : Any> get(…): T =
… resolveByClass(T::class, …) Behind by inject:

@PreusslerBerlin The android problem • Normally constructor injection preferred •
On Android: framework classes need field/setter injection: Activity, Service, Fragment, Views Android central

@PreusslerBerlin Bindings

@PreusslerBerlin Bindings (Dagger, Toothpick) bind(API::class.java) .to(DummyApi::class.java) bind(BinderFactory::class.java) .toInstance(ViewBindingFactory())

@PreusslerBerlin Bindings (Toothpick Ktx) bindClass<API>(DummyApi::class) bindInstance<BinderFactory> { ViewBindingFactory>() }

@PreusslerBerlin Bindings (Kodein) bind<API>() with provider { DummyApi() } bind<BinderFactory>()
with singleton { ViewBinderFactory() }

@PreusslerBerlin Bindings (Koin) factory<API>{ DummyApi() } single<BinderFactory>{ ViewBindingFactory()}

@PreusslerBerlin Let’s talk about constructors

@PreusslerBerlin The annotated contructor issue • @Inject to mark constructor
is handy: class HomeViewModel @Inject constructor(val resources: Resources) • Violates separations of concerns • Violates clean architecture : DI should stay in outermost layer • Providers are the cleaner solution anyway (part of JSR330)

@PreusslerBerlin The annotated constructor issue • @Inject to mark constructor

@PreusslerBerlin The annotated contructor issue • @Inject to mark constructor

@PreusslerBerlin Examples (Toothpick Ktx) bindProvider(HomeViewModelProvider::class) class HomeViewModelProvider @Inject constructor(val resources
Resources) : Provider<HomeViewModel> { override fun get() = HomeViewModel(resources) }

@PreusslerBerlin Examples (Kodein) bind<HomeViewModel>() with provider { HomeViewModel(instance()) }

@PreusslerBerlin Examples (Koin) factory { HomeViewModel(get())}

@PreusslerBerlin Should we change to Koin/Kodein?

@PreusslerBerlin Boilerplate • Manual dependency injection has zero fixed cost
…scales poorly. • A service locator has some overhead in creating it, inserting the bindings, and then doing the lookups. • A dependency injector has a lot of fixed overhead in setting up an injector hierarchy (components in Dagger 2) and all the modules to provide bindings. https://www.reddit.com/r/androiddev/comments/8ch4cg/dagger2_vs_koin_for_dependency_injection/

@PreusslerBerlin Boilerplate • if you're going to write a serious
app with hundreds of bindings and hundreds of injected types with a deep graph of types then you're better off with a proper injector that generates the code that you otherwise manually write worth Koin. https://www.reddit.com/r/androiddev/comments/8ch4cg/dagger2_vs_koin_for_dependency_injection/ only true when using @ constructor

@PreusslerBerlin Where are we? • Choice depends on scale •
Hard dependency to SL framework • Performance comparable • Compile-time validation

@PreusslerBerlin Compile time validation? • Whose job is it to
manage the nulls. The language? Or the programmer? • Defects are the fault of programmers. It is programmers who create defects – not languages. • And what is it that programmers are supposed to do to prevent defects? • TEST! https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html

@PreusslerBerlin Tests

@PreusslerBerlin Tests • Koin has dryRun()to verify the module setup
• Have a test spawning up all fragments/activities to see if breaking change was added

@PreusslerBerlin Access the real thing in test (Koin) dependencies {
testImplementation 'org.koin:koin-test:1.0.0‘ } val preferences: Persistence by inject()

@PreusslerBerlin Override for tests (Koin) val resources = mock<Resources>() @BeforeEach
fun setup() { StandAloneContext.loadKoinModules( module { factory(override = true) { resources } }) }

@PreusslerBerlin Override for tests (Koin) val resources by inject() @BeforeEach
fun setup() declareMock<Resources>() }

@PreusslerBerlin Features you probably want to have

@PreusslerBerlin Tags/Names • Dagger/Toothpick: @Named(„api1“) • Koin: factory <Api>(" api1
") { …. } by inject (name = „api“) • Kodein bind<Api>(tag = “api1") with … by kodein.instance(tag = “api1")

@PreusslerBerlin Scoping • Toothpick Ktx: scope(SCOPE, { module { //
bindings • Koin: module { scope(SCOPE) { // bindings }} • Kodein Kodein { bind<API>() with scoped(SCOPE)…

@PreusslerBerlin Scoping • Toothpick Ktx: Toothpick.openScopes(APP_SCOPE, SCOPE).apply { installModules(createPlayerModule()) }
• Koin: by inject() • Kodein: by kodein.factory()

@PreusslerBerlin Other Features • Android module • Koin has direct
support for architecture components • Multi modules support • Non JVM Kotlin projects Koin ✓ Kodein ✓

@PreusslerBerlin Transition flickr.com/photos/anca_bejinaru/5234037866/

@PreusslerBerlin Transition • Depends on how well you hide the
DI in your project • Replace all @inject with manual binding calls will be painful flickr.com/photos/anca_bejinaru/5234037866/

DI in your project • Replace all @inject with manual binding calls will be painful (could be a first step) flickr.com/photos/anca_bejinaru/5234037866/

DI in your project • Replace all @inject with manual binding calls will be painful • Kodein helps with reflection based javax.inject implementation flickr.com/photos/anca_bejinaru/5234037866/

DI in your project • Replace all @inject with manual binding calls will be painful • Kodein helps with reflection based javax.inject implementation (keeps your project running) flickr.com/photos/anca_bejinaru/5234037866/

@PreusslerBerlin Transition • Might end up in awkward readable syntax
factory { HomeViewModel(get(), get(), get(), get(), get(), get()) } flickr.com/photos/anca_bejinaru/5234037866/

@PreusslerBerlin Transition • Might end up in awkward readable syntax
• Actually a code smell • Reflective approach available now factory { build<HomeViewModel> } flickr.com/photos/anca_bejinaru/5234037866/

@PreusslerBerlin Sum up • Koin: • Pro: lightweight, easy •
Contra: Limited • Kodein • Pro: Feature rich • Contra: Too many features • DI is simple concept, keep it simple!

@PreusslerBerlin Give it a try • Kodein https://github.com/Kodein-Framework/Kodein-DI • Koin
https://github.com/Ekito/koin • Toothpick KTX https://github.com/sporttotal-tv/toothpick-kotlin-extensions

@PreusslerBerlin More • https://www.martinfowler.com/articles/injection.html • https://android.jlelse.eu/moving-from-dagger-to-koin-simplify-your- android-development-e8c61d80cddb • http://fragmentedpodcast.com/episodes/133/ flickr.com/photos/139228535@N05/40102368982

To inject or not inject @PreusslerBerlin We are hiring iOS
developer /Backend lead / Designer

To inject or not to inject: Dependency Injectio...

To inject or not to inject: Dependency Injection with Kotlin (Droidcon Nairobi)

More Decks by Danny Preussler

Other Decks in Programming

Featured

Transcript