Dagger2活动范围，我需要多少个模块/组件？

Question

我对自定义范围有几个问题：

1. 我使用MVP架构，我需要为不同的活动注入不同的演示者。为此，我创建了@ActivityScope。这是否意味着我必须为每个活动创建一个单独的模块/组件？
2. 如果我仍然负责创建和释放这些依赖项，那么自定义范围注释的目的是什么？不确定我是否正确，但我可以在我的所有模块/组件中使用@ Scope123，但它不会有任何区别。

Answer 1

  

这是否意味着我必须为每个活动创建一个单独的模块/组件？

是。没有。

在至少，如果要提供活动范围的依赖关系，则需要为每个活动创建一个新的组件 object ，例如Activity本身， LoaderManager或类似事物，因为范围只会与活动一样长。

您是否需要为每个活动提供模块和组件的问题在很大程度上取决于您的体系结构。您也可以制作通用ActivityModule，提供您可以重复使用的模型，演示者和视图。

只有一个Component也可以。如果只需要活动的基本依赖项，如LoaderManager或Activity本身，那么您可以编写一个ActivityModule来提供这些基础对象。然后，您可以将此模块与组件一起使用以提供依赖项。 如果您的Presenter（及其依赖项）可以通过构造函数注入创建，那么可以使用单个组件和模块来完成所有活动。

如果您的演示者和视图是实现的接口，则需要创建一个提供实际实现的模块。

  

如果我仍然负责创建和发布这些依赖项，那么自定义范围注释的目的是什么？

范围用于管理更容易的依赖关系。如上所述，活动范围随着活动被破坏而消亡。通过拥有这些范围的依赖关系，您可以确定没有任何东西取决于您的活动具有更高的范围/生命周期并且可能导致内存泄漏。

另外，我喜欢将它视为可以热插拔并且只是扔出去的依赖关系。一个很好的例子是@UserScope，它将保存用户数据，他的登录，会话数据，...... 如果我切换用户，我只需要用一个或更少的用户范围抛出所有内容（关闭活动，删除UserComponent），关于用户的一切都消失了。下一个可以登录，副作用的风险很低。

范围主要是编译时间检查，帮助您将层次结构带入依赖项，因为所有编译器都会检查其中没有循环，并且没有任何内容请求来自范围的依赖项＃＆＃ 39; t access。

Answer 2

1. 最简单的方法是创建一个应用程序级组件，希望您提供每种类型的演示者。问题是你将所有你所有的项目都放在同一级别，这有点难看。 好的方法是为活动创建一个模块，该活动注入当前活动/片段的依赖关系

2. 使用@ActivityScope或任何其他只是显示模块的生命周期与@Singleton不同，只要它不是单例，考虑你的模块将会死于创建它的活动。