有什么用私人内容供应商？ [英] What is the use of private Content Providers?

问题描述

而Android 开发指南说：

  

内容提供商也有用   读取和写入数据即   私人您的应用程序，而不是   分享。

通常，内容提供者用于提供数据到不同的应用程序或共享它们之间的数据。我想知道是否有任何使用其私人提供者和不想分享。有没有提供一个直接访问数据库或文件系统不提供任何好处？

谢谢， Rajath

解决方案

1. 在它自动安排所有的服务器端和数据库同步在后台线程访问。然而，在你的应用程序前端，内容解析器/供应商，通常会在UI线程默认情况下，执行查询/交易。你必须异步执行的所有交易（即使用 CursorLoader ），以确保您的应用程序在UI端运行顺利
2. 据本地化从通过的ContentProvider 访问任何线程重入DB访问，从而使所有的锁可以在你的ContentProvider覆盖通话完全发生，而不是跟踪它在一个DB层，一个服务，和一个UI层。
3. 如上面的一部分，它也提供了一个很好的单界面，您的数据 - 如果你在​​你的应用程序10活动课，你只要再通过每一个ContentResolver的静态调用，对需要处理的打开/关闭一个SQLiteDatabase在每个当你从一个活动跳到另一个在您的应用程序的活动。
4. 的ContentProvider绑非常紧密的SyncAdapter模型 - 这意味着它是pretty的多的去，如果你想用一台服务器托管数据库在网络上保持你的数据库同步的唯一途径。 （您的应用程序反映的情况REST API型）
5. 在它关系到ContentResolver的的ContentObserver接口 - 这是（在许多其他有用的东西）视图可以作为观察特定的一组数据（通过游标数据）寄存器的接口。然后，如果驾驶变化到ContentProvider的时，CP可以通知CR，其可以反过来通知任何有关光标，这又会重新查询并导致视图进行更新。这比手动保持你的意见的轨道，所以你可以废止和重绘他们干净多了。

对于DB的重入锁，它并不能完全做到这一点，但它可以帮助 - 你的ContentProvider类实现了四个简单的功能（CRUD接口），如果您选择覆盖它，第五，batchAdd （） - 这本地化的锁定。骨简单的答案是简单地标记那些函数声明同步的功能级别的所有四/五就大功告成了。比试图弄清楚从访问数据库中的5个不同的Activites 20个地方锁定了清洁。

The Android Dev Guide says

Content providers are also useful for reading and writing data that is private to your application and not shared.

Generally, Content Providers are used for providing data to different applications or sharing data among them. I was wondering if there is any use to having private providers and not wanting to share it. Are there any benefits provided that a direct access to DB or file system don't provide?

Thanks, Rajath

解决方案

1. 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
2. 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.
3. 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.
4. 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)
5. 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.

这篇关于有什么用私人内容供应商？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！