Dagger2 use the correct posture.

Dagger2 Use the correct posture.

The previous article "[Dagger2 This introduction will not have to give up]" (http://blog.csdn.net/u012943767/article/details/51897247 "introduced some of the Dagger2 of some shallow use, I think it is very suitable for the introduction of the Dagger2 of the silly explanation, and later found that some of the content is not careful enough, some details are not explained in detail. After referring to the following three articles, add some of the previous content. Android:dagger2 let you put it down-basic dependency Injection Framework Android:dagger2 let you put it down-focus on the concept of interpretation, integration Android:dagger2 let you love-the end of the chapter

The above three articles for Dagger2 's ideas are very clear, and for Dagger2 made an abstract concept, some of the contents of this article is also excerpted from the above article.

Have not seen the "Dagger2 this introduction will not give up" may not be conducive to reading the content of this article:

The content of this article also does not relate to the internal principle of Dagger2, but to the previous article to do some knowledge supplement, so as to better use Dagger2 thinking, Dagger2 two ways to provide injection instances Why Activitycomponent to provide a inject method. The use of scope, how to implement a single case. The role of the qualifier qualifier and its use. to clarify the idea, Dagger2 two ways to inject an instance.

It was previously said that the way to provide injected instances is by writing moudle, and by providing some providexxx () methods, and then injecting these objects through component.
In fact, there is a way to implement object injection in Dagger2, this method is relatively simple. Suppose we need to inject an object of Class A, we just need to add the @inject annotation to the Class A constructor, and then provide a way to get an instance of a directly in the component. The code is as follows:

public class a{

    @Inject public
    A () {
    }
}


//In  xxxcomponent

a geta ();

Then we can get the A object in the place where we need to inject the A object (Activity) and call the Geta () method with component.

In this case, there may be some doubt, the Class A is a simple object, if a need to pass in the constructor function parameters. In fact, the principle is similar to the previous article, these parameters will be obtained according to the dependent component or the providexxx () method provided in the current component module.

There are two ways in which Dagger2 can provide dependency injection in total. In fact, after testing, Dagger2, when encountering @inject-modified member variables, will look for a constructor that contains @inject if the object is provided in component and cannot be found.

The process of dependency injection for the entire Dagger2 is as follows:

Step 1: Find out if there is a method for creating the class in module.
Step 2: If there is a Create class method, see if the method exists parameter
    Step 2.1: If there is a parameter, proceed from step 1** to initialize each parameter
    steps 2.2: If there is no argument, initialize the class instance directly, once the dependency injection ends
Step 3: If the Create class method does not exist, look for the constructor of the inject annotation to
           see if the constructor has a parameter
    step 3.1: If there is a parameter, initialize each parameter
    sequentially starting with step 1** Step 3.2: If there is no parameter, initialize the class instance directly, once the dependency injection ends

why Activitycomponent to provide a inject method

First, after my testing, when I add @inject annotations to some of the members that need to be injected in daggeractivity, Dagger2 generates something Daggeractivity_membersinjector, This is the key class to inject the member variables, involving some more in-depth content, we do not go into the operating mechanism here. We just need to know that when we need to inject some member variables, we have to provide a method in Activitycomponent:

void inject (daggeractivity daggeractivity);

And this method is called at initialization time to inject successfully. As for this method inject is the official recommended name, we can not use this, but using inject words better understand it. It is worth noting that the parameters of this method must be accurate, such as daggeractivity need to inject, we need some daggeractivity here, can not be written baseactvity or activity, otherwise it will inject failure. Because the internal principle is to inject this parameter, it is obvious that the content that needs to be injected in daggeractivity does not exist in baseactivity or activity. the use of scope, how to implement a single case.

The scope of the puzzle is also a bit difficult to understand, where we have used the scope. In our appcomponent added a note for the @singleton, @Singleton is a scope, it is said to be able to achieve a single yo ... In this way, a singleton pattern is implemented. I was just beginning to understand that. I didn't know this was the case until I read the article a few times.

In fact, @sinleton does not have the ability to create a singleton, so the dependency injection provided in appcomponent is how to implement a single case. In fact, this principle is very cheap single.

The module first provides a way to create an instance, then the module is managed in Appcomponent, and finally Appcomponent is instantiated in the custom Applicaiton .

This instantiation is one of the most important. Just being instantiated once, that's not a single case. It's so simple.

Perhaps some of the children's boots were not happy at the time, since this has been achieved in a single case, then the @singltop will come. It's not superfluous.

In fact, @singletop there are some functions, the first on the one hand can let you face to know that this is a single case, and secondly this @singletop can better manage the relationship between Modlue and component.

Dagger2 need to ensure that the component and module are matched, it is necessary to use this annotation.

Why do you say that, the person who read the previous article will know that I have defined a activityscope, and my previous explanation is that Activityscope is to correspond to the life cycle of the activity (it was not understood at that time, is this scope really so magical, Declaring a activityscope will allow the injected object to be consistent with the activity life cycle, which is obviously wrong. Why do you need this scope? The reason is because I have @singletop in Appcomponent, Activitycomponent relies on appcomponent, so we need to use a scope to match their relationship, otherwise it will be error during compilation. Not that Activityscope can make the instance and activity life cycle consistent. is consistent with the activity life cycle because activitycomponent is generating instances in activity. (The specific Dagger2 how to protect this, and not in-depth study). the role of the Qualifier qualifier and its use.

This is also a very powerful note, first of all, why need to use such a thing, said before, in the module of the provide method is actually based on the return value to identify. But suppose I need to pass in different construction parameters according to different requirements, how to distinguish. For example: A presenter, maybe he has two constructors, corresponding to different requirements, in this case, the return value of the Provide method is presenter, then you need to use qualifier. How to use it specifically.

First, declare an annotation to be decorated with @qualifier, and then add it to the point where it needs to be distinguished, and here is an example code:

@Module public
class Appmodule {
    private final app app;

    Public Appmodule (App app) {
        This.app = app;
    }

    @Provides
    @Singleton
    @ForApplication
    Context provideappcontext () {
        return app;
    }

    @Provides
    @Singleton
    prefser provideprefser (@ForApplication context context) {
        return new Prefser ( context);
    }

    @Provides
    @Singleton
    accountmanager Provideaccountmanager (@ForApplication context context) {
        return Accountmanager.get (context);
    }

First add an annotation @forapplicition in the provide, and then mark it again where you need to use the context. This assumes that there are other context where the activity is provided and where the conflict occurs, Dagger2 can also find the context of this applicaiton accurately. Summary

Here to dagger the overall use of the way to make some additions, there is no source from the point of view to understand Dagger2, the next article will be combined with Dagger2 generated code for discussion, only to understand the operating mechanism, we can use it handy.