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