何时使用内容提供商


103

我了解内容提供者旨在允许在应用程序之间公开共享数据。但是,我想知道是否有人考虑过让内容提供程序仅在您自己的应用程序中使用。这样做会有什么好处吗?有什么缺点吗?

过去,我刚刚实现了SQliteOpenHelper来访问数据库中的数据,但是我正在考虑创建一个Content Provider。我觉得请求数据的URI方法简明扼要。另一方面,仅将Content Provider用于我的应用程序是否会多余(因为在其中,我将拥有SQliteOpenHelper类)并且工作量超过所需?


2
我制作了一个库,使内容提供程序易于编写。比编写普通的SQLiteOpenHelper更容易。github.com/coocood/VContentProvider
coocood 2012年

Answers:


59

如果您不打算共享数据,请不要考虑内容提供商。它们功能强大,但很难编写,如果要在内部使用它们,实现它们将很愚蠢。

但是,我想知道是否有人考虑过让内容提供程序仅在您自己的应用程序中使用。

当然...例如,对于我编写的一个旧的TODO列表应用程序,我必须编写一个内容提供程序,以允许其他应用程序检索和访问任务状态。这是要求的一部分,但不仅有意义,而且使应用程序更好。


34
我同意您的理由,但是我也很重要(特别是对于初学者),一旦实施内容提供商,您将获得很多好处。例如,您可以使用CursorLoader来执行异步查询...您可以访问单例实例(ContentResolver)来执行查询等。当然,您可以实现自己的Loader以用于SQLite数据库...当然您可以可以实现对整个应用程序中单个数据库实例的访问...当然,除非您希望共享,否则不需要ContentProvider
Alex Lockwood 2012年

11
与其他应用的数据。就是说,实现自己的内容提供程序有很多好处,因此您不应该仅仅因为您的应用程序不共享其数据而放弃考虑它。
亚历克斯·洛克伍德

8
是的,您完全正确,但是我仍然认为在大多数情况下不值得付出努力。我至少完成了12种不同的Android应用(已发布到Play商店),并且从不需要ContentProvider。实际上,我们正在使用的最后一个应用最初是使用a制作的ContentProvider,我们只是删除了它,因为它实际上比使用它更麻烦(我什至编写了一个库来简化基本ContentProviders的编写:github.com/casidiablo/persistence,但从未使用过它作为我自己的XD)。
2012年

1
@Cristian提供最实用的建议。甚至Android文档都指出,ContentProvider如果不需要,我们就不应该使用-“如果使用完全在您自己的应用程序中,并且您不需要,则不需要提供程序来使用数据库或其他类型的持久性存储上面列出的任何功能。您可以使用“保存应用程序数据”页面上所述的一种存储系统。”。否则,我们仅是工程。
Cheok Yan Cheng

简介:如果您不打算共享数据,则可以避免使用Content Provider,但另一方面,如果要更改应用程序的数据库,Content Provider将使您的生活变得轻松。例如从SQLite到MangoDB。
Prashant

116

我认为ContentProvider即使您不打算公开使用a,绝对是个好主意。

优良作法是在数据上提供额外的抽象级别,以使内部更改更容易。如果您决定以后更改基础数据库结构怎么办?如果使用a ContentProvider,则可以包含其中的所有结构更改,就好像您不使用其中一样,则必须更改受结构更改影响的所有代码区域。此外,很高兴能够重用相同的标准API来访问数据,而不是通过低级访问数据库来乱扔代码。

另外,将来总是有机会公开您的数据。如果您不ContentProvider预先使用,以后将很难进行改装。

然后,Android的其他部分ContentProvider是必需/推荐的,例如使用SyncAdapters时,以及是否要使用涉及数据访问的App Widget等。

总而言之,预先编写几乎ContentProvider不需要任何开销(一旦您已经学会了API,这是一个好主意),因此这样做是有意义的,即使对于私有数据也是如此。


1
我完全同意。它迫使您以一种可以确保新开发人员无法将UI与之耦合的方式抽象数据层。
加百利

3
学习了Android之后,出于这个原因,我立即开始以相同的方式进行思考。即使不是公开的,您也总是可以从体系结构决策的增加的抽象性和单点实施中受益。我喜欢ContentProviders。
davidcsb 2014年

