Главная » Разработка для Android » ПОШАГОВАЯ РАЗРАБОТКА ПОИСКОВОГО ПРИЛОЖЕНИЯ в Android приложении

0

 

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

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

Пошаговое исследование нашего второго видеоприложения Finch, в котором реализуется рассматриваемый паттерн написания программ для Android. Рекомендуем при чтении сверяться с этапами, схематически показанными на рис. 13.3. Обратите внимание и на то, что последовательность этапов не всегда будет соответствовать порядку, в котором мы описываем код. Чтобы не отрываться от описания кода, мы будем приводить номера этапов.

Этап 1. Пользовательский интерфейс собирает пользовательский ввод

Для получения ключевых слов поискового запроса в нашем пользовательском интерфейсе на рис. 13.2 используется обычное поле EditText.

Этап 2. Контроллер прослушивает события

 

Этап 3. Контроллер запрашивает данные у поставщика содержимого/модели при помощи метода managedQuery

Затем контроллер вызывает метод query, это делается в ответ на пользователь (поисковый) запрос:

Этап 4. Реализация запроса с передачей состояния представления

Этап 4 несколько сложнее, чем предыдущие шаги описываемой последовательности. Необходимо разобраться с нашим поставщиком содержимого FinchVideoContentProvider (это поставщик с передачей состояния представления), как мы разбирались с Simpl eFinchVideoContentProvider. Начнем с того, что FinchVideoContentProvider дополняет вспомогательный компонент RESTfulContentProvider, который, в свою очередь, дополняет ContentProvider:

FinchVideoContentProvider extend RESTfulContentProvider {

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

Константы и инициализация

Инициализация FinchVideoContentProvider очень напоминает процесс инициализации простого поставщика видео. Как и при работе с простым вариантом, сначала мы настраиваем механизм сопоставления URI. Нам придется решить лишь одну дополнительную задачу: обеспечить поддержку для сопоставления конкретных эскизов с содержимым. Мы не добавляем функцию сопоставления множественных эскизов с содержимым, поскольку нашей активности не требуется такая поддержка – в ней всего лишь понадобится загружать одиночные эскизы:

Создание базы данных

Создаем базу данных о видео Finch при помощи кода Java, выполняющего следующий запрос на SQL:

Обратите внимание, что, в отличие от простой версии базы данных, в этом варианте мы добавили возможность сохранять следующие атрибуты:

thumb_url, thumb_width, thumbjieight – это URL, ширина и высота, связанные с эскизом конкретного видео;

timestamp – при добавлении новой видеозаписи мы отмечаем точное время ее добавления;

query_text – сохраняем в базе данных текст запроса (или ключевые слова запроса) в базе данных вместе с каждым результатом запроса;

media_id – уникальное значение для каждого отклика с видео, получаемого от API GData. Мы не допускаем, чтобы две видеозаписи имели одинаковое значение media_id.

Метод query с сетевой функциональностью

Теперь поговорим о реализации метода query в классе FinchYouTubeProvider. В данном случае вызовы направляются в сеть для получения в качестве результатов запроса данных с YouTube. Для этого вызывается метод суперкласса, RESTf ul ContentProvi -der.asyncQueryRequest(String queryTag, String queryUri). Здесь query Tag – это уникальная строка, позволяющая при необходимости отклонять дублирующиеся запросы, a queryUri. – полный уникальный идентификатор ресурса, необходимый для асинхронной загрузки. В сущности, мы инициируем запросы к следующему URI после прикрепления параметров запроса URLEncoder. encoded, полученных из текстового поискового поля нашего приложения:

Наш сетевой метод query выполняет обычное сопоставление URI, а потом добавляет следующие задачи, соответствующие четвертому этапу обозначенной нами последовательности – «Шаг 4: Реализация запроса с передачей состояния представления»:

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

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

Задаем URI уведомления так, чтобы курсоры, возвращенные от метода query, получали события обновления во всех тех случаях, когда Поставщик содержимого обновляет информацию, отслеживаемую этими курсорами. Данное действие готовит почву для этапа 6 нашей последовательности, обеспечивающего обновление вида, когда поставщик содержимого инициирует события обновления. События обновления происходят при изменении данных, а сами данные изменяются, когда поставщик содержимого получает ответ на сделанный запрос. После прибытия уведомления происходит перерисовка пользовательского интерфейса, то есть этап 7. В данном описании этапы 6 и 7 идут «вне очереди», но мы считаем, что об этих этапах уместно рассказать именно сейчас, так как они связаны с URI уведомлений и запросами.

Порождение асинхронного потока для загрузки заданного URI запроса. Метод asyncQueryRequest заключает в себе создание нового потока, обслуживающего каждый запрос. В нашей схеме это этап 5; асинхронный запрос порождает поток именно для того, чтобы установить сетевое соединение, а сервис YouTube возвратит ответ.

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

По теме:

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