Главная » Разработка для Android » Определение того, как часто следует уведомлять наблюдатели содержимого в Android приложении

0

Как видно из листинга, описывающего операции управления данными в поставщике содержимого, уведомление не происходит в системе управления содержимым Android «просто так». В частности, вставка информации в таблицу SQLite не вызывает автоматической установки триггера базы данных, который инициировал бы обновления с подачи поставщика содержимого. От разработчика поставщика содержимого зависит, будет ли реализована схема, определяющая подходящее время для отправки уведомлений и решающая, какой URI посылать при изменении данных поставщика содержимого. Как правило, поставщики содержимого в Android немедленно после события отправляют уведомления всем URI, которые изменились в ходе конкретной операции с данными.

При выборе схемы уведомлений разработчику следует рассмотреть возможность такого компромисса: отказаться от доскональных результатов уведомления, но более точно выстроить обновления после изменений. Так можно снизить нагрузку на систему пользовательского интерфейса. Если списку сообщается, что в нем изменился только один элемент, то можно перерисовать этот элемент лишь в случае, когда он находится в поле видимости. Но доскональные уведомления имеют и еще один недостаток: при их применении через систему проходит большее количество событий. Вероятно, пользовательский интерфейс будет перерисовываться чаще, поскольку он будет получать больше отдельных событий об уведомлении. При более общем подходе к уведомлениям через систему проходит меньше событий. Но если событий меньше, то это зачастую означает, что при получении уведомления об изменениях приходится перерисовывать более значительную часть пользовательского интерфейса. Например, список может получить единственное событие, требующее от него обновить все элементы, в то время как фактически изменились всего три элемента. Советуем учитывать возможность такого компромисса при подборе схемы обновлений. Например, можно дождаться окончания считывания большого количества событий, а потом инициировать единственное событие типа «все изменилось», а не посылать обновления после каждого отдельного события.

Зачастую поставщики содержимого просто уведомляют об изменении данных все клиенты, URI которых указывают на изменившуюся информацию.

ОБЪЯВЛЕНИЕ ВАШЕГО ПОСТАВЩИКА

Теперь у нас есть собственный поставщик содержимого, осталось только открыть клиентам доступ к нему. Для этого нужно добавить в файл AndroidManif est. xml следующую XML-строку:

Когда ваше приложение будет собрано, в его файле АРК окажутся классы для реализации поставщика содержимого, а в файле описания будет находиться строка XML, напоминающая ту, которую мы показали выше. После этого доступ к поставщику содержимого будет открыт для кода всех приложений с платформы Android. Предполагается, что код запросил и получил права на такой доступ.

Мы справились с задачей создания собственного простого поставщика содержимого.

Источник: Android. Программирование на Java для нового поколения мобильных устройств

По теме:

  • Комментарии