Android и iPhone – войны браузеров: Часть 1. WebKit спешит на помощь

Разработка приложения для браузера, отвечающего за мониторинг состояния сети

Роль мобильных устройств в современной жизни стремительно растет. Мы используем их в качестве средства общения, в качестве средства навигации и даже в качестве карманного фонарика. Разнообразные пользовательские приложения, работающие на платформах iPhone и Android, завоевали широкую популярность у владельцев мобильных устройств. Развитие мобильных и Web-технологий открывает новые возможности в сфере мобильных Web-приложений. Эта статья является первой в серии Android и iPhone: войны браузеров, состоящей из двух частей и посвященной разработке приложений для браузеров iPhone и Android. В рамках статьи рассматривается построение простого приложения для мониторинга сети, которое может выполняться как на браузере настольного компьютера, так и на обоих мобильных браузерах.

Фрэнк Эйблсон, проектировщик ПО, Независимый разработчик

Когда Фрэнк Эйблсон (Frank Ableson) закончил карьеру баскетболиста в команде своего колледжа, не заключив многолетнего контракта с «Лос-Анджедес Лейкерс», он занялся разработкой компьютерных программ. Он любит решать сложные задачи, особенно из области связи и интерфейсов с аппаратурой. Свободное время Фрэнк проводит со своей женой Никки и детьми. С ним можно связаться по адресу: frank@cfgsolutions.com.



20.10.2010

Введение

Суммарно, платформы iPhone и Android насчитывают более 100000 приложений, доступных для скачивания из самых разных источников. При этом имеются в виду «родные» приложения, т.е. приложения, которые разрабатываются и собираются средствами соответствующего SDK, а затем устанавливаются на мобильное устройство. Подобные «родные» приложения позволяют эффективно реализовать технические возможности мобильного устройства, включая поддержку беспроводных сетей, Bluetooth и хранилищ данных, функции акселерометра или компаса и другие технологические чудеса и новинки, которые делают мобильные устройства столь привлекательными для пользователей. Популярность «родных» приложений для платформ iPhone и Android чрезвычайно велика, однако помимо этого мобильные устройства предоставляют широкие возможности для разработки Web-приложений.Мобильные технологии давно вышли из детского возраста, а с ними достиг определенной зрелости и мобильный Интернет.

Эта статья является первой в серии из двух частей, посвященной разработке приложений для браузеров на платформах iPhone и Android. Цель этой серии – познакомить читателя с основными принципами создания собственных мобильных Web-приложений. Возможности мобильных приложений не ограничиваются запуском Web-сайта на мобильном устройстве. Мы рассмотрим базовые технологии и подходы, используемые в разработке мобильных приложений, которые позволяют выделить этот раздел разработки ПО в отдельную самостоятельную дисциплину.

Популярность Web-платформы объясняется тем, что ее использование позволяет решить множество проблем, традиционно являющихся бичом разработчиков и системных администраторов. Среди них:

  • Проблемы установки: установка Web-приложений не вызывает никаких проблем – просто установите или скопируйте их на сервер и скажите вашим клиентам, какой URL-адрес нужно указать в браузере.
  • Проблемы масштабирования: Web-приложения легко масштабируются на пул серверов высокопроизводительного центра обработки данных, а для обслуживания приложений используются готовые инструменты управления Web-сайтом.
  • Проблемы архивирования и восстановления данных: Web-приложения используют централизованное хранилище данных, тем самым упрощая задачу восстановления в случае сбоев.
  • Вопросы пользовательского интерфейса: комбинация of HTML, Cascading Style Sheets (CSS) , JavaScript и графических изображений позволяет создать многофункциональный пользовательский интерфейс, который значительно превосходит по своим возможностям и внешнему виду интерфейсы, разработанные средствами «родных» SDK. Последние, как правило, не в состоянии обеспечить полноценный эффект присутствия для игровых приложений и не гарантируют необходимую функциональность для интерактивных информационных терминалов.
  • Простота использования: большинство приложений требуют простых и понятных в использовании элементов пользовательского интерфейса, позволяющих легко выполнять повседневные операции.

Наиболее привлекательный аспект модели дистрибуции приложений через Интернет состоит в том, что она позволяет превратить ПО в своего рода сервис по подписке, представляющий собой взаимовыгодный способ поставки программного обеспечения. «Каким образом?» – спросите вы. Давайте рассмотрим этот вопрос подробнее.

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

Звучит прекрасно, не правда ли? Идем дальше: все, что работает для Web-платформы, должно работать и для мобильных устройств, так? К сожалению, до появления iPhone ответ на этот вопрос был отрицательным. Почему?

Дело в том, что поддержка Web-браузеров на мобильных устройствах практически отсутствовала. Ситуация кардинально изменилась с появлением технологии, получившей название WebKit, которая уверенно заняла свое место в сфере мобильных устройств именно благодаря iPhone.

