Покрокова РОЗРОБКА пошукового додатка в Android додатку

&nbsp

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

Рис 133 Послідовність подій, в ході яких реалізується запит клієнта на отримання інформації від постачальника вмісту

Покрокове дослідження нашого друга відеододатки Finch, в якому реалізується розглянутий патерн написання програм для Android Рекомендуємо при читанні звірятися з етапами, схематично показаними на рис 133 Зверніть увагу і на те, що послідовність етапів не завжди буде відповідати порядку, в якому ми описуємо код Щоб не відриватися від опису коду, ми будемо приводити номера етапів

Етап 1 Інтерфейс користувача збирає користувача введення

Для отримання ключових слів пошукового запиту в нашому інтерфейсі на рис 132 використовується звичайне поле EditText

Етап 2 Контролер прослуховує події

&nbsp

Етап 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-derasyncQueryRequest (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 для нового покоління мобільних пристроїв

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


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

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

Ваш отзыв

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

*

*