RESTfulContentProvider: допоміжний клас для REST в Android додатку

&nbsp

Тепер розглянемо поведінки, які FinchVideoProvider успадковує від RESTful ContentProvider Ці поведінки потрібні для того, щоб виконувати запити з передачею стану подання Для початку вивчимо поведінка окремо взятого запиту до YouTube: як ми вже бачили, запити запускаються в асинхронному режимі з головного потоку REST-постачальник повинен вміти обробляти особливі випадки Так, якщо користувач робить запит за ключовими словами «Смішні кошенята» і в той же час вже виконується інший запит по тим же ключовими словами, то наш постачальник вмісту скине другий запит З іншого боку, якщо користувач зробив запит за ключовим словом «Собаки», а потім, коли цей запит ще не завершився, робить запит за ключовим словом «Коти», то постачальник вмісту дозволяє запитам за словами «Собаки» і «Коти» виконуватися паралельно Адже пізніше користувач може повторити запит по слову «Собаки» – і тут йому знадобляться кешированниє результати, які вже зацікавили його раніше

Клас RESTful ContentProvider дозволяє підкласу асинхронно породжувати запити, і коли дані за запитом прибувають, RESTful ContentProvider дає можливість виробляти настроюється обробку (custom handling) відповіді Для цього застосовується простий підключається інтерфейс, званий ResponseHandler Підкласи повинні перевизначати абстрактний метод RESTfulContentProvider newResponseHandler для повернення обробників, спеціально пристосованих для синтаксичного розбору даних відповіді, запитуваних їх базовим постачальником Кожен обробник перевизначає метод ResponseHandlerhandleResponse (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 для нового покоління мобільних пристроїв

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


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

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

Ваш отзыв

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

*

*