Some time ago, at Google I/O 2015 Extended in Tech Space in Cracow I had a presentation about dependency injection with Dagger 2. In a time of preparation I realized that there is a lot of things to talk about and there is no chance to cover everything in dozen of slides. But it could be a good entry point to start the new series of posts – Dependency Injection in Android. Continue reading “Dependency injection with Dagger 2 – Introduction to DI”
Dependency injection frameworks in Android – is there anyone who has never heard about it? At almost every Android dev conference someone talks about this software design pattern. I am a big fan of DI but there are also people who complain about it. The main reasons why they do this are:
- dependency injection frameworks are slow – well, it was completely true a couple years ago in times of RoboGuice, when the whole dependency graph were created and validated in runtime. Now, when we have Dagger it’s not (completely) true. In Dagger 1 much of work (graph validation) is done in compilation time and objects creation process is done without reflection (it’s worth mentioning that recently presented Roboguice 3 also does much of his work in compile-time). Yes, it’s still a bit slower than hand-written code, but in average Android app it is almost imperceptible.
- DI frameworks requires a lot of boilerplate – it is true and it isn’t. Yes, we have to create additional code for injections, classes which provides dependencies etc. but thanks to them we don’t have to deal with objects constructors every time when we need them. Yes, in small projects DI frameworks are overkill, but benefits of dependency injection increase when you start dealing with scale.
- Other stuff like poor traceability, hard to read generated code etc.