
Dependency injection on Android with dagger-android and Kotlin - albertgao
http://www.albertgao.xyz/2018/04/18/dependency-injection-on-android-with-dagger-android-and-kotlin/
======
parmesan
Dagger2 is great when you have it setup, generating the dependency graph
during compilation makes it lightning fast during execution. I also like the
error messages, as long as you can read Java stack traces all the info for
solving errors are in there - I've never seen an unsolvable situation this
far.

Kapt does bump the _clean_ build time to about 2min, incremental builds take
between 10-60s - although actually launching the app on an emulator/device
adds another 20s.

The cons of Dagger2 that I've experienced since it's launch are; The
documentation and support is useless. You're on your own of you don't use a
3rd party sample project as a template. No one understands scopes and
subscopes, subcomponents etc. The new Android dagger api is arcane and weird,
no one wants to use it.

The Dagger2 team should (if they aren't already) create a Kotlin extension for
it, I believe there are some syntactic optimizations to be offered.

~~~
beder
I wrote a semantics doc to try to help on the documentation front:

[https://google.github.io/dagger/semantics/](https://google.github.io/dagger/semantics/)

It's not intended as a tutorial, so perhaps it won't quite meet your needs,
but if you're curious how all the pieces fit together, it may help.

~~~
albertgao
Interesting, will check this and see what i could add to my blog. But yeah, if
there is an official example of how to use dagger-android, it will be much
helpful. Took me a day to figure it out the whole things and 2 different types
of dagger...

------
christop
Unfortunately, using Dagger for DI with Kotlin requires using the Kotlin
annotation processor, kapt, which is still incredibly slow, and works non-
incrementally.

If you value your build times or your sanity in the slightest, I'd recommend
either severely limiting use of Dagger, e.g. by only using it in certain,
small Gradle modules, or using a different DI solution.

~~~
clumsysmurf
I have only used Kotlin in the context of Android so far, and like the
language — I wish Java had many of these features — but almost find it more of
a pain in the ass than its worth for reasons like this (kapt). At some point,
the build times get so bad I asked myself, am I being more productive having
neat language features X,Y,Z or having 15sec build times (already too long) vs
2 minute build times (unbearable). Its like going from REPL driven development
to something else.

------
the_grue
I tried to learn Dagger for a recent project in a similar setting
(Dagger+Android+Kotlin). Spent some 8 hours, couldn't make it work and gave
up. I suppose, as with most systems, one needs to build up a list of recipes
for solving common problems. But with Dagger I found that notoriously hard for
some reason. Perhaps because it tends to fail silently at runtime or with non-
descriptive errors.

~~~
distances
It really helps to adopt a pattern from another project rather than trying to
build one from scratch if you're new to Dagger. But it's definitely worth it,
I wouldn't do an Android project nowadays without dependency injections.

~~~
the_grue
Yeah, I tried that, but the simple examples didn't do enough for my purposes,
I had to take it further and was never able to get too far.

------
seviu
No need to use kapt to kill compilation times. Data Binding is good enough. We
started using it a year ago and since then instant run does not work and the
debugger takes three minutes to start. Sometimes it mixes generated classes
and we have to do a full clean / rebuild.

Since then we have introduced Kotlin and Dagger and we are super happy with
it.

As with Dagger, the learning curve is pretty steep. Having it working with
modules + activities + fragments + architecture components has been a real
challenge but we love it.

For those who are struggling with Dagger: version 2.10 introduced major
changes for Android, for good reasons, but it made much harder to use and
understand. Many tutorials focus on Dagger < 2.10. You probably should ignore
those.

And for those who are going crazy with compilation times, Jrebel for Android
is a huge time saver. It has an incremental compiler which works with
annotation processors. They will stop supporting it in one year, but even then
I think it is worth using it. Who knows: if enough people buy licenses maybe
they reconsider killing it.

------
aristidb
I've never quite understood the appeal of Dependency Injection. What's wrong
with just using constructors?

~~~
V-2
For simple scenarios DI is obviously an overkill, but as soon as you're
dealing with nested dependencies, you'd end up with either:

* monstrously big constructors (for carrying transitive dependencies)

* lots of @VisibleForTesting code to handle manually injecting various dependencies only for the sake of testing (poor man's DI and generally bad practice)

* a lot of factories (service locator or poor man's DI, essentially)

* code that's hard to unit test due to dependencies being hardcoded.

In other words, you'll either reinvent DI poorly, or give up on testability.

------
mad_tortoise
You should look at kodein, a DI library for kotlin. Works brilliantly.

