Интересные статьи об Apple, приложениях для iPhone и iPad, iTunes

HTML5 в мобильной разработке — что выбрать?

HTML5 в мобильной разработке — что выбрать?

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

Устоявшиеся мнения о преимуществах кросс-платформенной разработки с использованием HTML5 или Native SDK:

HTML5

  • Лёгкое вхождение для веб-разработчиков
  • Дешево в разработке
  • Большое покрытие (браузер сейчас есть везде)
  • Единая база кода


При помощи таких средств как, например, Cordova, на HTML5 можно создавать гибридные приложения (которые размещены не в интернете, а в нативном контейнере). Такие приложения совмещают перечисленные выше плюсы и посредством плагинов позволяют выйти за пределы браузера, осуществляя тесную интеграцию с возможностями устройств. Гибридные приложения можно публиковать и распространять через AppStore, Google Play и другие магазины приложений.

Native

  • Нативные ощущения и внешний вид
  • Интеграция с аппаратной частью без ограничений
  • Интеграция с софт частью (например, вызвать твиттер или Facebook из приложения)
  • Нет привязки к браузеру
  • Полноценные IDE для разработки и отладки приложений


Естественно, это базовые утверждения, которые каждый может дополнить исходя из своего опыта. Так стоит ли выбирать HTML5 для разработки вашего приложения? Ответ не может быть однозначным — он зависит от множества факторов, которые мы и рассмотрим.

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



В 1995 году в нашем распоряжении был Mac OS, Windows 95 и Linux. Для каждой из операционных систем было свое программное обеспечение, но мысли о кросс-платформенности уже появлялись.

В 1996 году Sun Microsystems выпустила продукт под названием Java. Этот продукт имел высокий уровень абстракции для написания единого кода под разные ОС. Это была уже, действительно, кросс-платформенность в том виде, в котором мы привыкли её видеть. Но UI был одинаковый для каждой из систем.

Далее был этап развития, в течение которого возникали сущности, реализующие определённые уровни кросс-платформенной абстракции такие как WebKit, OpenGL, git и т.д. Это были стандарты, которые следовало использовать при написании приложений. UI мог отличаться в каждой системе, но тот же OpenGL был одинаков.

Параллельно активно развивалось и веб-направление. Вначале это были статические страницы, связанные ссылками. Но достаточно скоро в них стало появляться все больше динамики. Внедрение технологии AJAX и почтового клиента GMail (как первого полноценного и достаточно сложного веб приложения) заставило говорить о Web 2.0.

Единственное, что могло приостановить это нашествие — Flash и Silverlight. Которые так же, как и новорождённый HTML5, решали одну проблему — написание полноценного “толстого” клиента в браузере.

