Dagger1迁移Dagger2指南

原文地址:https://google.github.io/dagger/dagger-1-migration.html

Dagger 1是由squre开发,而Dagger2是Dagger1的分支,由谷歌公司接手开发,目前的版本是2.10。虽然Dagger 1和Dagge 2在许多方面是相似的,但一个不是另一个的替代。在由Dagger 1向Dagger 2迁移时,由于两种版本之间的API和概念差异,还是不是不得不慎重,于是翻译了这篇指南。

注射类型

Dagger 2继续依靠JSR 330来声明注入站点。Dagger 2继续支持Dagger 1(字段和构造器)支持的所有类型的注入,但Dagger 2也支持方法注入。Dagger 2不支持静态注入。

框架类型

Dagger 2还继续支持JSR 330和Dagger特定的框架类型。Provider、Lazyand MembersInjector都保持相同的行为。

@Modules

Dagger 2 @Modules与Dagger 1 @Modules非常相似,但是减少了许多配置复杂性,这对于某些模块是一个难点。 对于大多数用户而言,迁移只是删除属性。

@Module 属性

两者之间的主要区别源于图形验证不再以每个模块为基础的事实。 在Dagger 1术语中,Dagger 2模块都被声明为complete = false和library = true,但是由于对于验证完成是最容许的,所以库和addTo可以在迁移时被删除。

模块不再是声明可以通过调用代码访问哪些类型的机制。 因此,注入和静态注入属性也可以被删除。

Dagger 2不支持覆盖。 覆盖简单测试假的模块可以创建模块的子类来模拟该行为。 使用覆盖并依赖依赖注入的模块应该被分解,以便覆盖的模块被替代地表示为两个模块之间的选择。

剩下的property,include,仍然是组合模块的主要工具,并继续像往常一样。

@Provides 方法

@Provides 方法具有完全相同的语义。

创建图

完整的依赖注入图的构建机制是Dagger 1和Dagger 2之间的主要区别。在Dagger 1中,该图由ObjectGraph反射构成,但在Dagger 2中,它由@ Component-annotated完成, 在编译时生成实现的用户定义类型。 从ObjectGraph到@Component的转换可能是任何迁移的大部分工作。

声明组件

为了实例化ObjectGraph,用户需要提供模块类或实例的列表。 典型的调用可能如下所示:

ObjectGraph.create(ModuleOne.class, ModuleTwo.class, new ModuleThree("hello!"));

组件单独定义图形来实例化它。 组件定义需要相同的信息,而是在@ Component的modules参数中声明。 名为MyComponent的等效组件将如下所示:

@Component(
  modules = {
    ModuleOne.class,
    ModuleTwo.class,
    ModuleThree.class,
  }
)
interface MyComponent {
  /* … */
}

如前所述,@ Module.injects是用于声明可以从Dagger 1中的图形中检索哪些对象的机制。在Dagger 2中,组件接口上的方法具有相同的作用,但是以静态,类型安全的方式。 可以通过组件方法访问图中的任何绑定。

如果上面的ObjectGraph的调用者是要求一个Foo.class和一个Bar.class,并将成员注入到Baz的一个实例中,以下组件方法将为这些角色提供服务:

@Component(
  modules = {
    ModuleOne.class,
    ModuleTwo.class,
    ModuleThree.class,
  }
)
interface MyComponent {
  /* Functionally equivalent to objectGraph.get(Foo.class). */
  Foo getFoo();
  /* Functionally equivalent to objectGraph.get(Bar.class). */
  Bar getBar();
  /* Functionally equivalent to objectGraph.inject(aBaz). */
  Baz injectBaz(Baz baz);
}

有关定义组件的更多细节可以在Component javadocs中找到。

实例化组件

最后的任务是实例化组件实现。 Dagger 2注释处理器生成与使用Dagger添加的组件接口具有相同名称的实现。 对于MyComponent接口,生成的组件命名为DaggerMyComponent。

对于没有要传递的模块实例的组件实现,实例化组件就像调用create()方法一样简单。 在此示例中,ModuleThree作为实例传递,因此将使用组件的构建器。

MyComponent myComponent = DaggerMyComponent.builder()
    // ModuleOne and ModuleTwo don't need to be set explicitly
    .moduleThree(new ModuleThree("hello!"))
    .build();

有关定义组件的更多细节可以在Component javadocs中找到。

作用域

Dagger 1只支持一个作用域:@Singleton。Dagger 2允许用户进行任何格式正确的作用域注释。有关定义组件的更多细节可以在Component javadocs中找到。

子图

Dagger 1提供了ObjectGraph.plus作为从现有图形创建新图形的机制。 Dagger 2有两种组合图形的机制,每种都有自己的优点,但子组件是最直接的模拟。 定义子组件与定义组件非常相似,组件通过接收必要模块的工厂方法与子组件相关联。 如果Dagger 1代码通过调用objectGraph.plus(new ChildGraphModule(“child!”))创建了一个新的子图,下面的定义和调用将具有相同的效果。

@Component(/* … */)
interface MyComponent {
  /* … */

  /* Functionally equivalent to objectGraph.plus(childGraphModule). */
  MySubcomponent plus(ChildGraphModule childGraphModule);
}
MySubcomponent mySubcomponent = myComponent.plus(new ChildGraphModule("child!"));

子组件在@Subcomponent和Component javadocs中进一步描述。

可空性

与Dagger 1不同,Dagger 2执行隐式空检查,除非存在@Nullable注释(来自任何包)。 在迁移期间,应用程序可能必须注释注入站点,并提供其选择的@Nullable的方法。 任何空值不匹配都将报告为编译时错误。

你可能感兴趣的:(Dagger,Android,dagger2,dagger1,迁移)