My issue with the Android-specific pattern is, if you use their AndroidInjection
class, there is no way to members inject other objects besides Activities
/Fragments
/custom views/adapters, except with the Application Component. This is because you cannot get a reference the the Subcomponent
(AndroidInjector
) used to inject Activities
/Fragments
.
This makes injecting Dialogs (if you use DialogFragments
).
The AndroidInjection
class seems to support just the core Android types.
What follows is not an answer to your question, but an explanation why you shouldn't be asking this question at all.
You should avoid injections into custom Views
in general. The reasons for this are listed in this article.
Advantages of using Method Injection in this case [injection into custom Views] are:
- Dependencies will need to be propagated from top level component (Activity or Fragment)
- Method Injection does not open door to Single Responsibility Principle violation
- No dependency on the framework
- Better performance
The first advantage might come as a surprise because propagation from top level component is harder than adding annotation to fields, and involves more boilerplate code. This is surely a bad thing, right?. Not in this case. In fact, there are two good aspects associated with such a propagation of dependencies. First of all, the dependencies will be visible at the top level component. Therefore, just by looking at e.g. Fragment‘s fields, the reader of the code will immediately understand that this Fragment shows images. Such optimizations for readability makes the system more easily maintainable in the long term. Secondly, there are not many use cases in which sub-classes of View need additional dependencies. The fact that you need to actually work in order to provide these dependencies will give you a bit of time to think about whether providing them is a good design decision to start with.
The second advantage is related to collaborative construction. You might be very experienced software engineer yourself, but you’ll probably have also less experienced teammates. Or it is possible that you’ll leave the project one day, and the guy who will take over will not be as good as you. By injecting one single dependency using a framework, you basically open a door for other injections. Imagine that some data from SharedPreferences becomes required in custom View in order to e.g. fix a bug. One of the less experienced developers might decide that it is a good approach to inject SharedPreferences into custom View directly. Doing this violates Single Responsibility Principle, but that developer might not even be aware of such a concept. Therefore, in the long term, such injection “backdoors” can reduce design quality and lead to long debug sessions.
The third advantage of using Method Injection with custom Views is that you don’t couple the View to dependency injection framework. Just imagine that few years from now you (or some other poor guy) need to replace the framework. The fact that you’ll probably have tens of Activities and Fragments to start with will make your life miserable. If you’ll have additional tens or hundreds of custom Views to handle, then it might bring you into suicidal mood.
The last (but not least) advantage is performance. One screen can contain one Activity, several Fragments and tens of custom Views. Bootstrapping this number of classes using dependency injection framework might degrade application’s performance. It is especially true for reflection based frameworks, but even Dagger carries some performance cost.
In addition, I advice to avoid the new injection method that involves AndroidInjection
class. It is discussed in this video tutorial.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With