Dagger2 + framework
Today I want to introduce to you some thoughts on using dagger and MVP framework, hoping to improve our efficiency in using dagger and MVP framework, so that we can use dagger without worrying about the set of module and component of dagger, while using MVP framework, Auto-injection instead of maintaining an instance of Presenter allows us to concentrate on the business code. This is the Dagger2 + framework introduced today.
Background:
Dagger can be used for decoupling in large projects. I’m sure you’ve all heard of it, especially dagger2, which has been taken over by Google. Dagger2 uses compile-time generated code to replace the original reflection scheme without affecting the performance of the original application. Dagger has obvious advantages, but also obvious disadvantages:
1) It’s hard for beginners to understand. The old driver did not say, must understand at a glance. However, it is easy for beginners to get around the door. The four internal file classes generated by each annotation are easy for beginners to get confused, and there are a lot of articles on the web about how to get started, explain, and analyze dagger2. Those who are interested will read on and on until they understand that annotations are not modifying the source file. Those who are impatient will give up.
2) Every time a new object (such as an activity or fragment) needs to add the corresponding code to the Component and Module. If there are too many objects, the Component and Module will have too many things.
To address these shortcomings, Dagger2+ framework fully wraps dagger so that the user with dagger is unaware of the existence of dagger, thus achieving complete decoupling of dagger. The custom annotation automatically generates the required component, module and other dagger files, and then generates the dagger injection file class using the dagger recognition to remove the generated Component and module files. This framework combines MVP architecture to decouple Model, View layer and Presenter layer, so that the whole architecture is clear and less coupled.
1. Introduction to the Framework Layer:
2:
What to do:
1) Require java-provided annotation framework (just like the Dagger Module keyword), we provide AutoWire keyword to automatically identify objects that need decoupling (such as activities).
2) In our AutoWireProcessor, automatically detect classes marked with AutoWire annotations, judge whether they are activities or fragments, and then automatically generate diModule. Java and dicomponent. Java files for such classes.
Dimodule.java = diModule.java = dimodule.java = dimodule.java = dimodule.java
The specific part of generating the provider is as follows:
In the same way we can automatically generate DIComponent files. Final generated file:
You can see that it’s no different from our own handwriting, but it’s automatically generated, it’s automatically maintained, it’s not human error, it saves time, and that alone is exciting enough!
3) By eliminating the need to add methods to component and Module every time we create a new object, we can save ourselves a cup of coffee. So there is one more step to the final complete dagger isolation wrapper: the necessary inject invocation with dagger, without which injection cannot be completed with dagger. Here we cleverly use the base design combined with the instanceof keyword to automatically inject every object for everyone (note: instanceof is compile-time, so there will be no performance problems).
Key generated parts of the code are:
BaseAutoInjectActivity is automatically generated:
4) Finally, on our BaseCatActivity, we inherit this BaseAutoInjectActivity, and BaseAutoInjectActivity inherits BaseRxActivity, Automatically inject all activities by calling autoInject in onCreate() of BaseRxActivity.
4) Finally, on our BaseCatActivity, we inherit this BaseAutoInjectActivity, and BaseAutoInjectActivity inherits BaseRxActivity, Automatically inject all activities by calling autoInject in onCreate() of BaseRxActivity.
At this point, we have completed the initial design of the entire framework, completely isolating the dagger while further facilitating the development of the MVP architecture. See Github: Dagger2+ Framework for detailed code. Welcome star or fork.
NEXT: The Service annotation will be supported on this framework, and the annotated classes will automatically support singletons, eliminating the need for extra fixed code to be null every time getInstance is judged. And you can use it as long as you tag a class with @service. Use inject on the same class or parent class without following the original Dagger2.
Any comments are welcome