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

0

 

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

Исторически разработчики пользовательских интерфейсов на языке Java как для корпоративных, так и для мобильных приложений писали программы для мобильной среды и для настольных персональных компьютеров так, что эти приложения получались довольно «хрупкими». Иногда сетевые запросы выполнялись прямо в потоке пользовательского интерфейса, часто данные, полученные в результате этих запросов, не кэшировались. В большинстве приложений для отображения в пользовательском интерфейсе чего бы то ни было нужно было обращаться к сети – всякий раз, когда пользователь требовал вывести на экран новую информацию. Трудно поверить, что рабочие станции Unix образца 1980-х и 1990-х годов зачастую блокировались, когда оказывался закрыт доступ к удаленно смонтированным файловым системам. Если приложения использовали схему динамического кэширования на локальной машине, то они могли продолжать работать и в то время, пока файловый сервер оставался недоступен, а потом вновь синхронизироваться с ним, когда доступ возобновлялся. Разработчики должны были специально обращать внимание (что делалось редко) на то, чтобы приложения правильно получали доступ к сетевым данным и правильно их сохраняли.

Данная тенденция нашла поддержку и в J2ME, где разработчики могли сохранять состояние сети в довольно слабой системе управления записями, которая называлась RMS. Эта библиотека не поддерживала ни язык запросов, ни систему уведомлений, используемую с паттерном «Модель-вид-контроллер». Разработчики, имевшим дело с J2ME, были вынуждены порождать собственные обычные потоки Java, в которых потом выполнялись сетевые запросы, но зачастую этим пренебрегали, и приложение получалось ненадежным. Если веб-браузерам приходилось загружать сетевые данные в поток пользовательского интерфейса, то часто возникали ситуации их полного зависания, вплоть до того, что операционной системе приходилось завершить процесс браузера, чтобы выйти из такого положения. При каждом подвисании сети пользовательский интерфейс блокировался. Страницы, а также все изображения, на которые они ссылались, всегда требовалось загружать заново при каждом просмотре, из-за этого работа пользователя с программой шла очень медленно, если какой-нибудь запрос не приводил вдобавок к зависанию всего приложения. Сухой остаток из всех этих историй заключается в том, что, как правило, операционные системы возлагали задачи загрузки и кэширования информации на само приложение, практически не предоставляя прямой библиотечной поддержки, которая помогла бы разработчикам правильно реализовывать эти функции.

Для решения всех этих проблем можно написать полностью асинхронный интерфейс, который будет управлять и взаимодействием с сетью, и хранением данных. При таком подходе разработчику не приходится думать, правильно ли он поступил, когда запросил данные из сети. При применении такого API получение данных будет безопасным, независимо от того, работает ли в данный момент поток пользовательского интерфейса. Соображения такого рода становятся особенно важны при программировании для мобильных устройств, поскольку ненадежная связь с сетью повышает вероятность зависания кода, если он написан неправильно.

Рекомендуем использовать API поставщика содержимого как асинхронную модель сети и как кэш для состояний сети. Таким образом, виду и контроллеру вашего приложения не потребуются собственные механизмы для открытия соединений или доступа к базе данных. API поставщика содержимого несложно ассоциировать с API имеющихся веб-служб на основе REST. Поставщик содержимого просто находится между приложением и сетью, переадресовывая в сеть запросы и кэшируя результаты, если это требуется. Мы покажем, как такой подход помогает упростить приложение, а также опишем общие преимущества данного подхода. В частности, поговорим о том, как он позволяет внедрять еще более интересные свойства веб-программирования и технологии Ajax в приложениях Android. Подробнее о программировании с применением Ajax можно почитать по адресу http://ru.wikipedia.org/wiki/AJAX.

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

По теме:

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