Всего за несколько лет платформа iPhone стала Web-клиентом номер один в мире. Почему? Потому что WebKit вкупе с надежной работой Интернет-соединения позволили использовать Web-сервисы на мобильных устройствах гораздо эффективнее, чем на каких-либо других современных браузерах. Другие игроки рынка мобильных устройств также обратили внимание на новую технологию, и теперь весь рынок можно разделить на компании, которые используют WebKit, компании, которые собираются использовать WebKit и компании, придумывающие отговорки для того, чтобы не использовать WebKit.

Итак, что же такое WebKit?


WebKit и HTML5

WebKit – движок браузера, используемый как для поддержки браузера Mobile Safari на платформе iPhone, так и для поддержки браузера на платформе Android. Безусловно, WebKit используется и в других мобильных устройствах, однако в рамках этой статьи мы ограничимся рассмотрением платформ iPhone и Android.

WebKit – проект с открытым кодом, берущий свое начало из разработки K Desktop Environment (KDE). Именно проекту WebKit современные Web-приложения для мобильных устройств обязаны своим появлением на свет. Технологические и конструктивные характеристики мобильного устройства, безусловно, играют важную роль, однако мобильных пользователей в первую очередь интересует контент. Если мобильное устройство обеспечивает доступ лишь к малой части Интернет-контента, то вряд ли оно сможет попасть в топ-лист наиболее популярных устройств.

Большинство из нас предпочитает жить полноценной жизнью: если мы открываем какой-либо Web-сайт на портативном компьютере сидя дома, мы рассчитываем увидеть тот же контент, когда открываем этот сайт, сидя в поезде. Контент – вот основная проблема мобильных приложений. Независимо от того, где мы находимся, и чем мы занимаемся, нам нужен доступ к интересующим нам данным. Технология WebKit обеспечивает полноценный контент на платформах iPhone и Android.

Стоит отметить, что WebKit используется и в настольных компьютерах, например, в браузере Safari, который является основным браузером платформы Mac OS X. Независимо от того, рассматривается ли версия для настольных компьютеров или движок браузера для iPhone или Android, WebKit остается наиболее передовой технологией, поддерживающей HTML и CSS. Фактически, WebKit поддерживает стили CSS, которые пока еще не отображаются браузерами на других движках – в качестве примера можно указать ряд свойств, определяемых спецификацией HTML5.

HTML5 представляет собой набор предварительных технических спецификаций, определяющих технологии, которые базируются на использовании браузеров, таких, например, как хранилища данных на стороне клиента с поддержкой SQL, перемещения, преобразования и так далее. Разработка спецификации HTML5 пока еще на закончена, однако как только основные принципы будут четко сформулированы и реализованы в браузерах на большинстве платформ, весьма скромный начальный этап развития Web-приложений станет забытым прошлым. Разработка Web-приложений займет значительный сегмент в сфере разработки ПО, причем речь идет не только о приложениях для браузеров настольных компьютеров, но и для мобильных браузеров. Из побочного продукта мобильные приложения превратятся в основной товар на рынке Web-приложений.


Конструктивные особенности разработки мобильных Web-приложений

Если вы приняли решение освоить технологии Web-разработки, то в вашем распоряжении оказывается весьма ограниченный выбор средств. Прежде всего, приложение может быть создано непосредственно на сервере в виде файла, содержащего код HTML, CSS и JavaScript. При этом HTML-контент может поставляться в виде статических HTML-файлов, а может генерироваться динамически за счет использования различных технологий, работающих на стороне сервера, например, таких как PHP, ASP.NET, Java Servlets и др. В любом случае, с точки зрения вопросов, рассматриваемых в данной статье, все сводиться к коду HTML, и здесь наиболее важным для нас моментом является то, что технология WebKit позволяет браузерам воспроизводить HTML на мобильных устройствах.

Чтобы выполнить Web-приложение на мобильном устройстве (iPhone или Android), пользователю надо запустить браузер и ввести URL-адрес соответствующего сервиса, например: http://yourcompanyname.com/applicationurl.

При этом диапазон предлагаемых мобильных Web-приложений достаточно широк: от стандартного Web-сайта до мобильного Web-приложения, разработанного специально для конкретной мобильной платформы.

Отображение стандартных сайтов

Движок WebKit в сочетании с интуитивно понятным и удобным пользовательским интерфейсом платформ iPhone и Android позволяет просматривать на мобильном устройстве практически любые Web-сайты. Web-страницы отображаются вполне корректно в отличие от предыдущего поколения мобильных браузеров, которые произвольно переносили фрагменты контента или вовсе не отображали их. При загрузке страниц в браузере с поддержкой WebKit, содержимое страницы, как правило, масштабируется. При этом масштаб выбирается таким образом, чтобы вся страница целиком уместилась на экране, хотя и в сильно уменьшенном, зачастую нечитаемом виде, как показано на рисунке 1. Тем не менее, страницу можно прокручивать, увеличивать, двигать, обеспечивая удобный доступ ко всем элементам контента. По умолчанию браузер использует окно шириной 980 пикселей.

Рисунок 1. Уменьшенная в процессе загрузки Web-страница
Рисунок 1. Уменьшенная в процессе загрузки Web-страница

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

