Журнал Компьютерра - Журнал "Компьютерра" N741-742

• Название: Журнал "Компьютерра" N741-742
• Автор: Журнал Компьютерра
• Жанр: Прочая околокомпьтерная литература

---

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

Ответ на этот вопрос органически вытекает из ответа на предыдущие. Нужно средство создания богатых, нетривиальных, динамичных интерфейсов — но позволяющее описывать их на достаточно лаконичном языке (который можно было бы передавать с сервера на клиент как простой текст). Нужна возможность интеграции с пользовательской операционной средой (каждое веб-приложение имеет отдельное окно без "стандартных элементов браузера", может встраиваться в трей, вешать панели на рабочий стол и т. п.) — но контролируемая, с не слишком большими уступами со стороны безопасности. Нужна возможность хранения на клиентском компьютере рабочих данных (актуальных настроек, уже полученных писем и т. п.) и самого интерфейса приложения — чтобы иметь возожность работать в среде с нестабильным интернетподключением и минимизировать трафик — забирать с сервера только обновившуюся информацию[Еще раз подчеркнем — это требование обосновано скорее не потребностями "бедных домашних" пользователей с 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, либо "Хотите ли вы запустить это неподписанное приложение?".