В результате, HTML5 обрёл свою нишу. Этому способствовал ряд факторов:

  • открытая платформа
  • не все веб-разработчики хотели учить другие языки разметки и языки программирования (Flex+ActionScript у Adobe и XAML+C# у Microsoft);
  • Flash и Silverlight не предоставляли качественного кросс-платформенного решения. В Linux возникали постоянные проблемы с поддержкой Flash, а реализация Silverlight от Mono отставала. Отказ от поддержки Flash на мобильных платформах (iOS, и позднее Android) породили высказывания “Flash умер”.


В то же время JavaScript, являющийся фундаментом HTML5, имеет некоторые очевидные и досадные недоработки. Но возможности кросс-платформенности, лёгкость освоения и большая распространенность среди веб-разработчиков спасают его и даже держат в тренде.

Так, примерно с 2005 года браузеры стали ещё одним уровнем кросс-платформенности. Такие приложения как Google Maps, GMail и Facebook стали использоваться всё активнее. Оказалось, что очень удобно работать в браузере на любой операционной системе и нет необходимости устанавливать дополнительное десктопное ПО.

Таким образом, мы видим четыре уровня развития кросс-платформенности:

  • Для каждой из OС отдельное приложение, написанное по своим правилам.
  • Единый код, единый UI, рантайм прослойка (как, например, Java или Silverlight).
  • Общие спецификации, UI нативный для каждой из систем (например, OpenGL).
  • Приложения в браузере.


Возникает вопрос, можно ли применить данную градацию для мобильной разработки?
Если писать нативно, то попадаем в первый пункт когда для каждой мобильной ОС полностью свой код и свой UI. Любое приложение нужно будет переписать под каждую платформу.

Естественно, что в такой ситуации возникли решения для оптимизации разработки под различные платформы, при единой базе кода. Такими решениями на данный момент являются:

  • HTML5-фреймворки
  • Платформы с собственным рантаймом: например, AS3 Adobe AIR, .NET Xamarin
  • Трансляторы и кросс-компиляторы, например Appcelerator Titanium


Эти решения покрывают 2-4 пункт градации десктопных приложений под различные платформы. Рассмотрим каждое подробней.

AS3 Adobe AIR


AIR наиболее похож на Java и предоставляет свой рантайм для десктопа и мобильных приложений. Конечно, можно отслеживать, на каком устройстве мы запустили, и принудительно выставлять соответствующий UI. Но, в большинстве случаев, приложения имеют единый UI. Типичное AIR приложение — это игра, например, Angry Birds. Есть и бизнес приложения, например Photoshop Touch.

.NET Xamarin


.NET Xamarin приближен к нативной разработке, (например, мы можем использовать дизайнер интерфейсов Xcode), но при этом разработка может вестись в Mono Develop и Visual Studio. Данное решение успешно демонстрирует кросс-платформенность C#. Производительность приложений не уступает уровню нативных. Но UI под каждую из платформ необходимо писать отдельно.

HTML5 фреймворки


Идея делать мобильные приложения используя HTML5 понятна, это кратчайший шаг из браузера в мобильное устройство, на основе готовой базы кода и знаний. Низкий порог вхождения для многочисленной армии веб-разработчиков и покрытие всего спектра устройств. А если есть готовые UI элементы под каждую из платформ, то усилия и затраты минимальны.

Звучит отлично, но мир жесток, и чудес не бывает. Семь лет активной пропаганды и развития HTML5 дали свои плоды (хорошую инфографику можно посмотреть на Хабре). Мы можем найти примеры качественных гибридных HTML5 приложений:

  • Приложение Touralot от разработчика KnockoutJS для iOS, собранное при помощи PhoneGap и использующее Azure Mobile Services.
  • Быстрый Facebook от Sencha
  • Приложение Fly Delta с миллионом установок для клиентов Delta Airlines
  • Приложение tradeMonster, ставшее поводом для обсуждения на techcrunch


Однако, до сих пор существуют проблемы при разработке мобильных HTML5 приложений:

  1. Производительность UI
    • Манипуляции с UI работают в один поток (хотя для логики приложения можно использовать Web Workers).
    • Большое потребление памяти, т.к. кроме кода приложения необходимо запускать WebView.
    • Скорость исполнения JavaScript невысока.
    • Работа с DOM потребляет много ресурсов.
  2. Нет унификации платформ
    • Доминирует WebKit, но существует Windows Phone, в котором необходимо поддерживать IE. Другие игроки, такие как Mozilla, тоже пытаются выйти на рынок.
    • Каждая платформа предоставляет свои размеры экранов для телефонов и планшетов.
    • Разные требования к UI на каждой из платформ. И, естественно, баги платформы, не зависящие от багов конкретного фреймворка.
  3. Чужеродность UI
    • Приложение — всего лишь HTML-страница.
    • Sencha Touch, jQuery Mobile не похожи на нативные приложения.
    • Имитации UI страдают эффектом “зловещей долины”, иногда этот эффект проявляется со временем и зависит от частоты использования приложения
  4. Отсутствие средств разработки и отладки “из коробки”
    • HTML5 позиционируется как средство, которое вы можете использовать в вашем окружении разработки. Но, на самом деле, отладка HTML5 приложения на устройстве не самый простой процесс. Нативные средства, AIR и Xamarin предлагают полноценные IDE для разработки и отладки.
  5. Ограниченный доступ к аппаратным возможностям
    • набор PhoneGap плагинов из коробки скудный, а разработка своего равноценна разработке с использованием Native SDK

Таким образом, мобильные HTML5 приложения имеют много рисков при разработке. Но и возможности покрытия устройств велики. PhoneGap предоставляет доступ к аппаратным возможностям устройств, предоставляя мостик между браузером и реальным устройством. В сети можно найти много статей по данному вопросу, хороший пример интересного и развёрнутого обзора — "почему мобильные веб приложение такие медленные?".

Когда стоит использовать HTML5
  • Когда вы отлично разбираетесь в веб технологиях, например вы профессиональный веб разработчик.
  • Когда хочется поддерживать единый код.
  • Когда необходимо иметь приложение, охватывающее весь спектр платформ.
  • Когда нет жестких требований к UI, он простой и не содержит сложных эффектов.
Что на самом деле?


Вот результаты опроса, который я провел в рамках недавней статьи (проголосовало 507 человек):

  • Нативные средства под каждую из платформ 46%(287)
  • AS3 Adobe AIR 15%(96)
  • HTML5 фреймворки 30%(186)
  • .NET Xamarin 9%(56)


(как вы заметили, ChartJS отлично подходит не только для визуализации котиков)

Очевидно, ниша HTML5 разработки под мобильные платформы не пуста. Мы в DevExpress решили реализовать вариант с HTML5, и о результатах уже был пост.

Мы выпустили фреймворк для разработки мобильных приложений PhoneJS. На данном этапе развития технологий HTML5 имеет некоторые ограничения. Наше решение тоже не попадает в область чудес, но часть проблем мы преодолели, а часть готовимся решить. Мы работаем над устранением основной причины по которой разработчики скептически относятся к HTML5 приложениям — производительность UI.

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


Так мы берём на себя заботу об UI, а пользователь пишет UI-independent логику, которая на 99% не зависит от браузера. Фактически пользователь пишет приложение, а фреймворк делает так, чтобы под каждой платформой оно смотрелось максимально нативно, в соответствии с требованиями платформы. Естественно, могут возникать некоторые проблемы в производительности, но если приложение решает ваши задачи и вы заплатили за его разработку и поддержку в 10 раз меньше чем за нативное, то такое решение выгодно.

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

Отличной иллюстрацией использования нашего фреймворка могло бы быть приложение для таксопарка или авиаперевозчика, решившего следовать тенденциям BYOD. Приложение должно работать на большом спектре устройств и быть достаточно удобным как внутри компании, так и снаружи. При этом приложение будет клиентской частью общей системы которая уже существует в компании. Уже упомянутое приложение Fly Delta — хорошая иллюстрация.

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

В заключение необходимо добавить тот факт, что количество мобильных платформ растет. Появляются и закрепляют свои позиции новые платформы Firefox OS, Tizen от Samsung. Гибридные приложения на HTML5 — хорошее средство для создания действительно мультиплатформенных приложений. Эти факты вселяют уверенность в то, что данное направление будет развиваться, особенно, в сфере бизнес приложений.

А фреймворк PhoneJS позволит вам быть на волне технологий, не задумываться о многообразии платформ, а заниматься решением конкретной бизнес задачи.

Сайт: http://habrahabr.ru/hub/mobiledev/

Copyright: Mobile Development

Автор: SeOd