• Главная
• В избранное
• Наш E-MAIL
• Добавить материал
• Нашёл ошибку
• Вниз

Касание сеткиАвтор: Виктор Шепелев

Опубликовано в журнале "Компьютерра" N25-26 от 08 июля 2008 годаОсенью прошлого года Adobe выпустила технологию Adobe AIR, связанную с ее (точнее, купленными у Macromedia) технологиями Flash и Flex. Примерно тогда же в свет вышла Silverlight — прямой конкурент Flash/Flex. Flex, AIR, Silverlight, Google Gears, GWT, Mozilla Prizm, Sun JavaFX — все это технологии, созданные для того, чтобы навсегда изменить привычный нам Интернет, из "Сети документов" превратить его в "Сеть приложений", могучей волной смыть различие между десктопом и Интернетом, веб-сервисом и отдельной программой.

Эти гибриды обозначаются термином RIA (Rich Internet Applications, "богатые" интернетприложения; а раньше Smart Client, "умный клиент"). Так уже много лет называют гипотетические приложения, более удобные, чем обычные сайты-сервисы, и более Интернето-центричные, чем обычные приложения. Неизвестно, что тому виной — рост ли пропускной способности сетей, приход ли "нового веба", или что иное, но лишь в последние года полтора-два эти гипотетические приложения стали стремительно становиться реальностью. Как и почему — выясним?

Введение в ria в вопросах и ответах

Чем плох браузер?

Да всем хорош. В своей роли: программыпросмотрщика гипертекстовых документов. Равно как язык разметки HTML — отличный язык для разметки гипертекстовых документов[Ну, про его "отличность" есть и альтернативные мнения — как у практиков (разработчиков браузеров и веб-дизайнеров), так и у теоретиков (радетелей Семантической Сети). Но все же.]. Да вот беда: ни то ни другое к созданию приложений не имеет ни малейшего отношения — by design, то есть по определению. И сам HTML как язык разметки, базовыми элементами которого являются абзацы, списки, таблицы, предполагает "поток текста с форматированием", а вовсе не пользовательский интерфейс произвольной формы. И динамическое взаимодействие с HTML-приложениями ограничено "переходом на другую страницу" (ссылка) да "отправлением заполненной анкеты на сервер" (форма). И ограниченность (точнее, отсутствие) связи с пользовательским окружением мешает развернуться — ни иконку информационную в трей не запихнуть, ни вложение в письмо в подходящей программе сходу не открыть. И необходимость для обработки каждого малейшего действия пользователя связываться с сервером мешает в средах с нестабильным подключением (например, мобильных).

А чем тогда плохи обычные приложения?

Здесь достаточно сказать одно слово: платформа.

При всех своих недостатках (см. выше) приложение-вбраузере или его аналоги имеют и массу достоинств: простота доставки пользователю, установки и обновления (в том смысле, что никого не приходится просить "пожалуйста, скачайте новую версию Gmail" — она просто есть), естественность взаимодействия с сервером, лучшее обеспечение безопасности пользователя (неизвестное приложение имеет немного возможностей проникнуть в его систему), работа приложения под всеми распространенными настольными ОС — был бы браузер современный. Да и сами веб-технологии (клиентская часть — HTML/CSS/JavaScript), с технической точки зрения, — штука простая, высокоуровневая и работающая: с сервера по простому протоколу передаются простые текстовые описания пользовательского интерфейса (которые могут быть сгенерированы мириадами способов и технологий), а умный и эффективный клиент-браузер их отображает.

Может показаться, что все достоинства вебприложений есть обратные стороны их же недостатков (техническое удобство HTML-интерфейсов против семантического неудобства; недостаточная интеграция приложения с рабочим столом против высокой степени безопасности; необходимость за каждым чихом соединяться с сервером против отсутствия необходимости доставки-установки). Однако некоторые технологические новинки последнего времени, которым, собственно, и посвящена эта статья, показали, что кое-какие "плодотворные сдвиги" в этой области вполне возможны.

Ну, допустим. А что нужно-то? В какую сторону должен происходить "сдвиг"?

