ДОСЛІДЖЕННЯ ПОСТАЧАЛЬНИКІВ ВМІСТУ в Android додатку

&nbsp

Ми говорили про те, що при роботі з користувача інтерфейсами, яким необхідно взаємодіяти з віддаленими службами, виникають нетривіальні проблеми – наприклад, необхідність не займати потік користувача інтерфейсу рішенням довгострокових завдань Крім того, ми відзначали, що API постачальника вмісту в Android має симетрію, схожою з симетрією веб-служб типу REST (з передачею стану подання) Операції з даними, що здійснюються в постачальнику вмісту, відповідають операціям з даними в REST-службах, і нижче буде показано, як перетворити унікальні ідентифікатори ресурсів з постачальника вмісту в таку форму, яка дозволяє запитувати дані з мережі Радимо користуватися перевагами, властивими для такої симетрії, при написанні постачальників вмісту Постачальник вмісту повинен створюватися як асинхронний буфер між доменними (унікальними) аспектами вашого застосування і мережевими запитами, які отримують дані Обробкою цих даних займається вже вашу програму Якщо писати додаток за таким принципом, воно значно спроститься і допоможе уникнути поширених помилок, повязаних з розробкою користувацьких інтерфейсів і роботою в мережі, типових для програмування в Android і взагалі на мові Java

Історично розробники користувальницьких інтерфейсів на мові Java як для корпоративних, так і для мобільних додатків писали програми для мобільного середовища і для настільних персональних компютерів так, що ці програми виходили досить «крихкими» Іноді мережеві запити виконувалися прямо в потоці користувача інтерфейсу, часто дані, отримані в результаті цих запитів, що не кешувати У більшості додатків для відображення в інтерфейсі чого б то не було потрібно було звертатися до мережі – щоразу, коли користувач вимагав вивести на екран нову інформацію Важко повірити, що робочі станції Unix зразка 1980-х і 1990-х років часто блокувалися, коли опинявся закритий доступ до віддалено змонтованим файловим системам Якщо додатки використовували схему динамічного кешування на локальній машині, то вони могли продовжувати працювати і в той час, поки файловий сервер залишався недоступний, а потім знову синхронізуватися з ним, коли доступ поновлювався Розробники повинні були спеціально звертати увагу (що робилося рідко) на те, щоб програми правильно отримували доступ до мережевих даними і правильно їх зберігали

Дана тенденція знайшла підтримку і в J2ME, де розробники могли зберігати стан мережі в досить слабкій системі управління записами, яка називалася RMS Ця бібліотека не підтримувала ні мова запитів, ні систему повідомлень, використовувану з паттерном «Модель-вид-контролер» Розробники, що мали справу з J2ME, були змушені породжувати власні звичайні потоки Java, в яких потім виконувалися мережеві запити, але часто цим нехтували, і додаток виходило ненадійним Якщо веб-браузерам доводилося завантажувати мережеві дані в потік користувальницького інтерфейсу, то часто виникали ситуації їх повного зависання, аж до того, що операційній системі доводилося завершити процес браузера, щоб вийти з такого становища При кожному підвисань мережі користувальницький інтерфейс блокувався Сторінки, а також всі зображення, на які вони посилалися, завжди було потрібно завантажувати заново при кожному перегляді, через це робота користувача з програмою йшла дуже повільно, якщо який-небудь запиту не приводив до того ж до зависання всього програми Сухий залишок з усіх цих історій полягає в тому, що, як правило, операційні системи покладали завдання завантаження і кешування інформації на сам додаток, практично не надаючи прямий бібліотечної підтримки, яка допомогла б розробникам правильно реалізовувати ці функції

Для вирішення всіх цих проблем можна написати повністю асинхронний інтерфейс, який буде керувати і взаємодією з мережею, і зберіганням даних При такому підході розробнику не доводиться думати, чи правильно він вчинив, коли запросив дані з мережі При застосуванні такого API отримання даних буде безпечним, незалежно від того, чи працює в даний момент потік користувача інтерфейсу Міркування такого роду стають особливо важливі при програмуванні для мобільних пристроїв, оскільки ненадійна звязок з мережею підвищує ймовірність зависання коду, якщо він написаний неправильно

Рекомендуємо використовувати API постачальника вмісту як асинхронну модель мережі і як кеш для станів мережі Таким чином, увазі і контролеру вашої програми не будуть потрібні власні механізми для відкриття зєднань або доступу до бази даних API постачальника вмісту нескладно асоціювати з API наявних веб-служб на основі REST Постачальник вмісту просто знаходиться між додатком і мережею, переадресовуючи в мережу запити і кешіруя результати, якщо це потрібно Ми покажемо, як такий підхід допомагає спростити додаток, а також опишемо загальні переваги даного підходу Зокрема, поговоримо про те, як він дозволяє впроваджувати ще більш цікаві властивості веб-програмування та технології Ajax в додатках Android Детальніше про програмування із застосуванням Ajax можна почитати за адресою http://ruwikipediaorg/wiki/AJAX

Джерело: 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>

*

*