1
您可以使用以下属性将内容提供程序仅提供给您自己的应用程序使用:android:exported="false"
Toby 1 Kenobi,2016年

4
以我的愚见,您可以而且应该以完全抽象的方式处理数据,而无需实现ContentProvider。
hmartinezd

2
当我在为内部sqlite db实现contentprovider解决方案(不与其他应用程序交互)时,我在developer.android.com/guide/topics/providers/…上看到了这句话,上面指出您不需要提供者如果使用完全在您自己的应用程序中,则使用SQLite数据库。
塞尔丘克·席汉

7

看一下MOTODEV Studio for Eclipse。这是扩展Eclipse的开发环境。他们有一个工具,您可以在其中自动为数据库生成内容提供程序。如果内容提供商可以更轻松地访问您的数据,并且对性能没有重大影响,请继续使用它。在大多数情况下都是如此。


5

简而言之,Content Providers有助于有效地管理数据。我建议出于以下原因使用它们。

  • 它充当UI和数据库之间抽象层。您可以在ContentProviders中实现数据验证,以验证用户输入的数据。它还使您可以修改数据库的结构,而无需触碰UI和其他部分。
  • 它们与其他android框架类(如) 很好地配合使用SyncAdapter。例如,当数据库中的值与ContentProviders一起使用时,您可以自动刷新列表CursorLoader。没有ContentProviders,您必须自己实现许多类似的功能。
  • 我们可以安全地将我们的私人数据公开给其他应用程序。使用ContentProviders将使我们能够轻松安全地与其他应用共享数据。

因此,即使您现在不需要这些功能中的任何一个,您将来也可能需要它们,这很有益,可以加倍努力并立即实施它们。


好答案。单句说明ContentProviders以及我们应使用它们的三个不同原因。有时简单的解释是最好的。+1
AdamInTheOculus

4

我同意ContentProvider有点难掌握,但即使您想在自己的应用程序内部使用它们,它们也绝对有帮助。最好的是,您可以为适当的URI自定义contentproviders。

在这种情况下,数据库中可能有5个表,但是在使用它们之前,您需要按照特定的顺序将其中的一些表连接起来。并为每个连接创建一个内容URI。然后,您可以分别将这些URI用作表:)

我建议您继续使用Content Provider,您会惊讶地发现它的功能强大。


2

在我看来,内容提供者具有许多优势,仅与其他应用程序共享数据就不用说了。如果您需要使用Sync-Adapter与服务器同步,请使用google cloud消息传递,当数据库中的基础数据使用Loader进行更改时自动更新UI,实施搜索,使用小部件...然后内容提供者就是您的最佳选择。

我希望您遵循该指南,因为有一天您可能需要实施附加到内容提供商的上述某些功能

顺便说一句,您可以使用内容提供商生成器在不到5分钟的时间内快速构建数据库和CP


1

如文档所述: 创建内容提供程序

如果使用完全在您自己的应用程序中,则不需要提供程序来使用SQLite数据库。

那么,为什么还要增加这种开销呢?您想要更轻松,更快速的开发,对吗?因此,一层抽象(SQLiteOpenHelper后代)就足够了。

请参见Occam的剃刀 。如果没有充分的理由,请勿创建实体。


0

如果不想与其他应用程序共享数据,请不要使用内容提供程序。使用简单的sqlitedatabase执行数据库操作。使用内容提供商存储机密数据时要小心,因为其他应用程序可能会访问您的机密信息


默认情况下,不暴露内容提供者,并且管理对它们的访问限制很容易。拒绝传播错误信息。
TBridges42 '16

2
@ TBridges42您错了。实际上,直到暴露了API级别17内容提供者。截至回答之时,有25%的Android设备受到此行为的影响,而在您发表评论时,仍有10%的设备受到此行为的影响。因此,反之则更是如此:您的评论很危险,因为您声明某些事实是/不是事实是安全的。
Murmel '17

0

使用Content Provider可以进一步提高抽象水平-将其放在您自己的应用程序中可以为您的项目增加大量的开发时间。但是,如果要使用它在多个应用程序之间共享数据,应用程序设置或配置,则可以选择内容提供程序。

注意您的安全级别,如果您的内容提供者正在写入SQLite,我建议您使用SQLcipher加密重置数据(DAR)。(我在一些解决方案中使用了内容提供程序,并提供了实时“快照”操作值以进行调试和测试的功能。)

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.