Ответ на этот вопрос органически вытекает из ответа на предыдущие. Нужно средство создания богатых, нетривиальных, динамичных интерфейсов — но позволяющее описывать их на достаточно лаконичном языке (который можно было бы передавать с сервера на клиент как простой текст). Нужна возможность интеграции с пользовательской операционной средой (каждое веб-приложение имеет отдельное окно без "стандартных элементов браузера", может встраиваться в трей, вешать панели на рабочий стол и т. п.) — но контролируемая, с не слишком большими уступами со стороны безопасности. Нужна возможность хранения на клиентском компьютере рабочих данных (актуальных настроек, уже полученных писем и т. п.) и самого интерфейса приложения — чтобы иметь возожность работать в среде с нестабильным интернетподключением и минимизировать трафик — забирать с сервера только обновившуюся информацию[Еще раз подчеркнем — это требование обосновано скорее не потребностями "бедных домашних" пользователей с dial-up’ом, а "богатых мобильных" пользователей с WiFi’ем.].

К этим главным требованиям добавляются и веяния времени — пользовательский интерфейс должен быть "богатым" не только с точки зрения эффективного представления информации и удобного управления, но и в самом приземленном смысле: переливающиеся кнопочки, плавно выплывающие менюшечки — то есть динамические графические эффекты.

Личное мнение: вообще говоря, тот факт, что мощнейшие наработки современной графики — возможности железа и библиотек — используются в основном для украшения кнопок, а не для более эффективного представления информации, автор склонен считать признаком упадка нравов и победы потребительской цивилизации.

И что, есть решения, удовлетворяющие этим требованиям?

Полноценного и стопроцентного — кажется, еще нет ["Кажется" — потому что в этой горячей области все меняется чуть ли не ежедневно. Например, Adobe AIR уже существует, но возможности его полностью еще не распробованы.].

Но шаги в нужном направлении — и какие шаги! — делают многие, от гранд-монстров до еще вчера никомуне ведомых героев open source. Если разобраться в этих шагах и аккуратно их разложить, то и в фейерверке технологий, заявленном в первом абзаце, разобраться немудрено.

Рассказ об интерфейсах "богатых интернет-при ложений" (Rich Internet Applications) нельзя не начать с Gmail: роль этого сервиса в мэйнстримовом понимании "как можно делать веб-приложения" переоценить трудно. При этом, заметим, технологии использовались "старые": HTML/CSS/JavaScript. "Весь секрет" был лишь в довольно большом объеме кода на JavaScript (некогда созданного для простых однострочных инструкций типа "показать это окошко, когда нажмут ту кнопку") и использовании недооцененной возможности JavaScript по отправке запросов на удаленный сервер и получению ответов. Свершение Gmail было идеологическим, а не технологическим: он как бы сказал всем "вот эти (давно существующие) технологии можно использовать и так". Надо заметить, что у новаторского подхода были довольно существенные недостатки: во-первых, проблема переносимости по операционным системам сменилась проблемой переносимости по браузерам (очень немногие из которых оказались готовы к использованию возможностей JavaScript "на пределе", да и готовые исполняли его по-разному); вовторых, программирование сложных элементов интерфейса и аккуратного обновления их с сервера — работа довольно-таки нетривиальная.

Проблема адаптации к разным браузерам хоть и не решена полностью по сию пору, но стала в некоторой степени проблемой производителей браузеров, а не разработчиков веб-приложений. Здесь тоже большую роль сыграл масштаб шума вокруг гугловских сервисов, поставив вопрос ребром: "А в вашем браузере Google Maps работает?".

А вот для того, чтобы справиться со сложностью самой разработки, за истекшие годы было создано несколько решений разного толка. Одни из них — удобные библиотеки для эффективного изменения содержимого веб-страницы (например, jQuery, Prototype) — своим существованием обязаны гибкости и изяществу самого языка JavaScript, ранее недооцененного. Другие — Dojo, mooTools, Yahoo! UI Library или приложения к тем же jQuery и Prototype — это большие подборки готовых, профессионально разработанных и отлаженных элементов пользовательского интерфейса и вспомогательных объектов. Третьи, например Google Web Toolkit[Занятно, что для создания Gmail и Google Maps эта библиотека не использовалась. ], вообще предпочитают использовать веб-технологии как "высокоуровневый ассемблер" — приложения при помощи GWT пишутся на Java, а потом пользовательский интерфейс "компилируется" в HTML/JavaScript. Перечисленные средства, как правило, берут на себя не только построение динамичного интерфейса и обновление его с сервера, но и "красивости" (плавное выпадение меню, полупрозрачные окошки и пр.) и некоторую часть несовместимостей между браузерами.

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

