Question

我正在尝试在我们的MVP架构应用程序中稍微重构我们的DI混乱，并想出在我的应用程序中没有一个大的ActivityComponent用于所有与活动相关的组件，但是每个活动组件。我最近观看了一个Square演示文稿，他们使用有争议的范围（类似@ActivityScope(ActivityA.class)）来区分这些组件及其注入者，而不必为每个ActivityComponent声明一个单独的范围。

现在我面临一个难题。想象一下，我有一个View组件ViewAB，它有自己的演示者和其他东西。 ViewAB及其内容应在ActivityA和ActivityB之间共享，其中 - 使用新样式 - 应注入不同的组件ActivityComponentA和ActivityComponentB。< / p>

ViewAB现在实际上是一个Android视图，所以我不能总是控制它的创建，所以我必须使用成员注入。由于没有“one”单个活动组件可用于注入，但由于视图应该驻留在“类似活动”的组件中，我认为将它及其依赖项移动到它自己的组件中是个好主意{{1让它“以某种方式”依赖于ViewABComponent和ActivityComponentA。

现在“某种程度上”是我的问题。我认为我基本上有两种可能性，子组件和组件依赖。

我对子组件的试验不成功，因为我认为子组件的构建器依赖于具体的“父组件”，所以我不能轻易地为我的视图创建和注入子组件（我尝试使用） the builder injection that is described here）。这是，当你考虑它时，真的很好，因为子组件按照定义“不完整”，直到它们被附加到某个父组件。但是子组件具有将所有父组件“传播”到子组件以便在那里使用的好概念，因此如果我的子组件中的一件事例如需要注入ActivityComponentB，则可以已由Activity或ActivityComponentA轻松提供。

接下来，我检查了常规组件依赖是否会更好。这里的问题实际上是一切都在很大程度上是分离的，你真的处理单独的图形。将ActivityComponentB和ActivityComponentA依赖项提供给ActivityComponentB不是问题，但如果ViewABComponent本身取决于ViewABComponent和ActivityComponentA提供的内容，该怎么办？即一个简单的ActivityComponentB实例？

那你怎么解决这样的问题呢？以某种方式去和破坏子组件，去寻找真正的依赖，只使用模块将不同的东西放在一起？你最好的做法是什么？

Answer 1

由于您的视图是活动的一部分，因此它也应位于活动范围（和组件）中。因此，拥有自己的组件（无论是某些组件依赖项，还是某些SubComponent）看起来并不真实。

您必须使用ActivityAComponent的依赖关系注入一次视图，并从ActivityBComponent注入一次...为什么不这样做？

这些组件知道使用哪个演示者。他们知道如何注入你的观点。

class ActivityA {
    onCreate() {
        ActivityAComponent component = create();

        component.inject(this); // inject activity
        component.inject(findViewById(R.id.myComplexView); // inject the view
    }
}

一个对象永远不会注入自己。如果您让活动处理注入，您可以提供必要的依赖项。

使用Dagger2的每活动图

1 个答案: