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

Question

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

应用程序结构如下：主要活动有3个选项卡，每个选项卡都有分别从服务器中获取的供稿，朋友和奖励的列表。 这些需要命中三个diff端点，并进行分页（每个feed，奖励，朋友信息均出现在大小为5的页面中）

当前在App.onCreate（）方法[应用程序扩展应用程序]中，我点击了这些端点的第一页并将其存储在App.appData对象（具有ArrayList提要，ArrayList好友，ArrayList奖励的复合对象）中。

我应该同时将它们保存到数据库中还是应该以某种方式在用户暂停应用程序时拦截（即看不到任何活动），然后在该回调函数中将App.appData的the-then内容保存到数据库中？ 否则，我感觉一旦用户滚动浏览并转到此以下位置（从服务器获取）并写入数据库周期将持续很多时间

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

+-----+----+---+                           
|  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时一样。