И тут возникает идея использования схожих, но изначально "под интерфейсы заточенных" технологий: язык описания, подобный HTML, но более удачный; движок отображения встраивается в браузер, но более быстр, во всех браузерах работает одинаково и предоставляет больше специфических возможностей; скриптовый язык, подобный JavaScript (или он сам). Этим путем идут Adobe Flex [Чтобы не запутаться: Flash и Flex — две смежные технологии от одной корпорации Macromedia/Adobe: Flash — средство создания и отображения интерактивной анимации; Flex — технология создания пользовательских интерфейсов, основанная на Flash и использующая его для отображения этих интерфейсов. Сточки зрения клиента, и то и другое — Flash-ролик; но с точки зрения разработчика разница есть] — язык описания MXML, отображается Flash Player’ом; скриптовый язык ActionScript; Microsoft Silverlight — язык описания XAML, отображается Silverlight-плагином (который представляет собой легковесную часть более общей технологии Windows Presentation Foundation); скриптовый язык JavaScript (с версии 2.0 — и другие, в том числе компилируемые); OpenLaszlo [На этой платформе работает, например, pandora.com.] — язык описания LZX, отображается Flash Player’ом или как Java-апплет; скриптовый язык JavaScript; Curl (свои языки и плагины для всего). А в браузерный движок Gecko (Mozilla Firefox), например, без всяких плагинов встроен язык описания интерфейсов XUL — на нем-то и описан интерфейс и браузера, и плагинов. Кстати, и Sun, со своими Java-апплетами полезшая в эту область слишком рано и набившая все шишки, которые только возможно, теперь пытается войти в ту же реку второй раз с технологией JavaFX (и не только с ней — Sun поддерживает несколько фреймворков для создания веб-приложений).

Чтобы превратить "сайт" в "программу", то есть чтобы "веб-приложение" воспринималось пользователем более как "приложение", нежели "веб", требуется выполнить немало телодвижений. Приложение не должно быть "одной из вкладок браузера", ему нужно свое, отдельное окно. Неплохо бы и иметь возможность запускать приложение со своего диска (если у меня вообще нет доступа в Интернет, чтобы загрузить основной интерфейс Gmail, то как мне посмотреть свою старую переписку, даже если она хранится у меня на компьютере?) — а значит, "упаковывать" приложения и "устанавливать". При этом неплохо бы задуматься и о безопасности: не то "козел"-приложение, пущенный в "огород"-систему без присмотра, дорого обойдется пользователю.

Решений, в той или иной мере включающих в себя описанные возможности, существует несколько, все они следуют примерно одной и той же модели: пользователь единожды устанавливает у себя "запускалку", то есть платформу, и впоследствии может скачивать или запускать прямо с Веба сами приложения. В "скачиваемом" виде они, как правило, представляют собой архив со специальным расширением (например, webapp) и специальным набором файлов внутри. При запуске такого как-бы-приложения "запускалка" создает отдельное окно: оно, по сути, является окном браузера, но без привычных элементов и с иконкой запущенного приложения; кроме того, "запускалка" может предоставлять приложению дополнительные сервисы (скажем, JavaScript-функции для помещения иконки в трей) и, в идеале, должна контролировать уровень безопасности — скажем, требовать от всех запущенных приложений цифрового сертификата и/или спрашивать у пользователя разрешения на доступ к файловой системе, системным настройкам и рабочему столу.

Несколько примеров. Adobe AIR — это решение на основе браузерного движка WebKit (используется в Safari), "внутри" себя позволяет запускать air приложения, состоящие из HTML и Flash/Flex файлов, собранных в одно приложение с помощью бесплатного AIR SDK. Если на пользовательском компьютере установлен AIR, то air-приложения устанавливаются "совсем как настоящие" (меню "Пуск", "Установка и удаление программ" и т. п.) и, будучи запущены, выглядят как обычные приложения — и к трею доступ имеют, и обновляться (и даже запускаться) могут с Веба… Правда, модель безопасности в них достаточно простая — либо приложение подписано сертификатом, выданным Adobe, либо "Хотите ли вы запустить это неподписанное приложение?".

