Главная » Разработка для Android » СЕТЕВОЙ ВАРИАНТ «МОДЕЛЬ-ВИД-КОНТРОЛЛЕР» в Android приложении

0

 

Нам кажется, что удобно представить второй из описанных выше принципов как сетевой вариант паттерна «Модель-вид-контроллер», где сам поставщик содержимого получает данные из сети, а затем закачивает их в обычный паттерн MVC, действующий в Android. Мы рассмотрим поставщик содержимого как модель сетевого состояния – поставщик может выполнять запросы на получение данных с состоянием, имеющимся в локальной системе, либо получать данные из сети. При применении такого подхода код контроллера и вида не должен непосредственно создавать сетевые запросы для доступа к данным приложения и для управления ими. Вместо этого вид и контроллер вашего приложения должны использовать API ContentResolver для того, чтобы запрашивать данные через поставщик содержимого. И только поставщик содержимого должен в асинхронном режиме загружать сетевые ресурсы и сохранять результаты в локальном кэше данных. Кроме того, поставщик содержимого всегда должен быстро реагировать на запрос, с самого начала избегая этапа сетевой активации, которая может потребоваться для выполнения запроса с использованием какой-либо информации, уже находящейся в локальной базе данных. При выполнении запроса по такому принципу гарантируется, что поток пользовательского интерфейса будет заблокирован не дольше, чем это необходимо, и что пользовательский интерфейс должен отобразить те или иные данные как можно быстрее. Таким образом, увеличивается скорость реагирования приложения и пользователю становится гораздо приятнее работать с таким интерфейсом. Рассмотрим, в какой последовательности поставщик содержимого запрашивает данные.

1. Поставщик содержимого выполняет сопоставление входящего URI и запрашивает содержимое локальной базы данных на предмет элементов, которые до этого совпали с данными запроса.

2. Наш поставщик содержимого всегда пытается получить наиболее актуальное состояние для запроса и после этого порождает асинхронный REST-запрос для загрузки содержимого из сети. Это поведение можно сделать конфигурируемым на базе запроса.

3. Поставщик содержимого возвращает клиенту курсор из исходного локального запроса.

4. Асинхронный загрузочный поток должен решить, необходимо ли обновить данные, находящиеся в кэше поставщика содержимого. Если такая необходимость есть, то поставщик содержимого загружает данные из сети и производит их синтаксический разбор.

5. Когда содержимое приходит из сети, поставщик содержимого непосредственно вставляет каждый новый фрагмент данных в базу данных, а потом уведомляет клиентов URI о приходе новой информации. Поскольку сама операция вставки уже происходит в рамках поставщика содержимого, не требуется вызывать ContentResolver. іnsert. Клиенты, содержащие существующие курсоры (данные в которых устарели), могут вызвать Cursor. requery для обновления своих данных.

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

На рис. 13.1 проиллюстрированы операции, происходящие в поставщике содержимого при выполнении этой последовательности.

Рис. 13.1. Сетевой поставщик содержимого, кэширующий контент по инициативе клиента

С каждым запросом в этой последовательности используется единственный объект Cursor, создаваемый поставщиком содержимого, а затем возвращаемый виду. Лишь от поставщика содержимого требуется уведомлять пользовательский интерфейс при изменении данных. Вид и контроллер не обязаны собирать данные и, конечно, не должны обновлять модель. Когда данные доступны, поставщик содержимого уведомляет курсор о том, что можно делать запрос. Роль управления данными целиком заключена в поставщике содержимого, благодаря этому упрощается код вида и контроллера. Клиент поставщика содержимого запрашивает данные и быстро получает курсор; когда прибывают данные из сети, курсор об этом уведомляется. Необходимо еще раз отметить, что работа механизма оповещения требует, чтобы объект Cursor и база были открытыми все время, пока клиент использует их. Закрытые курсоры и базы данных приводят к тому, что в клиентских видах не отображается никаких результатов. В такой ситуации сложно понять, почему пуст компонент (например, список) – потому, что курсор был по ошибке закрыт, или потому, что запрос действительно не дал результатов.

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

По теме:

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