Web-страницы, созданные с учетом особенностей мобильных устройств

Если вы хотите, чтобы ваша Web-страница была доступна не только обычным пользователям сети, но и мобильным пользователям, стоит рассмотреть еще несколько возможностей оптимизации мобильных Web-приложений.

Несмотря на то, что WebKit позволяет корректно отобразить Web-страницу на экране мобильного устройства, существует определенная разница между устройствами, использующими мышку, такими как портативные или настольные компьютеры, и сенсорными устройствами, такими как смартфоны iPhone или Android. Сенсорные устройства отличаются физическими размерами площади «клика», отсутствием функции наведения курсора на какой-либо элемент и другой последовательностью событий. Таким образом, если вы хотите создать Web-сайт, который был бы удобен как для обычных, так и для мобильных пользователей, необходимо учитывать следующие особенности мобильных устройств:

  • Браузеры iPhone и Android в состоянии отобразить Web-страницу целиком в достаточно «читабельном» виде – качество отображения этих браузеров значительно выше, чем у стандартных мобильных браузеров, – так что не спешите упрощать дизайн вашего сайта.
  • Размер подушечек пальцев значительно превосходит размер указателя мышки. Учитывайте этот фактор при разработке элементов навигации по сайту. Не располагайте ссылки слишком близко друг к другу, иначе пользователь не сможет щелкнуть на одной ссылке, не задев при этом соседнюю.
  • Элементы, отображаемые при наведении курсора, не будут работать на мобильных устройствах. Пользователь просто не может «навести» палец на какой-либо элемент так же, как курсор мышки.
  • События, определяемые нажатием и удерживанием кнопки мышки, перетаскиванием мышкой и т.п., на сенсорных экранах реализуются другим способом. Какие-то из этих событий смогут отработать и на мобильных устройствах, но в целом не следует рассчитывать, что мобильный браузер и браузер настольного компьютера будут выполнять одни и те же последовательности действий.

Детальное обсуждение этих аспектов вы можете найти в статье «iPhone in Action» (см. раздел Ресурсы). В нашей статье мы ограничимся рассмотрением преимуществ WebKit, а не его недостатков.

Рассмотрим наиболее очевидную проблему, с которой сталкиваются пользователи iPhone или Android при доступе к Web-сайтам, а именно ограниченный размер экрана. Фактически экран современного мобильного устройства имеет размер 320x480 или 480x320, при условии, что пользователь предпочитает просматривать Web-контент в альбомной конфигурации. Как видно из рисунка 1, WebKit в состоянии корректно отобразить Web-страницу, разработанную для стандартных настольных компьютеров. Тем не менее, при масштабировании Web-страницы, ее текст может оказаться слишком мелким для чтения, так что пользователю придется воспользоваться функциями прокрутки, сдвига и увеличения, прежде чем он сможет прочитать текст. Как бороться с этим ограничением?

Наиболее простой способ создать страницу, одинаково хорошо отображаемую в окне мобильного браузера и в окне браузера настольного компьютера, это использование специального мета-тега viewport.

Мета-тег – это HTML-тег, размещаемый в заголовке HTML-документа. Самый простой пример использования тега viewport выглядит следующим образом: <meta name="viewport" content="width=device-width" />. При добавлении этого мета-тега к HTML-странице, ее отображение в окне мобильного браузера масштабируется наиболее оптимальным образом (см. рисунок 2). Браузеры, не поддерживающие viewport, просто игнорируют этот тег.

Рисунок 2. Web-страница, уменьшенная с учетом удобства просмотра на экране мобильного устройства
Рисунок 2. Web-страница, уменьшенная с учетом удобства просмотра на экране мобильного устройства

В отдельных случаях полезно заранее определить параметры масштабирования окна, как это показано на рисунке 3.

Рисунок 3. Отображение Web-страницы в заранее заданном масштабе
Рисунок 3. Отображение Web-страницы в заранее заданном масштабе

Для определения конкретных параметров масштабирования, укажите точное значение атрибута content мета-тега viewport: <meta name="viewport" content="width=device-width, initial-scale=1.0 user-scalable=yes" />. Изменяя значение параметра initial-scale, изображение может быть уменьшено или увеличено. Для платформ iPhone и Android лучше использовать значения от 1.0 до 1.3. Мета-тег viewport также поддерживает минимальный и максимальный масштаб, что позволяет ограничить возможности пользователя модифицировать масштаб страницы в процессе ее загрузки.

В то время как конструктивные характеристики iPhone, в частности размер экрана 320x480, практически не изменились с момента его появления, параметры устройств на платформе Android имеют достаточно широкий диапазон, так как мобильные устройства на этой платформе выпускаются различными производителями и предназначены для самых разных групп пользователей. Таким образом, если вы хотите, чтобы ваше Web-приложение пользовалось популярностью у мобильных пользователей, следует учитывать возможную разницу в размерах и разрешении экрана, а также конструктивных особенностях устройств на базе Android.

