Android：从应用程序中的多个活动访问单个数据库？

Question

我有一个待办事项列表类型的应用程序，它将所有的笔记数据存储在sqlite3数据库中。 应用程序中的每个活动都需要访问数据库以实时编辑数据的不同部分。

目前，我让每个活动都打开自己的DBManager对象（我创建的帮助程序类来管理数据库）。 这会导致问题，我想要一个稍微更全面的访问解决方案，所以我不必继续打开/关闭/创建数据库。

我正在考虑几个选项，并希望听到每个选项的优缺点以及其他建议。

1. 单身人士风格。 有一个包装类，它返回对唯一数据库管理器的引用，因此任何需要它的活动都可以使用它。

2. 静态管理器。 让管理器类完全是静态成员并让它在加载时打开数据库。 任何需要它的人都可以轻松访问（这是每个人）。

3. 合并在1和2之间。我可以创建一个数据库管理器类来初始化数据库的成员单例实例，并且所有数据操作方法都是静态的。 然后我甚至不需要引用单例来访问数据库。 我最喜欢这个解决方案，请指出缺点。

建议？

Answer 1

在我看来，内容提供商很复杂，如果您不与自己的活动共享，则不需要它。 因此，我建议你先使用单例类。 然后，如果您有更多时间或需要它，请转到内容提供商。

我已成功使用单身人士6个月，没有太大困难。 （我小心翼翼地让它成为单身，但只有一个实例加载数据一次）

独生子

• 优点：易于实施
• 优点：因为我使用了一个通用实例，所以我可以轻松实现缓存，从而使应用程序不必经常对数据库执行操作
• 缺点：无法与外部活动共享您的数据

内容提供商

• 优点：您可以与外部活动共享数据
• 优点：您可以与Search API集成
• 缺点：复杂，需要以不同的方式表示您的数据
• 缺点：还有另一个Android API花时间学习

Answer 2

但这会引起问题

哪个......什么？

我想要一个稍微全局的访问解决方案，所以我不必继续打开/关闭/创建数据库。

打开和关闭SQLite数据库很便宜。 尽可能避免静力学和单身。 是什么让你认为你目前的解决方案是坏的？

Answer 3

在Android上执行此操作的推荐方法是使用ContentProvider 。 你的第一个内容提供商可能觉得比它的价值更麻烦，但是一旦你得到了模式，它就不会太糟糕，只要你没有尝试序列化blob。

Answer 4

它是2018年，与此同时Android已经发展。

今天推荐用于此用例的Android架构组件是Android Room。