我在 Android 中使用 Dagger 2 和 Repository 模式，并且被我应该为存储库的依赖项使用的范围以及使用它们的权衡所绊倒。
通常我会为每个功能创建一个存储库。因此，如果我们谈论的是注册功能，那么我将创建一个 RegistrationRepository。RegistrationRepository 将有 3 个不同的数据源，RegistrationNetworkSource、RegistrationDiscSource 和 RegistrationMemorySource。当我的 Activity 向 RegistrationRepository 发出请求时，repo 将创建一个 RxJava observable 并将其返回给 Activity。然后活动可以订阅可观察对象并等待结果。如果 Activity 在 observable 返回结果之前碰巧经历了配置更改，则 observable 可以缓存在一个单独的类中，该类的范围限定为应用程序生命周期，并且在重新创建 Activity 后，它可以获取这个缓存的 observable 并重新订阅它。这就是我的困惑开始的地方。
我的直觉告诉我，我应该将它们的范围限定在 Application 范围内。这样做将允许每个源执行长时间运行的数据获取任务，即使请求来自的 Activity 经历了配置更改，该任务也可以继续。每个应用程序有一个实例，并且它们始终可供使用。听起来不错，但这不会浪费资源吗？如果注册是我的应用程序的第一个屏幕，而用户将其余时间花在 HomeActivity 或其他地方，那么为什么 3 个注册数据源还活着？
这个问题与您之前的问题非常相似，但似乎有一些悬而未决的疑问。
首先，我建议您阅读有关范围如何在此问题的答案中工作的内容。总而言之，作用域并没有什么神奇之处，它们只是帮助您推理从组件创建的对象的生命周期。您从组件生成的依赖项的实例将存在于您维护对它们的引用的位置。通常，您会@PerActivity在单个活动中维护对从组件注入的依赖项的引用。例如，如果您@PerActivity CoffeeComponent有一个CoffeeModule：
@Provides
@PerActivity
public CoffeeMaker coffeeMaker(HotWater hotWater, Beans beans) {
return new DefaultCoffeeMaker(hotWater, beans);
}
然后您通常会期望CoffeeMaker您获得的实例遵循单个 Activity 的生命周期。但是，如果您使用其中一个 CoffeeMaker 实例并在Application类中维护对它的引用，则该实例将一直存在，直到应用程序被销毁。
让我们尝试将其应用于您的问题：
如果我的 observable 被缓存在一个作用域为应用程序范围的类中，这是否意味着 3 个存储库数据源也需要被定义为应用程序范围？
不，库数据源可以作用域@PerActivity，你可以保持对引用Observables在@PerApplication（@Singleton）的范围。此处的其他 Dagger 2 答案已经讨论过Holder为此使用该模式。简而言之，您将创建一个能够Observables在应用程序范围级别存储结果的单例类。当您使用 发出请求时RegistrationNetworkSource，您可以使Holder订阅、接收和缓存结果。您的活动可以从 获取挂起的结果，Holder而不是直接Observable从订阅RegistrationRepository。
其他一些需要考虑的问题：
您需要多长时间才能在配置更改后继续运行的网络请求？考虑使用类似的东西DownloadManager
是装载机不适合你的使用情况比匕首2和Rx-Java的观测量更适合？请注意 Loaders 的文档中的以下内容：
加载器跨配置更改持久保存和缓存结果，以防止重复查询。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句