Какая польза от частных контент-провайдеров? - PullRequest
Новая
       13

Какая польза от частных контент-провайдеров?

43 голосов
/ 02 апреля 2011

Android Руководство разработчика говорит

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

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

Спасибо, Rajath

Ответы [ 2 ]

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

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

1 голос
/ 15 июня 2016

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

...