从实例出发理解Dagger2（五）

上一片文章最后提到的容易让人误解的@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报错。那么怎么解决这个问题呢？有两种方法：

1. @Named 直接贴代码：
   
   

   image.png
   
   @Named 后面的activity_context就是在告诉Dagger，这是一个叫activity_context的Context。
   在要使用的context前面加上相同的注解即可，这样Dagger就知道具体使用的是哪个Context了。编译时就能 正常通过了。
   
   

   image.png

大家发现没有，这样把字符串加来加去不仅麻烦还容易出错。那有没有其他方法呢？来，看下面一条。

2. @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