Опыт показывает, что помимо конструктивных различий, существующих между различными мобильными устройствами на базе Android, само программное обеспечение Android пытается установить настройки загружаемой Web-страницы в зависимости от свойств браузера мобильного устройства. Помимо стабильности, платформа Android отличается постоянно меняющимся набором функций и возможностей. Настройки конкретного устройства на базе Android, скорее всего, будут отличаться от настроек вашей среды разработки, в зависимости от версии SDK и производителя устройства. На рисунке 4 показан экран настройки браузера в версии V1.6 Android Emulator. Настройки экрана предоставляют пользователю возможность определить уровень масштабирования изображения на экране (far, near, medium) или выбрать режим автоматического масштабирования страницы.

Рисунок 4. Меню настроек Android Emulator
Рисунок 4. Меню настроек Android Emulator

В мире мобильных устройств самая постоянная величина – это перемены, так что следует учитывать развитие и обновление рынка мобильного ПО. Например, настройки браузера Sprint Hero включают в себя набор опций, который в корне отличается от стандартных параметров, используемых при загрузке Web-страницы. Браузер Hero построен на платформе Android V1.5 с использованием рядя модификаций, сделанных компанией HTC. К счастью, при использовании мета-тега viewport специфические настройки Hero будут игнорироваться.

До сих пор мы видели, что WebKit вполне справляется с загрузкой Web-страницы, хотя и в сильно уменьшенном и трудночитаемом виде. Затем мы расширили контроль над тем, как страница отображается на экране мобильного устройства за счет использования мета-тега viewport. Теперь отображаемая страница гораздо более удобна для чтения и навигации. Но этого все еще недостаточно для того, чтобы наша страница выглядела и функционировала как Web-приложение.

Сделано для мобильных устройств

Перейдем к рассмотрению особенностей дизайна Web-странцы, предназначенной для мобильной аудитории. В качестве конкретного примера рассмотрим страницу регистрации сервиса GMail электронной почты Google.

Так выглядит эта страница в окне браузера настольного компьютера:

Рисунок 5. Окно браузера настольного компьютера
Рисунок 5. Окно браузера настольного компьютера

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

Рисунок 6. Отображение окна регистрации на экране iPhone
Рисунок 6. Отображение окна регистрации на экране iPhone

Страница, показанная на рисунке 6, безусловно рассчитана на мобильных пользователей. На экране отображаются только те элементы страницы, которые необходимы пользователю для дальнейшей работы – не требуется никакой дополнительной прокрутки, смещения или масштабирования.

Теперь рассмотрим окно просмотра электронных писем мобильной версии Gmail. Поскольку экранное пространство, доступное приложению, весьма ограничено, окно просмотра сообщений имеет дополнительные кнопки и элементы навигации. При этом отображаемые навигационные элементы перекрывают окно для просмотра сообщений. Кроме того, не следует использовать слишком много фреймов или элементов прокрутки div, если этого можно избежать. Мобильная версия Gmail решает эту проблему путем использования всплывающего меню, которое появляется, как только пользователь заканчивает прокрутку страницы. Всплывающее меню содержит 3 кнопки: Archive, Delete и More. При нажатии на кнопку More появляются дополнительные элементы меню (см. рисунок 7).

Рисунок 7. Всплывающее меню
Рисунок 7. Всплывающее меню

Это действительно приложение, разработанное для мобильных устройств.

Следует учитывать, что мы не хотим намеренно обеднять дизайн и сокращать возможности работы мобильных пользователей, обладающих развитыми многофункциональными браузерами для платформ iPhone и Android. С этой точки зрения полезно обратить внимание на элемент, отображаемый внизу страницы Gmail (см. рисунок 8):

Рисунок 8. Предоставьте пользователю право выбора
Рисунок 8. Предоставьте пользователю право выбора

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

Теперь рассмотрим случай, когда вы хотите создать приложение, использующее Web-технологии, но выглядящее при этом как «родное» мобильное приложение.

Контент, специфичный для конкретной платформы

Следующий шаг – это разработка контента, специфичного для конкретной мобильной платформы. При этом формат и интерфейс страницы определяются таким образом, чтобы в результате страница выглядела как «родное» приложение для конкретной платформы, а не как стандартный Web-сайт общего доступа. Что мы имеем в виду под «родным» приложением?

Прежде чем углубиться в дискуссию о том, как сделать Web-приложение максимально похожим на «родное» приложение для конкретной платформы, давайте оставим в стороне общие свойства браузеров iPhone и Android и вкратце остановимся на визуальных отличиях, существующих между этими платформами.

Приложения iPhone имеют свой специфический вид и интерфейс. Покажите кому-нибудь снимок экрана iPhone и, если только этот человек не свалился буквально на днях с луны, он практически наверняка сразу же скажет, что это iPhone. Покажите этому же человеку снимок экрана мобильного устройства на базе Android, и ответ уже не будет столь однозначным. В чем причина? Существует несколько возможных объяснений. Во-первых, iPhone появился на рынке гораздо раньше устройств на базе Android и успел приобрести огромное количество поклонников. Вспомните людей, выстраивающихся в очередь, чтобы заплатить немалые деньги за ограниченные возможности V1 iPhone. Нравится вам iPhone или нет, этот продукт Apple является в настоящее время лидером рынка. А как обстоит дело с Android?

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

