私人内容提供商有什么用？

发布于 2024-10-29 14:40:59 字数 312 浏览 1 评论 0原文

Android 开发指南说

内容提供商对于读取和写入数据对您的应用程序来说是私有的，而不是已分享。

通常，内容提供者用于向不同的应用程序提供数据或在它们之间共享数据。我想知道拥有私人提供商并且不想共享它是否有任何用处。是否有直接访问数据库或文件系统无法提供的好处？

谢谢，拉贾特

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

猫卆 2024-11-05 14:40:59

它会自动在后台线程中安排所有服务器端和同步数据库访问。但是，在您的应用程序前端中，内容解析器/提供程序通常会默认从 UI 线程执行查询/事务。您必须异步执行所有事务（即使用 CursorLoader），以确保您的应用程序在 UI 端顺利运行。
它会本地化通过 ContentProvider 访问的任何线程的可重入数据库访问。 code>，这样所有锁定都可以完全发生在您的 ContentProvider 覆盖调用中，而不是在数据库层、服务和 UI 层中跟踪它。
作为上述内容的一部分，它还为您的数据提供了一个很好的单例接口 - 如果您的应用程序中有十个 Activity 类，您只需对每个类进行 ContentResolver 静态调用，而不需要处理打开/关闭 SQLiteDatabase当您在应用程序中从一个活动跳转到另一个活动时的每个活动。
ContentProvider 与 SyncAdapter 模型紧密相连——这意味着如果您想让数据库与网络上服务器托管的数据库保持同步，它几乎是唯一的方法。（您的应用程序反映了 REST api 类型的情况）
它与 ContentResolver 的 ContentObserver 接口相关联——在这个接口中（以及许多其他有用的东西）视图可以注册为观察一组特定的数据（通过 Cursor 到该数据）。然后，如果您对 ContentProvider 进行更改，CP 可以通知 CR，CR 又可以通知任何相关游标，而游标又会重新查询并导致视图更新。这比必须手动跟踪视图要干净得多，这样您就可以使它们无效并重新绘制它们。

至于数据库的可重入锁定，它并没有完全做到这一点，但它有所帮助——您的 ContentProvider 类实现了四个简单的函数（CRUD 接口），如果您选择覆盖它，则还可以实现第五个，batchAdd() - - 这会本地化您的锁定。最简单的答案是简单地在函数级别将所有四个/五个函数声明标记为“同步”，然后就完成了。比尝试找出锁定 5 个不同活动中访问数据库的 20 个位置要干净得多。

It automatically schedules all your server-side and synchronization DB access in a background thread. However, in your application frontend, the Content Resolver/Provider will normally execute queries/transactions from the UI thread by default. You must perform all transactions asynchronously (i.e. using a CursorLoader) to ensure that your application runs smoothly on the UI side
It localizes re-entrant DB access from the any threads that access through ContentProvider, so that all locking can happen entirely in your ContentProvider override calls, rather than keeping track of it in a DB layer, a service, and a UI layer.
As part of the above, it also provides a nice singleton interface to your data -- If you have ten Activity classes in your app, you just go through ContentResolver static calls from each one, versus needing to deal with opening/closing a SQLiteDatabase in each activity as you jump from one activity to another in your app.
ContentProvider is tied very tightly to the SyncAdapter model -- Meaning it's pretty much the only way to go if you want to keep your database in sync with a server-hosted database out on the net. (your app mirrors a REST api type of situation)
It ties into ContentResolver's ContentObserver interface -- This is an interface where (among many other useful things) a view can register as observing a specific set of data (through the Cursor to that data). Then, if you drive a change into the ContentProvider, the CP can notify the CR, which can in turn notify any relevant cursors, which in turn will requery and cause the view to update. This is much cleaner than having to manually keep track of your views so you can invalidate and redraw them.

As for re-entrant locking of the DB, it doesn't do it completely, but it helps -- your ContentProvider class implements four simple functions (CRUD interface) and, if you choose to override it, a fifth, batchAdd() -- This localizes your locking. The bone simple answer is to simply tag all four/five of those function declarations "synchronized" at the function level and you're done. Much cleaner than trying to figure out locking out from 20 places that access your DB in 5 different Activites.

回复收藏 0 原文