上一篇Dagger2入门学习之MVP项目整合(上)的最后我们列举了Dagger的关键注释，其中@Singleton和@Scope还没有接触，接下来我们来先看看这两个标签的使用。

@Singleton

类似于SharedPreferences对象，我们可能在整个App的生命周期中只需要一个单例，而不需要每次都通过application.getSharedPreferences(“spfile”, Context.MODE_PRIVATE)获得新的对象，那么怎么办呢，我们只需要在你需要单例的对象提供方法上加一个注解@Singleton ,类似这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

@Module
public class AppModule {

    private MyApplication application;

    public AppModule(MyApplication application) {
        this.application = application;
    }

    //全局单例SharedPreferences
    @Provides
    @Singleton
    SharedPreferences provideSharedPreferences() {
        return application.getSharedPreferences("spfile", Context.MODE_PRIVATE);
    }

    @Provides
    MyApplication provideApplication() {
        return application;
    }
}

只需要一个@Singleton,无论我们在多少个Activity容器中通过@Inject获取这个SharedPreferences对象的实例，该对象都是同一个对象，从而实现了全局单例的效果。

阅读更多

Dagger基础回顾

在前面一篇Dagger2基础传送门我们得出了一个结论。

1. 若一个类（Xx）的构造函数被@inject标注，则该类编译时会产生Xx_Factory.
2. 若一个类（Xx）的成员变量被@inject标注，则该类编译时会产生Xx_MembersInjector.
3. @Component标注的接口（Xx）在编译时生成DaggerXx,负责将上面两个联系起来。

下面我们通过前面提到的这个例子再来回顾一下这个结论

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

/**
 * Created by 水寒 on 2017/11/16.
 */

public class Province {

    @Inject
    public City city;

    @Inject
    public Province(City city) {
        this.city = city;
    }

    public String showAddress() {
        return "四川省" + city.show();
    }
}

Dagger2会在编译过程中生成对应的依赖项，这些依赖项在Android Studio该路径下，如图所示：

Dagger依赖生成文件目录

阅读更多

最近在重新搭建android工程听到dagger2这个框架，然后去Github上看了一下，天啊！2w多的star，呃，是应该看一下这玩意是个什么东西了，竟然这么火。

百度了一下大概看了一下其他关于dagger的文章大概知道这玩意是干啥的了。

Dagger2是Dagger的升级版，是一个依赖注入框架，现在由Google接手维护。

我们要搞清楚这个框架怎么用必须先知道什么是依赖注入和依赖注入的好处。

什么是依赖注入

依赖注入是面向对象编程的一种设计模式，其目的是为了降低程序耦合，这个耦合就是类之间的依赖引起的。

举个例子：我们在写面向对象程序时，往往会用到组合，即在一个类中引用另一个类，从而可以调用引用的类的方法完成某些功能,就像下面这样.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

public class ClassA {
    ...
    ClassB b;
    ...
    public ClassA() {
        b = new ClassB();
    }

    public void do() {
        ...
        b.doSomething();
        ...
    }
}

这个时候就产生了依赖问题，ClassA依赖于ClassB，必须借助ClassB的方法，才能完成一些功能。这样看好像并没有什么问题，但是我们在ClassA的构造方法里面直接创建了ClassB的实例，问题就出现在这，在ClassA里直接创建ClassB实例，违背了单一职责原则，ClassB实例的创建不应由ClassA来完成；其次耦合度增加，扩展性差，如果我们想在实例化ClassB的时候传入参数，那么不得不改动ClassA的构造方法，不符合开闭原则。

阅读更多