С течением времени, количество устройств в мире на базе Android превзойдет количество iPhone. Это объясняется тем, что устройства на платформе Android выпускаются целым рядом компаний и будут поддерживаться самыми различными сетями передачи данных. При таком значительном количестве игроков на рынке мобильных устройств Android, несомненно, следует ожидать определенной фрагментации рынка на базе внешнего вида и параметров устройств. Эта тенденция прослеживается на примере интерфейса SenseUI от компании HTC. Этот привлекательный внешний вид и интерфейс не поддерживается базовыми версиями Android SDK и не совместим с другими устройствами на базе Android. Компании Motorola, Google и Verizon объединили свои усилия для разработки нового устройства DROID на базе Android. Это первый коммерческий продукт на платформе Android версии 2.0.

Сравните разнообразие систем на базе Android с единообразным внешним видом iPhone. iPhone – особо ценная собственность Apple. Внешний вид приложений iPhone может слегка измениться со временем, но эти незначительные изменения вряд ли сравнятся с различными версиями систем Android, количество которых достаточно велико даже сейчас, когда платформа находится в самом начале своего развития.

Итак, что необходимо сделать для того, чтобы максимально приблизить внешний вид и интерфейс приложения к «родным» программам?

Если бы такая задача стояла перед нами до появления Web 2.0, это была бы действительно серьезная проблема. Ранние попытки поддержки нескольких клиентских браузеров (мобильных и стационарных) основывались на использовании нескольких подходов, например:

  • Разработка полностью параллельных сайтов
  • Динамическая генерация контента в зависимости от параметра userAgent
  • Использование прокси-серверов, которые смогли бы трансформировать контент в зависимости от каждого конкретного устройства. Подобная технология с успехом использовалась компанией RIM для организации доступа к электронной почте с мобильного устройства клиента.

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

К счастью, нам и не придется это делать. В эпоху WebKit и CSS разницу во внешнем виде и интерфейсе различных мобильных устройств можно преодолеть благодаря использованию таблиц стилей и media-запросов (media query), позволяющих использовать разные стили в зависимости от конкретного типа устройства. Технология media-запросов позволяет получить информацию о клиенте. Традиционно, браузер отправляет серверу значение userAgent, которое позволяет серверу идентифицировать конкретный браузер и определить контент, который должен быть передан клиенту. Используя media-запрос, браузер выбирает стиль страницы, исходя из своих возможностей. Следующий пример демонстрирует выбор таблицы стилей, предназначенной для смартфонов: <link rel="stylesheet" type="text/css" href="smartphone.css" media="only screen and (max-device-width: 480px)" />. А этот запрос определяет таблицу стилей для настольных компьютеров: <link rel="stylesheet" type="text/css" href="smartphone.css" media="only screen and (min-device-width: 481px)" />.

Internet Explorer V6

На момент написания этой статьи Internet Explorer V6 занимал примерно 20-30% общего рынка браузеров, однако рассмотрение возможностей IE V6 не входит в задачи данной статьи.

Более подробную информацию о media-запросах вы можете найти в предварительном варианте спецификации (см. раздел Ресурсы).

Рассмотрим пример использования media-запросов для разработки приложения, отображающего состояние серверов сети.


Программа мониторинга сети

Задача этого приложения – мониторинг работы нескольких серверов. Независимым разработчикам программного обеспечения зачастую приходится обеспечивать поддержку нескольких приложений на нескольких серверах. Если вы занимаетесь разработкой ПО сколько-нибудь значимое время, то наверняка вы уже сталкивались с разными типами серверов и разными типами приложений. Все это означает, что вполне возможна такая ситуация, когда вы не сможете использовать единый инструмент для отслеживания работы всех необходимых приложений. В этом случае имеет смысл воспользоваться мобильным приложением для мониторинга сети (netmon). Приложение обеспечивает всю требуемую функциональность, оставаясь при этом достаточно гибким и удобным для доступа с мобильного устройства.

Приложение netmon включает список серверов, работу которых необходимо отслеживать. Для каждого сервера собираются ключевые индикаторы производительности (KPI). Ключевые индикаторы производительности – основной инструмент, который в течение многих лет используют студенты MBA для оценки текущего состояния бизнеса. С точки зрения хостинга Web-приложений, в качестве KPI могут использоваться следующие показатели:

  • Количество транзакций за прошедший период времени
    • Заказы
    • Запросы на получение каталогов
    • Электронные сообщения
    • Количество просмотров страницы
  • Время, прошедшее с момента последней транзакции
    • Заказа
    • Обмена электронными данными
    • Сообщения от бизнес-партнера
    • Загрузки файла от вендора через FTP
  • Доступна ли база данных
  • Дата последнего резервного копирования
  • Средняя сумма заказа (в долларах)
  • Объем свободного места на диске
  • Пропускная способность за последний час, день, месяц

