【问题标题】:Storing JSON on android: sqlite vs SharedPreference在 android 上存储 JSON:sqlite 与 SharedPreference
【发布时间】:2017-09-10 17:48:40
【问题描述】:

对于允许我的组织成员在他们的移动设备上查看数据的应用程序,我需要在设备上存储预先格式化的数据,以便他们也可以离线查看。他们如何通过 JSON 请求-响应获取数据。

响应格式如下(匿名 ofc):

[{
    "firstname":"John",
    "lastname":"Smith",
    "group":"1",
    "age":11,
    "installed":"Ja",
    "medical":"Is aan zijn linker zijde verlamd geweest.",
    "notes":"Heimee. \r\nBeschermend opgevoed. \r\nTerug getrokken persoonlijkheid.",
    "Insignes":["test", "Test2"],
    "Parents":[]
},
{
    "firstname":"Emely",
    "lastname":"Watson",
    "group":"33",
    "age":14,
    "installed":"Ja",
    "medical":"",
    "notes":"Test",
    "Insignes":["Veilig & Gezond I","CWO II","CWO III","Kampeertechnieken & Pionieren"],
    "Parents":[
        {
            "name":"ouder ouder",
            "address":"op | 0000AA Amsterdam",
            "phone1":"",
            "phone2":"0612345678",
            "mail":"example@google.com"
        }]
}]

我已经阅读了一些关于如何最好地存储它的讨论:

Is it ok to save a JSON array in SharedPreferences?

How to save JSON Array in SharedPreferences?

Android: what is the best way to store JSON data offline for the app in android?

Android - how to add JSON object to sharedPreferences?

What is the advantage of Using SQLite rather than File?

通过阅读这些,我了解到 SharedPreference 文件比 sqlite 文件“更快”,但容易损坏。 SQLite 是一个数据库,由于数据来自一个数据库,因此我倾向于以牺牲处理速度为代价来使用它。

现在我只需要存储然后读取数据,除非“主服务器”上有更新,否则它不会发生变异,在这种情况下,我可能会擦除本地数据并重新填充它。在这些线程中,我读到将 JSON 存储在 sharedpreference 中很容易但很难阅读。

但是在阅读了这些(以及更多)讨论之后,我并没有更接近了解/决定存储我的 json 的最佳方式是什么。

非常感谢任何建议!

【问题讨论】:

  • 嗯,为什么不只是一个普通的 JSON 文件呢?在这种情况下,您希望从 SharedPreferences 或 SQLite 获得什么对您有帮助?
  • 支持CommonsWare! (如果我理解正确的话)。 @S.Holzhauer 在您的情况下,我只需将整个文件保存到文件系统。并从那里加载它。这种方法的代码会更少。
  • 说实话,在阅读之后我得出的结论是这两个选项是公认的。 JSON 响应来自 HTTPS 请求,是否仍然可以将其存储为文件?那有多安全? @CommonsWare
  • @S.Holzhauer 您可以轻松地将 json 转换为字符串并保存。关于安全性,不是 sqlite,也不是首选项不会为存储的数据提供与保存到内部存储的文件相同的安全性。顺便说一句,sqlite db 和首选项 xml 保存在那里。默认情况下,用户无权访问内部存储。但是他可以根他的设备并访问它。因此,如果您需要提供安全性,您应该加密保存的数据。对于您的情况,保存和恢复文件是将 json 保存/恢复为字符串的更简单方法(在我个人看来),因为您正在其他地方处理它(如果您将其存储为 json)。
  • "是否仍然可以将其存储为文件?" ——嗯,嗯,是的。 “那有多安全?” -- 如果你把它存储在internal storage,它会相当安全。

标签: android json sqlite sharedpreferences android-storage


【解决方案1】:

您可以尝试使用 Realm 或 SugarORM 等 ORM 并将 json 有对象存储在数据库中。他们还提供了密码选项,您也可以通过这些选项加密数据,这将更加灵活。

http://www.androidauthority.com/use-android-keystore-store-passwords-sensitive-information-623779/

http://www.androidhive.info/2016/05/android-working-with-realm-database-replacing-sqlite-core-data/

如果您不需要第三方使用任何ORM,那么您可以直接使用android keystore 密钥加密JSON字符串,然后可以将加密后的字符串存储在普通sqlite中。

【讨论】:

    【解决方案2】:

    最好的选择是使用数据库方法,因为听起来您的数据集可能很大,但预计会很大。数据库保存大量信息,但我不建议使用 SQLITE ,因为它是基于 sql 的,没有 ORM 并且操作可能会变得乏味和耗时,主要是它很慢(值得商榷)。而是使用android和ios的最热门和最新的no-sql数据库,Realm,realm超级快,它基于java注释和ORM(如hibernate)。要在 android 中使用 json,我建议您熟悉 GSON,这是一个 Java 序列化/反序列化库,可以将 Java 对象转换为 JSON 并返回。

    Shared Preferences 非常方便存储小的键值对,如果您想要保存的键值集合相对较少,您应该使用 SharedPreferences API。 SharedPreferences 对象指向一个包含键值对的文件,并提供简单的方法来读取和写入它们。您仍然可以在这里使用 gson,我从未听说过共享偏好被破坏,我所知道的是它们很脆弱,并且可以与您的应用安装一起存在。

    结论:如果你的数据集很大,使用数据库方法来持久化大型数据集,这里的维护和修改更流畅,但是如果你知道你存储的内容相对较小,请使用共享首选项,并操作 json 结构在 android 中来回使用 google gson 库。

    【讨论】:

    • 数据集其实很小,大概30个孩子。如前所述,我不需要修改本地数据。那怎么办?
    • SQLite 中的原始 sql 既烦人又痛苦,但是游标操作很快。
    • 是的,您可以使用共享偏好,您的数据集听起来很小。是的。
    • 如果你选择了逻辑来清除你的共享偏好?
    【解决方案3】:

    SharedPreferences:

    如果 Json 中有少量数据,则必须将其存储在 SharedPreferences 中。

    您可以使用 Gson 轻松地将 Json 存储到 SharedPreferences。就用这个:

    将 Json 转换为字符串:

    Gson gson = new Gson();

    String jsonString = gson.toJson(jsonData);
    

    将字符串转换为 Json:

    gson.fromJson(jsonString, TypeToConvert);
    

    Sqlite 数据库:

    如果您在 Json 中有大量数据,请使用 Sqlite

    【讨论】:

      【解决方案4】:

      这是基于意见的答案。 Android 不,我不会将 JSON 存储在数据库或首选项中。将json存储在一个文件中。可以像流访问 json 一样以流的方式访问文件。文件大小几乎没有上限。我可能会将指向 json 文件的链接存储在数据库或首选项中。根据应用程序,我可能只是将 json 提取到抽象元素中并存储在 DB 中以进行排序选择。

      您提供的数据取决于我将提取并插入到设备的联系人数据库中的敏感度。

      【讨论】:

        猜你喜欢
        • 2016-08-23
        • 2013-01-08
        • 1970-01-01
        • 2017-10-18
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2014-01-17
        相关资源
        最近更新 更多