А вот Mozilla Prism (на движке Firefox’а, естественно) позволяет уже существующие веб-сервисы запускать как "совсем настоящие приложения". Для этого нужен специальный файл с расширением webapp — просто zip-архив, внутри которого лежит ini-файл, описывающий, какой сайт да с какой иконкой запускать. Впрочем, этим возможности Prism не ограничиваются — в том же webapp-архиве могут лежать и дополнительные js файлы, которые используют возможности интеграции в пользовательскую среду, предоставляемые Prism (например, раз в секунду проверять, поменялась ли строка, отображающая количество писем в загруженном Gmail приложении, и если да — отображать иконку-конвертик все в том же трее). Правда вот, с безопасностью и контролем у Prism пока совсем никак — но бета, бета ведь.

Из перечисленных ранее "производственных необходимостей" на пути к богатому интернет-приложению осталась необходимость хранения данных на клиенте:полученных писем, пользовательских настроек, уже загружавшихся частей карты, да мало ли чего. Наименее заметный для клиента (и оттого комфортный) способ предлагает библиотека Dojo.storage (часть огромного фреймворка Dojo, упоминавшегося выше как популярное средство построения HTML-интерфейсов).

Решение Dojo.storage иначе как хаком не назовешь библиотека позволяет использовать уже существующие на клиенте, но имеющие другое предназначение "хранилища": например, возможность браузера хранить информацию в cookies или скрытый Flash-объект (Flash-плагин имеет встроенную возможность сохранять небольшое количество информации на клиенте).

Как всякий хак, такое решение довольно уязвимо: и объем хранимого ограничен, и полностью рассчитывать на то, что в каждый следующий раз удастся записать/ прочитать сохраненную информацию, нельзя. Более надежное решение — Google Gears, устанавливаемый как плагин к браузеру и позволяющий умеющему работать с ним приложению хранить данные на клиентском компьютере (но только в специальной встроенной БД, доступа к файловой системе приложению не предоставляется). Adobe AIR также содержит встроенную БД и средства работы с ней (к слову, и Gears, и AIR, и многие другие используют один и тот же опенсорсный движок БД SQLite).

Возможно, судить еще рано, однако похоже, что тенденции на улучшение веб-приложений ведут клиентскую часть Веба куда-то далеко в сторону от изначальной "платформы для чтения документов". Например, мозилловцы, создавшие Prism, говорят о нем как о Site Specific Browser (каждому сайту свой браузер с подходящим именно этому сайту внешним видом и управлением), а горячие норвежские парни из Opera прямо говорят о своем курсе на превращение браузера в "полноценную платформу для приложений, работающую на любом устройстве"[Например, недавно Opera анонсировала поддержку Google Gears по собственному почину, не дожидаясь, пока "приспособление" биб лиотеки к браузеру сделает Google.]. Все это очень здорово, но как бы оставляет за кадром тот факт, что первоначальное назначение Веба — сети гипертекстовых документов — отнюдь не исчерпано. И тем не менее весь браузерный прогресс последних лет направлен вот на то самое — на превращение браузера в "платформу для всего" [Не могу не вспомнить бесконечно бородатую шутку про текстовый редактор Emacs, тоже стремившийся в свое время стать платформой и преуспевший: "Emacs — отличная операционная система, жаль, текстового редактора в ней нету". ], а не на удобство потребления информации. Не то пора, как предлагают некоторые, вводить HyperApplication Transfer Protocol — чтобы спасти Hyper Text от засилья приложений; не то пора создавать веб-приложение-для-удобного чтения [(Не сарказм.) Рекомендую обратить внимание, например, на New York Times Reader, сделанный на основе Microsoft WPF (то есть технологии, частью которой и является Silverlight). См]…

P.S. Автор благодарит за ценные консультации Андрея Федонюка (Terra Informatica Software) — создателя интерфейсной библиотеки HTMLayout и платформы для RIA-приложений Sciter.