Вышеуказанные показатели и другие аналогичные операционные параметры позволяют оценить состояние конкретной системы или приложения. Так, например, во время отпускного сезона мы просматриваем количество заказов, размещенных на некоторых наших сайтах. В случае если данные не показывают стабильного увеличения количества заказов с каждым часом, мы проводим более детальный анализ ситуации.

Поскольку работа конкретного приложения требует своих условий и ресурсов, программа netmon должна обладать достаточной гибкостью, чтобы учитывать особенности каждого приложения. Для обеспечения подобного уровня гибкости, мы начнем с определения наиболее общей структуры данных, позволяющей учитывать параметры состояния каждой системы. В Части 2 мы подробнее остановимся на том, откуда поступают эти данные, и как они обновляются. Пока что ограничимся следующей информацией:

  • Имя сайта
  • URL-адрес сайта (домашней страницы)
  • URL-адрес для получения обновлений
  • Статус: ОК или нет
  • Краткая сводка: описание состояния сервера, которое будет либо иметь значение ОК, либо содержать текстовую строку с указанием наиболее серьезной проблемы для данного сервера
  • Элементы: это набор пар имя/значение, которые нам потребуются для передачи текущих значений KPI для соответствующего сайта.

Наше приложение будет отображать полученные индикаторы эффективности в удобном для навигации виде, максимально используя возможности CSS, jQuery и WebKit для того, чтобы привлечь внимание пользователя к проблемным зонам. Как мы уже упоминали, основная цель при разработке данного приложения – возможность выполнять его на платформе iPhone, Android и на настольном компьютере в браузере Safari.


Разработка приложения для мониторинга сети

Современные Web-страницы должны создаваться в декларативном виде, определяющем организационную структуру и контент страницы. Позиционирование и форматирование страницы выполняется при помощи каскадных таблиц стилей CSS и, в большинстве случаев, с использованием JavaScript. Фактически, библиотеки JavaScript стали настолько популярны, что их использование сегодня – это скорее правило, чем исключение. В приложении, рассматриваемом в данной статьи, мы воспользуемся популярной библиотекой JavaScript jQuery. Наше приложение будет выполняться на платформе iPhone, Android и на настольном компьютере. При этом будет использоваться один и тот же код HTML, а все необходимые отличия будут реализованы в таблицах стилей. Здесь необходимо отметить, что мы сознательно не прикладывали каких-либо значительных усилий для разработки привлекательного внешнего вида приложения. Более того, в качестве фона сознательно были выбраны броские, не гармонирующие друг с другом цвета, чтобы привлечь дополнительное внимание читателя к организации таблиц стилей. В Части 2 мы слегка улучшим внешний вид приложения, а пока его HTML-код выглядит так, как показано в листинге 1.

Листинг 1. HTMLкод приложения
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta name="viewport" content="width=device-width" />
<link rel="stylesheet" href="netmon.css" type="text/css" />
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="netmon.js"></script>

