Компания
67,29
рейтинг
11 июля 2013 в 13:15

Разработка → 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 позволит вам быть на волне технологий, не задумываться о многообразии платформ, а заниматься решением конкретной бизнес задачи.
Автор: @SeOd

Комментарии (50)

  • +9
    iOS/Android/WP — не получиться сделать универсально и удобно, для каждой из ОС приходиться допиливать UI, тем самым теряя смысл кроссплатформенного приложения.
    Я уже молчу о том, что в Android WebView не настолько хороший, что бы на нем делать красивое и быстрое UI, ну и скорость довольно сильно уступает нативному.

    А в итоге получаем проблем больше (с одним только JS), чем если вести разработку на нативной платформе.
    • –4
      Действительно ли больше? Если не так важна производительность, то на весах оказываются две проблемы:
      1) Учить Java & C# & Objective C и разрабатывать интерфейс для каждой платформы.
      2) Просто переделать интерфейс для каждой платформы (везде используя HTML+JS).
      И тут действительно есть что взвесить.
      • +19
        Я вам гарантирую, что с JS вы получаете проблем больше, чем с Java + Obj-C вместе взятые. Это касается более или менее функциональных приложений т.е. где много логики.
        • +3
          А кто спорит?

          В статье были примеры применимости веб-фреймворков для создания приложений. Много ли функционала и логики в приложениях для таксопарка? Скорее всего нет. Вот для них JS — самое оно. А для функциональных приложений лучше Native SDK, никто и не спорит.
        • +1
          А если использовать TypeScript?
        • +1
          Это зависит исключительно от ровности рук и выбранных средств разработки. Я абсолютно согласен с Вами, если вы о jQuery-style.
          Но
          К примеру использую google closure library. Размер исходников десятки мегобайт.
          Проблем с размером приложения итп не имею вообще. Контроль типов, пространства имён, автоматическое документирование, кодхинтинг в иде — всё это абсолютно так-же как и в Java + Obj-C.
          В результате 95% кода отлично работают от вэба до андроида или иоса.
    • +7
      Мдя, похоже, не получилось у Юры обьяснить нишу применимости HTML в мобильных приложениях.

      Ну вот давайте на примерах. Вот два гибридных приложения:

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

      Fly Delta — а это пример приложения которое имеет смысл делать в HTML, потому что функционально это интерфейс к вебсервисам компании Delta, и HTML/JS вполне справятся с такими задачами.

      Нюансы здесь в том, что если бы Untappd выглядело криво, то даже при хорошей задумке быстро бы сделали более красивый аналог и все. А число пользователей Fly Delta зависит не от вылизанности программы, а насколько она полезна и юзабельна. Меню работает? Зачекиниться на рейс можно? Удобнее чем на сайт лезть с мобильника? Нотификации приходят? Все — что еще нужно? В данном случае скорость доступа к удаленным данным все равно не зависит от того на чем написано. Скорость работы JavaScript достаточна чтобы пришедшие данные показать. Ощущения от работы с приложением данного типа зависят больше от юзабилити, чем от того, какой код рисует UI и какими средствами.
  • +3
    От себя добавлю что PhoneGap не такой уж и быстрый. Если приложению не так важны какие-то функции, советую посмотреть на CocoonJS. Он и WebGL поддерживает (но плагины доступны премиум юзерам), есть webView. На android play достапны примеры скорости, и один пример у меня в профайле
    • +3
      Ну, если быть точным, то на 99% скорость обоих (PhoneGap и CocoonJS) зависит от скорости встроенного WebView контрола на каждой конкретно взятой платформе, они своих браузеров или JS engine не предоставляют. Нюансы могут быть в реализации «моста» между JS и нативным кодом, но это обычно не самые критичные имеено к скорости места.
      • +1
        Не совсем так, WebView у них как плагин. Если писать чисто игру на JS, быстродействие там очень даже велико, как я понимаю он не использует WebView в этом случае

        Вот пример игр запечатаных на CocoonJS:

        play.google.com/store/apps/details?id=com.ideateca.android.ibasket
        play.google.com/store/apps/details?id=net.alexeyshishkin.jb
        Пример WebGL: play.google.com/store/apps/details?id=com.ludei.demos.webgl
        • 0
          Насколько я знаю, у какуна только ускоренный(прямой) вывод канваса. Этим он и отличается от кордовы
        • 0
          Очень ОЧЕНЬ спорная ссылка. Я например больше доверяю собственному опыту и http://caniuse.com/webgl а они утверждают что чистого WebGL нет ни на иосе ни на андроиде. Единственный вариант это если они имплементировали собственный вэбвью…
  • 0
    Прошедшие комментарии только подтверждают мысли против вчерашнего заминусованного перевода в этой статье коммент к «9 признаков того, что не стоит нанимать этого Веб-разработчика»: — HTML5 довольно часто всё ещё спорно для разработки.
  • 0
    Как раз на днях была развернутая статья на тему «почему мобильные веб-приложения такие медленные».
    Статья и обсуждение (англ.).
    • 0
      Ссылка на неё ведь уже есть в статье выше :)
  • +2
    Работаем над приложением для iPhone, используем технологии Sencha Touch/Cordova с небольшим числом нативных плагинов.

    Скорость рендеринга на iPhone 4 слабоватенькая, то есть это выражается в небольшом притормаживании анимации переходов из одной карточки в другую, но в целом работает и пользоваться можно. На iPhone 4S/5 работает хорошо, вполне удобно пользоваться. Уже запущена и работает версия под iPad. Под Android — работает шустро на топовых устройствах aka Samsung Galaxy S4.

    Из плюсов, которые я вижу в использовании Sencha Touch — это неплохие компоненты, биндинг.

    Для себя решил работать в этом напрвалении.

    Из других плюсов (имею ввиду использование HTML5 на моб устройствах) — это проще найти и переучить специалиста, до этого работающего с клиентскими технологиями.
  • +1
    Jiayu G2, загрузил семпл workout, все списки тормозят очень сильно, да и любое изменение в UI. А ведь это приложения вообще практически логикой не обремененные, насколько я понимаю (код не смотрел, мало ли что там происходит о_О)

    Сейчас еще на айфоне потестим…
    • +2
      iPhone 4 немного шустрее, но все равно не юзабельно. Привыкший к плавности нативных приложений человек сразу снесет такого ужасного монстра)
      • +3
        Автор пытается подтвердить гипотезу о том, что существуют такие типы приложений, для которых желаемый результат можно получить с использованием HTML5, затратив при этом гораздо меньше ресурсов чем с использованием нативной разработки. Другими словами, типы приложений, для разработки которых HTML5 более эффективен. И здесь речь идет не о том, когда человек выбирает одно из десятка приложений опубликованных в аппсторе, и может безболезненно снести одно и поставить другое, а о том когда ему приходится выбирать между «объехать все точки в городе, записать на бумажку и вечером перенести все в базу данных вручную» и «воспользоваться мобильным приложением, которое местами притормаживает и провести 2 оставшихся вечером часа за кружечкой пива или в кругу семьи». Для меня выбор был бы очевиден. Минус здесь в том, что приложений подобного типа нет в списке демок продукта.
  • 0
    Я столкнулся со следующими проблемами HTML5 фреймворков: svg в андроидах 2, воспроизведение звуков, возможность создания экранов на время загрузки приложения, реакция на кнопки выхода из приложения.
    • 0
      всё что вы перечислили я делал в phonegap без каких либо проблем. другое дело что это работает медленнее чем нативные приложения…
      • 0
        У меня в нем звук не работал, шрифты отображались коряво, как будто движок старый.
        Вообще есть впечатление, что тема очень востребована, но нет русского сообщества. Начиная с тонкостей установки Эклипса, который надо в режиме администратора запускать.
        • 0
          я всё делал в блокноте, компилил через сайто phonegap. Звук работал но с тормозами. С кнопками проблем не было. Андроид 4.1. Но я всё равно в итоге пришёл обратно к нативным приложениям. Это более стабильно.
  • 0
    Фактически пользователь пишет приложение, а фреймворк делает так, чтобы под каждой платформой оно смотрелось максимально нативно, в соответствии с требованиями платформы.

    А есть какой-то фреймворк, который НЕ старается придать интерфейсу OS-нативный вид?
    Если я хочу сделать простое приложение в нейтрально-минималистичном стиле. Мне только нужно, чтобы все работало, максимально надежно, быстро и совместимо.
    • 0
      Все зависит от того, что конкретно Вам нужно от фреймворка. Если нейтральный UI, можно посмотреть на twitter bootstrap или jQueryMobile, где можно воспользоваться конструктором тем. А так, конечно, все познается в сравнении :)
      • +1
        Я про другое. Фреймворк (обертка, интерфейс, не знаю как лучше назвать), который:
        — даст движок с роутером урлов;
        — даст доступ к железным функциям телефона (типа геолокации);
        — позволит приложению работать в полноэкранном режиме на всех популярных мобильных ОС (ну как минимум iOS+Andriod, но желательно и прочие).

        Но при этом чтобы он не влезал в вопросы отрисовки кнопок. Во-первых, 100% аутентичности все равно не достичь, а во-вторых, CSS-код я прекрасно умею писать сам.
        • 0
          Для роутинга можно найти множество бесплатных JavaScript библиотек. API для геолокации доступно в большинстве современных браузеров. Если нужно больше, то можно воспользоваться PhoneGap API. Для упаковки в нативный контейнер, можно использовать PhoneGap build. Если не хочется самому реализовывать транзишны между вьюшками и другие аспекты SPA, то можно взять тот же PhoneJS, которому посвящена эта статья и отказаться от использование встроенных виджетов и лейаутов, сверстав UI самому, тем более если Вы это прекрасно умеете делать, а фреймворк позволяет. Разве что заплатить за виджеты все равно придется (если планируется коммерческое использование), т.к. они не поставляются отдельно.
  • +3
    Спасибо за ссылку на статью про эффект “Зловещей долины”, очнулся через минут 15 читая статью про «Плачущего мальчика».
  • +1
    Посмотрел демки PhoneJS на своем телефоне (недорогой андроидофон) — плане скорости все о-очень печально. Лаги такие, что в реальной жизни этим пользоваться невозможно. К большому сожалению.
    Обладатели пятых Афонов и Геллакси S3/4 — хотя бы у вас нормально?
    • +1
      Говорю как обладатель бюджетного андроид-девайса. На айфонах начиная с 4S и андроидах с хорошим железом все намного лучше.
      Текущее, разрабатываемое нами HTML5-приложение (+Cordova), которое достаточно интенсивно использует Canvas + библиотеку Sencha Touch тестировалось на Prestigio. С производительностью явные проблемы. Так же тестировалось на Galaxy S4 — субъективно, производительность выше, чем на iphone 4s.
      • 0
        Я там снизу линканул видео на фонгап демо, сенча не идеальна — она просто самая раскрученая.
        • +1
          Да, согласен. Просто они одни из первых начали интересоваться и делать что то.

          Да, библиотека громоздкая — комопненты-обертки практически для всех мелких элементов. Это естесственно выливается в большие затраты в производительности. Но порог вхождения за счет такого подхода снижается.

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

          Одна из оптимизаций — использование вместо списков Ext.dataview.List самописного компонента, реализующего самые простые фичи данного компонента — просто вывод списка кнопок и пару событий. И такими оптимизациями приходится заниматься.

          Тем не менее, на выходе мы имеем в короткие сроки приложение для топовых айфонов и андроид устройств ну и потенциально для веба.
  • 0
    Почему обошли стороной Qt? Там интерфейс можно делать и на HTML5, и на QML, и виджетами.

    И там мне очень нравится подход, когда само приложение на C++ и работает везде без изменений, а вот интерфейс на QML и создается под каждую платформу свой.
    • 0
      Присоединяюсь, считаю Qt очень даже конкурентной в ближайшем будуем (пока все на стадии TP).
  • –1
    Думал задать вопрос в Q&A и скорее всего там и задам, но какие «движки» html5 видит сообщество для разработки игр, мы сейчас рассматриваем альтернативы?
  • +2
    1) на андроиде нет WebWorkers, поэтому о каком их использовании может идти речь?
    2) приведенная ссылка абсолютно не обясняет тонкостей и проблем мобильных приложений. «Масло масляное», поверте я когда перобретаю смартфон я догадываюсь что он будет медленее моего десктопа или ноута.
    3)«Так мы берём на себя заботу об UI, а пользователь пишет UI-independent логику, которая на 99% не зависит от браузера.» извините, но это не самое необходимое. Как раз наоборот: более чем в 90% случаев — заказчик хочет нестандартный UI(поверьте, наша компания имеет опыт в разработке более чем 150 мобильных приложений, из них только 4 для собственного бренда), и что потом делать?

    и т.д.

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

    В качестве затравки видео на програму которая делает абсолютную хрень.
    PhoneGap программа была написана за 6 часов и UI оптимизация 11 часов, в первом виджете отображается через слайд 14 000 объектов данных.
    Хочу также обратить внимание на UI, его верстка не вошла во время разработки — просто парень сел и наваял кнопки и бары которые ему нравятся за 4 часа. Это по поводу «хочу кнопочки, но не такие»

    Для того чтобы педалить фреймверки надо понимать зачем и какие проблемы они решают.
    • +1
      А в чем заключалась UI оптимизация? Хотя бы в общих чертах.
    • +4
      по пунктам:
      1) речь может идти о об их использовании с фоллбэком (fallback, он же graceful degradation). Работает — хорошо, не работает — запустили в основном потоке выполнения

      3а) это, очевидно, кастомно-красивые приложения. А PhoneJS ориентирован во многом на бизнес-составляющую
      3б) ну и это — «берём заботу...» — это то, что предлагают, а не навязывают. Хочешь, бери. Не хочешь — не бери, пиши своё. Хочешь — бери только навигацию, а кнопочки верстай как душе угодно…

      по демке:
      хорошая штука получилась. Статью жду )

      По перформансу:
      на канве вот товарищ из твиттера показал 60 fps.
      просто к слову пришлось )
    • +3
      1) на андроиде нет WebWorkers, поэтому о каком их использовании может идти речь?

      Если Вы что-то слышали о graceful degradation и progressive enhancement, то Вам должно быть очевидно, что глупо отказываться от использования какой-то фичи, только из-за того что ее не поддерживает какая-то часть целевых устройств. Нет поддержки WebWorkers — сменим стратегию на однопоточное вычисление. Но там где они поддерживаются приложение станет более отзывчивым. Более того, я уверен, что в последующих версиях андроида WebWorkers станут доступны, или встроенный браузер вовсе заменят на Chrome.

      когда перобретаю смартфон я догадываюсь что он будет медленее моего десктопа или ноута.

      Суть статьи по приведенной ссылке не в том чтобы сказать что мобильник медленнее десктопа, а в том чтобы сравнить по производительности web/native, причем не только в терминах быстрее/медленнее, но и в конкретных цифрах. Уверен, многие нашли эту информацию полезной.

      «Так мы берём на себя заботу об UI, а пользователь пишет UI-independent логику, которая на 99% не зависит от браузера.» извините, но это не самое необходимое. Как раз наоборот: более чем в 90% случаев — заказчик хочет нестандартный UI(поверьте, наша компания имеет опыт в разработке более чем 150 мобильных приложений, из них только 4 для собственного бренда), и что потом делать?

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

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

      В-третьих, не нужно путать понятия «позволяет» и «обязывает». PhoneJS позволяет не задумываться об отрисовке UI, если в этом нет необходимости, но в то же время он позволяет откастомизировать UI в соответствии с требованиями, если это необходимо. Хоть с нуля можно наверстать.

      В качестве затравки видео на програму которая делает абсолютную хрень.

      Без комментариев.

      Для того чтобы педалить фреймверки надо понимать зачем и какие проблемы они решают.

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

        Вы это называете частью?
        Без комментариев.

        причем не только в терминах быстрее/медленнее, но и в конкретных цифрах.

        Порой мне кажется, что основное достижение команды разработчиков iOS очень часто остается без внимания рецензентов: факт того, что на всех iOS устройствах движение пальцев по экрану вызывает точно соответствующее им перемещение объектов. Не подмораживает, не вздрагивает, создается иллюзия, будто вы физически управляете объектом. Всякий раз когда я беру в руки новое устройство под управлением Android и пользуюсь им, я удивляюсь, обнаружив, что его интерфейс не так отзывчив, как на устройствах iOS. Jason Snell

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

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

        А я это не утверждал — будьте внимательны. Я утверждал:
        более чем в 90% случаев
        можно к примеру посмотреть скриншоты много там программ со стандартными кнопками? Возможно я и преувеличил, но все равно нестандартного больше половины. Прошу заметить, что и раньше и сейчас, речь не идет о стандартных UI патернах, а именно о стандартных элементах управления реализованных в указаном фреймверке.

        позволяет откастомизировать UI в соответствии с требованиями

        Не хочу вас расстраивать, но на мобильных браузерах это не всегда приемлемо использование css фреймверка для UI, мало того, как правило это идет во вред приложению. К примеру здесь предлагают отказаться от слайд анимации на андроиде, а у нас она летает даже на двойке. Это не потому что мы такие 'умные', а просто потому что мы понимаем как надо сделать чтобы конечному юзеру понравилось. А JQueryMobile посильнее будет PhoneJS.

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

        И я не увидел
        зачем и какие проблемы они решают
        то что не делают другие фреймверки.

        Хочу пригласить Вас в Одессу мы с коллегой прочитаем доклады именно по мобильной разработке: о PhoneGap, да и о том как влияет впечатление от программы на прибыль заказчика приложения.
        • 0
          Все же считаю что WebWorkers не заслуживают такого внимания, которое мы им здесь уделяем, думаю это вопрос времени, учитывая популярность, которую набирает Android. Ваши 90% я бы еще умножил на процент пересечения рынков вашей компании и целевого рынка PhoneJS, к сожалению сложно сказать насколько сильно они пересекаются. Эта информация была бы действительно ценной. Т.к. пока не понятно почему же эти 90% не хотят стандартный интерфейс и готовы платить за это (перекрасить кнопки в зеленый цвет — не считается). Ваш доклад с удовольствием бы послушал, спасибо за приглашение. Ну и если у вас действительно есть какие-то революционные наработки в области мобильной веб-разработки, ждем реализации PropertyCross.
      • 0
        В качестве затравки видео на программу которая делает абсолютную хрень.
        Без комментариев.


        К сожалению, вы не увидели главного —
        программа была написана за 6 часов
        и человек не использовал UI фреймверков
        сел и наваял кнопки и бары которые ему нравятся за 4 часа

        Просто взять и использовать UI фрейверк +MV* — не поможет написать программу на Phontgap — тут надо «понимать все сразу»
        • +1
          К сожалению, главное не это, главное когда будет написано конечное приложение в соответствии с требованиями и будет летать также как и спайк созданный на коленке за полчаса. По опыту было много случаев когда команда с горящими глазами после реализации такого спайка допиливала его до real-life приложения и все становилось уже не так радужно как до этого. Хочется пожелать вам успехов в этом нелегком деле и, конечно, попробовать что-нибудь готовое на ощупь :)
  • 0
    Если именно об этом демо:
    1)то была неправильно сделана анимация при свайпе, с аналога адаптервью на андроиде(установка онлайн стилей для каждого элемента), перешли на аналог hamer.js — двигаем рут, а чаилдам просто меняем место по окончании анимации.
    2) на некоторых андроидах был баг транзишен с лефтом — вызывалась «доводка» после анимации с translate3D — просто translate3D выполнялся сразу так как эта анимация юзает графический ускоритель, а лефт потом. При этом на iOs хватало быстродействия а на андроиде нет.
  • 0
    В «заманухе» есть логотип BlackBerry. В статье нет ни одного упоминания об этой платформе. Даже в комментах нет.
    Просто констатирую факт.
  • +1
    Занятно, что статьи про PhoneGap и его success stories как правило рассматривают его с перспективы iOS.

    Вообще пока что ситуация выглядит примерно так:
    1. приложение на PhoneGap будет тормозить. Просто by design. Вопрос только — насколько сильно.
    2. Как только появляется более-менее развесистый DOM и/или JS для визуальных эффектов (здравствуй Sencha Touch) — начинаются тормоза

    От того, насколько тормозной будет интерфейс зависит в принципе успех приложения. Более-менее шустрый GUI создать на PG можно, если
    1) использовать минималистичную верстку
    2) делать анимацию только на CSS (ибо ускоряется на GPU)
    3) использовать минимальный набор фреймворков и библиотек (если можете написать сами — пишите сами)
    4) следить за чисткой неиспользованных фрагментов DOM

    И похоже что идеального UI HTML5 фреймворка в этом смысле нет.
  • 0
    Странно что в таких топиках нет ни слова о MoSync — www.mosync.com/

    Для кроссплатформенной разработки это наилучший выбор. Тем более если хочется быстрых приложений без проблем с производительностью.
    • 0
      А не подскажете, в чем отличие MoSync Reload от SDK?
  • 0
    Просто оставлю здесь занимательный факт, что игра из под Construct2 под PhoneGap безбожно лагает но при этом тот же дистрибутив скомпилированный под CocoonJs летает на ура
  • 0
    Нам нужно было выбрать способ разработки мобильных приложений для существующего веб-сервиса.

    Решения с HTML5 + WebView отпали сразу же, ибо они все же подтормаживают.
    Выбор был между Xamarin и Appcelerator Titanium.

    Принимая во внимание, что javascript у нас сейчас используется для Web UI, я подумал, что даже хорошо знакомый C# в нашем случае не так хорош для мобильных приложений. Кроме этого, конечно нужно иметь ввиду, что лицензия на Xamarin, стоит тысячу долларов на каждого разработчика и каждую платформу.
    Да, там есть свои плюсы, так как используется «родная» Visual Studio, но дорого, когда есть бесплатное решение и тоже со своими плюсами помимо бесплатности.

    А mac придется покупать в любом случае((

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

Самое читаемое Разработка