Главная » Разработка для Android » RESTfulContentProvider: вспомогательный класс для REST в Android приложении

0

 

Теперь рассмотрим поведения, которые FinchVideoProvider наследует от RESTful ContentProvider. Эти поведения требуются для того, чтобы выполнять запросы с передачей состояния представления. Для начала изучим поведение отдельно взятого запроса к YouTube: как мы уже видели, запросы запускаются в асинхронном режиме из главного потока. REST-поставщик должен уметь обрабатывать особые случаи. Так, если пользователь делает запрос по ключевым словам «Смешные котята» и в то же время уже выполняется другой запрос по тем же ключевым словам, то наш поставщик содержимого сбросит второй запрос. С другой стороны, если пользователь сделал запрос по ключевому слову «Собаки», а затем, когда этот запрос еще не завершился, делает запрос по ключевому слову «Коты», то поставщик содержимого позволяет запросам по словам «Собаки» и «Коты» выполняться параллельно. Ведь позже пользователь может повторить запрос по слову «Собаки» – и тут ему пригодятся кэшированные результаты, которые уже заинтересовали его ранее.

Класс RESTful ContentProvider позволяет подклассу асинхронно порождать запросы, и когда данные по запросу прибывают, RESTful ContentProvider дает возможность производить настраиваемую обработку (custom handling) ответа. Для этого применяется простой подключаемый интерфейс, называемый ResponseHandler. Подклассы должны переопределять абстрактный метод RESTfulContentProvider. newResponseHandler для возврата обработчиков, специально приспособленных для синтаксического разбора данных ответа, запрашиваемых их базовым поставщиком. Каждый обработчик переопределяет метод ResponseHandler.handleResponse (HttpResponse), чтобы обеспечить настраиваемую обработку сущностей HttpEntity, содержащихся в переданных объектах HttpResponse. Например, наш поставщик содержимого применяет обработчик YouTubeHandler для синтаксического разбора RSS-ленты, используемой в YouTube, вставляя в базу данных о видео новые строки для каждой из считанных записей. Чуть ниже мы поговорим об этом немного подробнее.

Кроме того, класс RESTful ContentProvider позволяет подклассу с легкостью выполнять асинхронные запросы и отклонять дублирующиеся запросы. RESTful ContentProvider сопровождает каждый запрос уникальной меткой (тегом), благодаря чему подкласс и может сбрасывать дублирующиеся запросы. Наш поставщик содержимого Finch VideoContentProvider применяет в качестве метки запроса ключевые слова, введенные пользователем, поскольку они уникально идентифицируют конкретный поисковый запрос.

Поставщик содержимого FinchVideoContentProvider переопределяет newResponseHandlеr следующим образом:

Теперь обсудим реализацию RESTf ul ContentProvider, это поможет нам объяснить те операции, которые он позволяет осуществлять в подклассах. Класс Uri RequestTask реализует интерфейс runnable для асинхронного исполнения запросов с передачей состояния представления. RESTf ul ContentProvider использует ассоциативный контейнер RequestsInProgress со строкой в качестве ключа, что гарантирует уникальность всех запросов:

Рассмотрим пояснения к коду.

Метод getRequestTask использует mRequestsInProgress для доступа к любым выполняемым в текущий момент идентичным запросам. Таким образом, asyncQueryRequest может блокировать дублирующиеся запросы при помощи обычного оператора if.

Когда запрос завершается после возврата метода ResponseHandlеr. handl eResponse, RESTful ContentProvider удаляет задачу из своего mRequestsInProgress.

newQueryTask создает экземпляры Uri RequestTask, являющиеся при этом экземплярами Runnable. В свою очередь, Runnable открывает HTTP-соединение, а затем вызывает handl eResponse применительно к подходящему обработчику.

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

Конечно, RESTful ContentProvider содержит суть системы многократно используемых задач, но для полноты картины мы продемонстрируем и другие компоненты нашего фреймворка.

UriRequestTask. Uri RequestTask содержит в себе асинхронные аспекты обработки REST-запроса. Это простой класс, обладающий полями, которые позволяют ему выполнять операции GET с передачей состояния представления в его методе run. Функционально такое действие относится к этапу 4 нашей последовательности – «Реализация запроса с передачей состояния представления». Как мы уже говорили, после того как получен ответ на запрос, этот ответ передается вызовом метода ResponseHandlеr. handl eResponse. Предполагается, что метод handleResponse будет добавлять в базу данных новые записи по мере необходимости. Этот процесс будет показан в YouTubeHandlеr:

YouTubeHandler. Поскольку используется абстрактный метод RESTful ContentProvider. newResponseHandler, мы наблюдали, что наш поставщик содержимого FinchVideoContentProvider возвращает YouTubeHandler для обработки RSS-лент с YouTube. YouTubeHandler использует для синтаксического разбора входящих данных инструмент XML Pull, экономно расходующий память. Этот инструмент итерирует запрошенные данные RSS в формате XML. В YouTubeHandler есть некоторые сложные моменты, но, в принципе, он просто подбирает XML-теги, необходимые для создания объекта ContentVal ues. Потом YouTubeHandler сможет вставить этот объект в базу данных поставщика содержимого FinchVideoContentProvider. Часть этапа 5 осуществляется в тот момент, когда обработчик вставляет содержимое, прошедшее синтаксический разбор, в базу данных поставщика содержимого:

Пояснения к коду следующие.

Наш обработчик реализует handl eResponse, разбирая сущность YouTube HTTP в своем методе, pa rseYoutubeEnti ty, вставляющем новые видеоданные. Затем обработчик удаляет старые видеоданные, запрашивая элементы, которые старше, чем период задержки, и удаляет строки с данными в этом запросе.

Обработчик закончил синтаксический разбор медийного элемента и использует содержащуюся в нем ссылку на поставщик содержимого для вставки только что разобранного объекта ContentValues. Обратите внимание, что этот процесс относится к этапу 5 нашей последовательности – «Обработчик ответа вставляет элементы в локальный кэш».

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

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

По теме:

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