<script type="text/javascript">
   if (navigator.userAgent.indexOf('iPhone') != -1) {
      document.write('<link rel="stylesheet" href="iphone.css" 
type="text/css" />');
   } else if (navigator.userAgent.indexOf('Android') != -1) {
      document.write('<link rel="stylesheet" href="android.css" 
type="text/css" />');
   } else {
      document.write('<link rel="stylesheet" href="desktop.css" 
type="text/css" />');
   }

function setupTestData() {
   try {
      netmon.initialize();
      if (netmon.resources.length > 0) {
         jQuery.each(netmon.resources,function (index, value) {
            $("#mainContent").append(netmon.render(index,value));
         });
         $(".serverentry").click (function() {$(this).find(".serveritems").toggle();});
         $(".serveritems").hide();
      }
   } catch (e) {
      alert(e);
   }
}
   
</script>
   
<title>My Network Resources</title>
</head>
<body onload="setupTestData();">
<div id="mainContainer">
   <div id="header">
      <h1>My Servers</h1>
   </div>
   <div id="mainContent">
   </div>
   <a href="q.php">My User Agent</a>
</div> 
</body>
</html>

Беглый просмотр предлагаемого HTML-кода позволяет выделить следующие основные особенности:

  • В коде используются два внешних файла JavaScript: один файл библиотеки jQuery и один вспомогательный файл для нашего приложения.
  • Для масштабирования отображаемого контента в коде используется мета-тег viewport.
  • Основная таблица стилей определяется файлом netmon.css.
  • Для определения вспомогательной таблицы стилей используется параметр userAgent. В зависимости от его значения будет подгружена таблица стилей для iPhone, Android или для браузера настольного компьютера.
  • В процессе загрузки страницы для отображения данных используется jQuery и вспомогательная функция, определенная в файле netmon.js.
  • В основном коде страницы используется несколько тегов div.
  • И наконец, в коде присутствует ссылка на страницу, которая показывает строку userAgent. Эта ссылка не имеет никакого отношения к работе приложения и используется исключительно для демонстрации.

Прежде чем приступить к подробному разбору таблиц стилей и файла netmon.js, которые, собственно, и определяют основную работу приложения, давайте взглянем на наше приложение в его текущем состоянии. Еще раз обратите внимание, что мы используем три различных таблицы стилей: по одной для каждой из трех поддерживаемых платформ. Чтобы процесс разработки приложения был более наглядным, каждая таблица определяет свой фоновый цвет. На рисунке 9 наша страница открыта в настольном браузере Desktop Safari и имеет синий фон.

Рисунок 9. Так выглядит приложение в браузере Safari для настольных компьютеров
Рисунок 9. Так выглядит приложение в браузере Safari для настольных компьютеров

Рисунок 10 демонстрирует, как будет выглядеть наше приложение в окне браузера Android с использованием красного фона.

Рисунок 10. Так выглядит приложение в браузере Android
Рисунок 10. Так выглядит приложение в браузере Android

Рисунок 11 демонстрирует внешний вид приложения в окне браузера iPhone (цвет фона - зеленый).

Рисунок 11. Так выглядит наше приложение в браузере iPhone
Рисунок 11. Так выглядит наше приложение в браузере iPhone

Основная таблица стилей, хранящаяся в файле netmon.js, приведена в листинге 2.

Листинг 2. Основная таблица стилей
body {
   color: #888888;
   font-family: Helvetica;
   font-size:14px;
   margin: 0px;
   padding: 0;
}
.details {
   margin: 0px;
   padding: 0px;
   background-color: white;
   border: solid;
   border-width: 1px;

   -webkit-border-top-left-radius: 8px;
   -webkit-border-top-right-radius: 8px;
   -webkit-border-bottom-left-radius: 8px;
   -webkit-border-bottom-right-radius: 8px;
}
.OK {
   color: #000000;
}
.BAD {
   color: #ff0000;
}
.odd {
   background-image: -webkit-gradient(linear, left top, right bottom,from(#ccc) 
,to(#999));
}
.even {
   background-image: -webkit-gradient(linear, left top, right bottom,from(#999) 
,to(#ccc)); 
}
.serverentry a {
   float: right;
   color: #ffffff;
}
.serveritems{
   color: #000;
}

#header h1 {
   margin: 0;
   padding: 0;
   text-align: center;
   color: #000;
}

Использование своей таблицы стилей для каждой платформы позволяет реализовать следующие задачи:

  1. Изменять цветовое решение страницы. Это позволяет, во-первых, наглядно продемонстрировать роль таблицы стилей, а во-вторых, показать, насколько просто выбрать нужную таблицу стилей в зависимости от значения параметра userAgent.
  2. Устанавливать разный размер шрифта для мобильной и настольной платформы.
  3. Проверить соответствующие функции WebKit. Это имело бы существенное значение, если бы для работы приложения использовался браузер без поддержки WebKit, например Firefox.

Листинг 3 демонстрирует код iphone.css файла.

Листинг 3. Файл iphone.css
body {
   background-color: #00ff00;
}
.serverentry {
   -webkit-border-top-left-radius: 8px;
   -webkit-border-top-right-radius: 8px;
   -webkit-border-bottom-left-radius: 8px;
   -webkit-border-bottom-right-radius: 8px;
}
.name {
   font-size: 2em;
}
.summary{
   font-size: 1.5em;
}
.serverentry a {
   font-size: 1.5em;
}

Как мы видим, в качестве фонового цвета тега body используется зеленый цвет (#00ff00), а размер шрифта настраивается для более удобного чтения с экрана мобильного устройства. Наконец, давайте взглянем на файл netmon.js, в котором определяется список серверов и функция, выводящая данные каждого сервера (используемая в листинге 4). Часть кода файла для краткости пропущена, полный его текст доступен в разделе Загрузка).

Листинг 4. Файл netmon.js
var netmon = {
   initialize : function () {
   },
   resources : 
   [
      {
         name : 'msiservices.com',
         homeurl : 'http://msiservices.com',
         pingurl : 'http://msiservices.com/netmon.php',
         status : 'OK',
         summary : 'OK',
         items : 
         [
          {name : 'DiskSpace', value : '22.13 GB'},
          {name : 'Database Up?', value : 'Yes'}
         ]
      },
      {
         name : 'server 2',
         homeurl : 'http://someurl',
         pingurl : 'http://someurl/netmon.jsp',
         status : 'OK',
         summary : 'OK',
         items : 
         [
          {name : 'DiskSpace', value : '100.8 GB'},
          {name : 'Database Up?', value : 'Yes'}
         ]
      },
// additional entries clipped for brevity

   ],
   render : function(index,itm) {
      try {
         var ret = ";
         ret += "<div class='serverentry " + itm.status + " " + (index % 2 == 0 ? 
'even' : 'odd') + "'>";
         ret += "<span class='name'>" + itm.name + 
"</span>&nbsp;&nbsp;<a target='_blank' href='" + itm.homeurl + 
"'>Show</a><br />";
         if (itm.status != "OK") {
            ret += "<span class='summary'>-" + itm.summary + 
"</span><br />";
         }
         
         ret += "<div class='serveritems'>"; 
         jQuery.each(itm.items,function (j,itemdetail) {
            ret += ">" + itemdetail.name + "=" + itemdetail.value + 
"<br />";
         });
         ret += "</div>";      
         ret += "</div>";
         return ret;
      } catch (e) {
            return "<div class='error'>Error rendering item [" + itm.name + "] 
" + e + "</div>";
      }
   }
};

Если строка состояния какого-либо сервера не равна ОК, то соответствующая запись сервера выводится красным, как видно из определения класса в файле CSS. Кроме того, если проверка статуса сервера выявила какие-то проблемы (статус не равен OK), дополнительно выводится краткое описание проблемы. На рисунках 9-11 видно, что на сервере 4 не хватает свободного дискового пространства. При нажатии на строку этого сервера на экран выведется подробное сообщение о проблеме (см. рисунок 12).

Рисунок 12. Подробное описание проблемы, обнаруженной на сервере 4
Рисунок 12. Подробное описание проблемы, обнаруженной на сервере 4

При нажатии на ссылку show справа от имени сервера открывается домашняя страница этого сервера. Наличие такой ссылки очень удобно по двум причинам: во-первых, это избавит вас от неприятной необходимости заучивать наизусть URL-адрес каждого сервера, а во-вторых, это избавит вас от еще более неприятной необходимости вводить этот URL-адрес с клавиатуры мобильного устройства (пусть даже и самой удобной).

Итак, если нам удастся успешно запустить netmon на мобильном устройстве, задача поддержки серверов не должна вызвать никаких проблем.

В Части 2 мы рассмотрим это приложение более подробно, добавим больше данных, получаемых в режиме реального времени, и обсудим ряд вопросов, связанных с серверной поддержкой мобильных приложений.

В заключение кратко коснемся вопросов, связанных с организацией загрузки нашего приложения из хранилища.


Web-приложение – в массы

Представьте, что процесс разработки программы для мониторинга сети успешно завершен. Вы продемонстрировали свое детище другу, и он настоятельно посоветовал вам выставить ваше приложение на продажу, чтобы другие пользователи также смогли воспользоваться им для наблюдения за ресурсами своих сетей. Как вам продать Web-приложение? Для продажи Web-приложения вы можете воспользоваться традиционной подпиской или моделью SaaS. Но что делать, если вы хотите собрать готовый пакет с вашим Web-приложением и выставить его на рынке приложений, например в он-лайн магазине iTunes App Store или Google Marketplace? Для этого ваше приложение должно быть скомпилированно как «родное». Сделать это можно следующим образом.

Каждая крупная мобильная платформа располагает инструментами, позволяющими встроить браузер в вид или в форму, или добавить его в качестве отдельной функции. Разные платформы могут использовать свои термины для определения подобного инструментария, тем не менее, все они используют одинаковый подход: управление браузером передается «родному» приложению, так что приложение может с ним работать. В упрощенном виде эта модель выглядит следующим образом: приложение получает управление браузером и указывает ему, какой контент следует загрузить по сети. Другой способ состоит в том, что «родное» приложение перехватывает запрос на открытие ссылки и предоставляет свой собственный контент, используя браузер только для отображения необходимой информации. При этом следует помнить, что HTML и CSS являются вполне конкурентоспособной альтернативой использованию «родных» виджетов, независимо от источника контента, используемого приложением. Некоторые приложения используют комбинацию двух вышеуказанных моделей, так, например, приложение может получить большую часть контента из сети, но при этом «родная» часть приложения обеспечивает доступ к локальным ресурсам с помощью Bluetooth.

В настоящее время на рынке предлагаются несколько средств разработки приложений с подобной архитектурой, однако лидирующие позиции в этой сфере занимают PhoneGap и Appcelerator (см. раздел Ресурсы).


Заключение

Эта статья знакомит с принципами разработки Web-приложений для iPhone и Android с использованием технологии WebKit. В Части 2 мы расширим возможности нашего приложения, добавив функцию обновления данных с использованием вызовов Ajax.


Загрузка

ОписаниеИмяРазмер
Network app source codeos-androidiphone1-browserwars1sourcecode.zip23KB

Ресурсы

Научиться

Получить продукты и технологии

  • Скачайте Android SDK, получите доступ к API и узнайте последние новости об Android.
  • Android – это открытый продукт, так что вы можете загрузить исходный код системы с сайта Android Open Source Project (EN).
  • PhoneGap (EN) – открытое средство разработки, позволяющее легко и быстро создавать мобильные приложения с помощью JavaScript.
  • Воспользуйтесь Appcelerator (EN) для разработки, тестирования и распространения Web-приложений для мобильных устройств и настольных компьютеров.
  • Воспользуйтесь при разработке вашего следующего открытого проекта пробными версиями ПО IBM (EN).
  • Ознакомительные версии продуктов IBM и практические занятия в "песочнице" IBM SOA (EN) помогут вам освоить инструменты разработки приложений и промежуточное ПО семейств DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Open source
ArticleID=555257
ArticleTitle=Android и iPhone – войны браузеров: Часть 1. WebKit спешит на помощь
publish-date=10202010