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.