上一片文章最后提到的容易讓人誤解的@Singleton希望大家要記住。 等等，說起來好像上上上篇文章里還有一個抬杠還沒解決啊。就是如果在Module里兩個Provider返回的類型是相同的，Dagger怎么知道使用哪個Provider提供的依賴注入呢？而且如果你真的在Module的兩個Provdier中返回相同的類型，在編譯時是會報錯的！因為Dagger也不知道使用哪個，只好報錯：你TM想要我用哪個？說清楚！
這時就會引出另外兩個注解啦---Qualifier和Named！
舉個常見的例子，就是通過Dagger提供Context。除了Application可以提供Context外，Activity也可以提供Context。代碼如下：
image.png
還記得
@Module、@Provides、@GithubApplicationScope是什么意思嗎？不記得可以回去翻翻上面的文章哦。問題來了，如果把ActivityModule和ContextModule放到一起，Dagger在編譯的時候就會因為不知道要用哪個Context報錯。那么怎么解決這個問題呢？有兩種方法：
-
@Named直接貼代碼：
image.png
@Named后面的activity_context就是在告訴Dagger，這是一個叫activity_context的Context。
在要使用的context前面加上相同的注解即可，這樣Dagger就知道具體使用的是哪個Context了。編譯時就能 正常通過了。
image.png
大家發現沒有，這樣把字符串加來加去不僅麻煩還容易出錯。那有沒有其他方法呢？來，看下面一條。
-
@Qualifier
在看@Qualifier之前讓我們先看看@Named的源碼：
image.png
咦？這個@Named不就是一個@Qualifier嘛！那自己自定義一個專用@Qualifier得了。代碼如下：
image.png
這樣就不需要把字符串拷來拷去了，而且方便閱讀和理解代碼。具體的用法見下面代碼：
image.png
image.png
好了，抬杠圓滿結束。讓我們開始下面的內容！
相關文章：
從實例出發理解Dagger2（一）
從實例出發理解Dagger2（二）
從實例出發理解Dagger2（三）
從實例出發理解Dagger2（四）
從實例出發理解Dagger2（五）
從實例出發理解Dagger2（六）
從實例出發理解Dagger2（七）
參考資料：https://www.youtube.com/watch?v=WAENNp2wxbQ&index=5&list=PLuR1PJnGR-Ih-HXnGSpnqjdhdvqcwhfFU
