Какая польза от частных поставщиков контента?

Android Dev Guide говорит

Поставщики контента также полезны для чтение и запись данных, конфиденциально для вашего приложения, а не общий.

Как правило, поставщики контента используются для предоставления данных различным приложениям или совместного использования данных между ними. Мне было интересно, есть ли какие-либо возможности для частных поставщиков и не хотят делиться ими. Существуют ли какие-либо преимущества при условии, что прямой доступ к БД или файловой системе не предоставляется?

Спасибо, Rajath

Ответ 1

Он автоматически назначает весь доступ к серверной стороне и базе данных синхронизации в фоновом потоке. Тем не менее, в своем интерфейсе приложения Content Resolver/Provider обычно выполняет запросы/транзакции из потока пользовательского интерфейса по умолчанию. Вы должны выполнять все транзакции асинхронно (т.е. С помощью CursorLoader), чтобы гарантировать, что ваше приложение работает плавно на стороне пользовательского интерфейса.
Он локализует доступ к базе данных с последующим доступом из любых потоков, которые получают доступ через ContentProvider, так что вся блокировка может полностью произойти в ваших ContentProvider переопределять вызовы, а не отслеживать их на уровне БД, службе и UI.
В рамках вышеизложенного он также предоставляет приятный сингл-интерфейс для ваших данных. Если у вас есть десять классов активности в вашем приложении, вы просто просматриваете статические вызовы ContentResolver от каждого из них, а также должны иметь дело с открытием/закрытием SQLiteDatabase в каждом действии при переходе от одного действия к другому в вашем приложении.
ContentProvider очень сильно привязан к модели SyncAdapter. Это означает, что это в значительной степени единственный способ пойти, если вы хотите, чтобы ваша база данных синхронизировалась с серверной базой данных в сети. (ваше приложение отражает тип ситуации типа REST)
Он связан с интерфейсом ContentResolver ContentObserver - это интерфейс, в котором (среди многих других полезных вещей) представление может регистрироваться как наблюдающее определенный набор данных (через Курсор для этих данных). Затем, если вы введете изменение в ContentProvider, CP может уведомить CR, который может, в свою очередь, уведомлять о любых соответствующих курсорах, которые, в свою очередь, будут требовать и заставляют просмотр обновляться. Это намного проще, чем вручную отслеживать ваши взгляды, чтобы вы могли аннулировать и перерисовывать их.

Что касается блокировки повторного входа в БД, он не делает это полностью, но это помогает - ваш класс ContentProvider реализует четыре простые функции (интерфейс CRUD) и, если вы решите переопределить его, пятый, batchAdd() - Это локализует вашу блокировку. Костяной простой ответ - просто пометить все четыре/пять из этих деклараций функций "синхронизированными" на уровне функции, и все готово. Гораздо чище, чем пытаться выяснить блокировку из 20 мест, которые получают доступ к вашей БД в 5 различных активах.

Ответ 2

Например, сценарий использования многопроцессорного приложения (например, служба воспроизведения музыки, обычно выполняемая в удаленном процессе), между двумя процессами, которые в одной базе данных совместного использования приложений должны использовать частный ContentProvider.