Визначення того, як часто слід повідомляти спостерігачі вмісту в Android додатку

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

При виборі схеми повідомлень розробнику слід розглянути можливість такого компромісу: відмовитися від доскональних результатів повідомлення, але більш точно вибудувати поновлення після змін Так можна знизити навантаження на систему для користувача інтерфейсу Якщо списку повідомляється, що в ньому змінився тільки один елемент, то можна перемалювати цей елемент лише у випадку, коли він знаходиться в полі видимості Але докладні повідомлення мають і ще один недолік: при їх застосуванні через систему проходить більшу кількість подій Ймовірно, користувальницький інтерфейс буде перемальовуватись частіше, оскільки він буде отримувати більше окремих подій про повідомлення При більш загальному підході до повідомлень через систему проходить менше подій Але якщо подій менше, то це найчастіше означає, що при отриманні повідомлення про зміни доводиться перемальовувати більш значну частину інтерфейсу користувача Наприклад, список може отримати єдине подія, що вимагає від нього оновити всі елементи, в той час як фактично змінилися всього три елементи Радимо враховувати можливість такого компромісу при підборі схеми оновлень Наприклад, можна дочекатися закінчення зчитування великого кількості подій, а потім ініціювати єдина подія типу «все змінилося», а не посилати поновлення після кожного окремого події

Найчастіше постачальники вмісту просто повідомляють про зміну даних всі клієнти, URI яких вказують на змінилася інформацію

ОГОЛОШЕННЯ ВАШОГО ПОСТАЧАЛЬНИКА

Тепер у нас є власний постачальник вмісту, залишилося тільки відкрити клієнтам доступ до нього Для цього потрібно додати в файл AndroidManif est xml наступну XML-рядок:

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

Ми впоралися із завданням створення власного простого постачальника вмісту

Джерело: Android Програмування на Java для нового покоління мобільних пристроїв

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*