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

我有几个关于自定义范围的问题:

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

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

是。 和不。

如果要提供活动范围的依赖关系(如Activity本身, LoaderManager或类似的东西), 至少需要为每个活动创建一个新的组件对象 ,因为范围只会与活动一样长。

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

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

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

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

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

此外,我喜欢将它视为可以热插拔并且只是“丢弃”的依赖关系。 一个很好的例子是@UserScope ,它可以保存用户数据,登录,会话数据……
如果我切换用户,我只需要用一个或更少的用户范围抛出一切(关闭活动,删除UserComponent),关于用户的一切都消失了。 下一个可以登录,副作用风险低。

范围主要是编译时间检查,可帮助您将层次结构带入依赖关系 ,因为所有编译器都会检查其中没有循环,并且没有任何请求来自它无法访问的范围的依赖关系。

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

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