何时以及如何在 Android 应用程序中将数据保存到数据库

Question

我正在尝试了解从服务器获取数据并将其存储在数据库中并在多标签 Android 应用程序中以片段的形式显示的最佳实践

应用结构如下： 主要活动有 3 个选项卡，每个选项卡分别有一个从服务器获取的提要、朋友、奖励列表。这些需要点击三个不同的端点，并被分页（每个提要、奖励、朋友信息都在大小 = 5 的页面中）

目前在 App.onCreate() 方法 [App extends Application] 中，我正在点击这些端点的第一页并将其存储在 App.appData 对象中（具有 ArrayList 提要、ArrayList 朋友、ArrayList 奖励的复合对象）。

我应该同时将这些保存到数据库中，还是应该在用户暂停应用程序时以某种方式拦截（即没有可见的活动）并在该回调函数中保存 App.appData 的内容进数据库？否则，我觉得一旦用户滚动并转到此从服务器获取并写入数据库周期下方的页面，将会持续很多次

是否有此类应用程序架构的最佳实践/教程？

+-----+----+---+                           
|  T1 | T2 | T3|                           
+-----+----+---+  +---------+   +---------+
|      F1      |  |  F2     |   |    F3   |
| +----------+ |  |         |   |         |
| +----------+ |  | +-------+   |  +----+ |
|              |  | |-------+   |  |----| |
|  +---------+ |  | |-----| |   |  |----| |
|  +---------+ |  | +-----+ |   |  +----+ |
|              |  |  Friends|   | Rewards |
|     Feeds    |  |         |   |         |
+--------------+  +---------+   +---------+

Answer 1

我正在开发具有类似架构的应用程序。我们从服务器获取数据并在数据到达时将其存储在数据库中。我们的 UI 对象从数据库中获取他们需要的东西。这种架构的好处是 UI 从不直接依赖于网络——它总是只显示数据库中可用的任何内容。但是，有许多重要的问题会影响这种架构对您是否有意义：

1. 您获取的数据多久更改一次？例如，如果用户在几天后运行应用程序，那么在您检查新内容时显示一些旧数据是否合理？
2. 您获取的数据的有效期是多久？如果您一天获取和存储大量数据，第二天仍然有效，还是需要将其丢弃？如果旧数据没用，那么数据库就没有什么用处了。
3. 您的数据列表有多大？它们会永远消失（例如相关性降低的搜索结果），还是有尽头（例如 Facebook 好友列表）？如果您的列表永远存在，那么将列表存储在数据库中就没有多大用处了。

在我的应用中，数据永远不会失效，每天的新数据量很少，数据量也不会大到难以在数据库中管理。这允许我们始终拥有一组好的数据供 UI 显示。但是，根据您对这些问题的回答，数据库可能没有那么有用。

希望这会有所帮助。对不起，如果我只是漫无目的。

编辑： 对于存储，我们只使用 SQLiteDatabase 和相关类。我在上面写了一个层来将大部分数据保存在内存中以获得更好的性能。当从网络接收到新数据时，我可以快速检查内存映射以查看是否有新的或更新的内容，然后根据需要将其保存到数据库中。

我不确定您是否希望将 App.onCreate 作为发出请求的主要位置。如果您的应用程序在后台运行了很长时间，但仍在运行，那么您可能没有意识到应该获取新数据。我们为片段使用基类，在 onResume 中我们从数据库（或内存映射）中获取数据，以便它始终是新鲜的。您还可以跟踪上次获取数据的时间（在 SharedPreferences 中保留时间戳），并且每 4 小时左右发出一个新请求。

基片段类也是在有新数据可用时接收通知的便捷方式。在 onResume 中，我们将片段注册为活动的，并在 onPause 中取消注册。然后，当网络上有新数据可用时，您只需检查哪些片段是活动的，并通知它们。然后这些片段可以从数据库中获取数据并刷新，就像调用 onResume 时一样。