Компания
32,95
рейтинг
29 июля 2013 в 14:12

Разработка → PhoneGap: как сделать приложение отзывчивым tutorial

На сегодняшний день существует немалое количество обзорных статей о PhoneGap, но к сожалению, написаны они или front-end разработчиками, которые решили заняться мобильными платформами, или нативными программистами, которые решили попробовать себя в кроссплатформенной разработке. И именно с этих позиций рассматриваются достоинства и недостатки PhoneGap'а, возникают статьи о том, «насколько крута кроссплатформа», или об «ущербности кроссплатформенных решений».

В качестве затравки — видео демо-приложения, написанного за 6 часов; готовым был взят UI-бутстрап, наверстанный за 3,5 часа; использовались библиотеки iScroll, backbone, underscore, Jquery, и небольшая обертка на backbone (RAD.js — rapid application development, архитектурный фреймворк, берущий на себя часть оптимизации, связанной с мобильной средой выполнения).


Еще 2 часа было потрачено на фикс движка. Но сегодня речь не о том, что что-то тормозит, дергается, или самописный свайп не всегда вовремя отрабатывает на 14000 объектах данных; речь о том, что на PhoneGap можно и нужно писать.

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

PhoneGap позиционируется как платформа для кроссплатформенной разработки на HTML/JavaScript под семь мобильных операционных платформ.

Кроссплатформенность в PhoneGap достигается тем, что код Вашего HTML/JavaScript-приложения выполняется в компоненте webView (представляющего собой, встроенный в приложение браузер).

Фактически разработка PhoneGap-приложения представляет собой разработку HTML5-приложения с учетом особенностей среды выполнения (мобильное устройство, ограниченная процессорная мощность, память, тачскрин и т.д.) и… зоопарка браузеров.
Точно так, как при разработке под десктопные браузеры, при разработке мобильных сайтов или PhoneGap-приложений Вам необходимо знать и учитывать специфику каждой операционной системы и ее дефолтного браузера, на базе которого построен компонент webView.

И главное, на что влияет ограниченность мобильной среды выполнения PhoneGap-приложения и ресурсов, — это отзывчивость пользовательского интерфейса.

Для рядового пользователя не страшно, если на время выполнения каких-либо длительных операций программа заблокирует интерфейс, показав, к примеру, диалог с прогрессом выполнения задачи. Намного хуже, если пользователь подсознательно испытает дискомфорт, когда при нажатии кнопка отреагирует не сразу. Речь в данном случае идет даже не о секундах; человеку для ощущения подсознательного дискомфорта достаточно задержки более 150 миллисекунд между нажатием и реакцией программы. В этом случае наше подсознание просигнализирует о том, что интерфейс программы реагирует не так, как мы ожидаем.

Поэтому мы в своих программах пытаемся акцентировать внимание на отзывчивости пользовательского интерфейса. И в данный статье не будем говорить об оптимизации JavaScript-кода или CSS, так как это не специфично для PhoneGap и мобильных приложений, и, кроме этого, об этом уже немало написано(тут, тут, тут или тут).

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

Статьи, которые комплексно рассматривают взаимосвязь интерфейса и отзывчивости мобильного веб-приложения, найти непросто. Для примера можно привести эту статью, или же эту. Вторая статья достаточно свежая, и указывает направление «движения» для создания хорошего приложения на PhoneGap, но автор в ряде случаев использует «canvas based UI», что не всегда возможно).
Но и в этих статьях, к сожалению, рассмотрены не все проблемы.

Выделим проблемы, которые мы считаем характерными, и которые хотели бы рассмотреть сегодня:

  • Задержка в 300 миллисекунд события «click» на «тач»-устройствах;
  • Проблема касания
  • Оптимизация DOM-структуры;
  • Проблема больших списков.


Возможно в чем-то мы повторимся, но всеже начнем.

Проблема задержки в 300 мсек:

Большинство мобильных операционных систем в своем браузере (и как следствие, в webView) для решения проблемы ложных касаний вводят специальную задержку около 300 миллисекунд между непосредственным нажатием и запуском события «click» в DOM'e.

Подход к решению этой проблемы нетрудно найти на просторах интернета. Существует как минимум несколько десятков JavaScript-библиотек, решающих эту проблему. Принцип действия всех их одинаков — отслеживать события «touchstart» и «touchend» — и в момент окончания последнего вызывать событие «click» или аналогичное кастомное (например, «tap»). Примеры можно найти и как решение на stackoverflow, и как плагин к JQuery, и как отдельную библиотеку, причем даже в реализации от Mozilla или просто в качестве советов.

К сожалению, всегда есть небольшое «но» — если генерировать событие «click» (например, как советует компания google в своем решении), то через некоторую задержку Вам придется отловить и прекратить распространение стандартного «click», сгенерированного самим браузером. Что в старых версиях android может привести к несовместимости со сторонними библиотеками. При этом, если генерировать кастомное событие, то фокус будут передаваться с задержкой, и эта задержка будет видна при выборе полей ввода.

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

И хотя, в этом случае Ваше приложение и становится зависимым от данной библиотеки, этот недостаток с лихвой перекрывается простотой решения и наименьшим количеством багов.
Следует также предостеречь Вас от привязки отдельных экземпляров «fastclick» на каждый элемент UI, так как делают некоторые библиотеки. Это решение, хоть и работоспособное, но крайне затратное с точки зрения потребления ресурсов мобильного устройства. Необходимо использовать делегирование и привязку, например, на «body» слушателя и генерацию всплывающего кастомного события по координатам нативного.

Вторая проблема — точка касания:

Еще одна часто встречающаяся проблема в неправильно спроектированных интерфейсах мобильных устройств (в том числе и на PhoneGap) звучит из уст пользователей так: «я нажимаю, а оно не всегда срабатывает» или «я нажимаю, а оно не работает».
Давайте внимательно рассмотрим следующий рисунок, отображающий, как именно происходит взаимодействие пальца пользователя с экраном устройства.

image

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

Именно по этим причинам, реальная точка касания никогда не совпадет с визуальной.

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

Исправляется этот момент достаточно просто — грамотной версткой элементов управления приложения; например, когда кнопка имеет невидимый падинг в 4-6 пикселей если она недостаточно большая по дизайну: то есть ее бэкграунд имеет невидимые внешние границы, которые увеличивают ее физический размер до необходимого и удобного пользователю (розовое поле на рисунке).

image

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

А теперь о самом нетривиальном — об оптимизации DOM-структуры

image

Если посмотреть на более-менее «стандартный» экран «среднего» приложения, то можно насчитать от 200-300 html тегов (узлов DOM), с помощью которых наверстан экран приложения. В данном конкретном примере страница наверстана с помощью 225 HTML-элементов. Далеко, не самая оптимальная верстка, но, как бы мы ни старались, в любом случае, в среднем экране PhoneGap-приложения можно насчитать от 100 до 250 элементов HTML. И попросим учесть, что мы пока не рассматриваем экраны со списками (об этом поговорим чуть-чуть позже).

Среднее приложение, аналогичное нативному, содержит от пяти до полутора десятков экранов. В случае PhoneGap, все эти старницы являются частью single-page приложения.

Существует общепринятый подход к архитектуре такого приложения: все страницы верстаются в одном html файле как блоки, а потом, в ходе выполнения программы, в зависимости от того, какая страница необходима, стилями
display: none;
display: block;

отображается нужная страница (так, например, делается в JqueryMobile ).

Но этот подход, к сожалению, приводит к задержкам в приложении при переключении страниц(и не только). И чем сложнее приложение, тем длительнее эти задержки.

Связано это с тем, что даже для самой обычной JavaScript-функции запроса к DOM, например, document.querySelector('selector'), время выполнения зависит от количества узлов в объектной модели документа. К примеру, указанная операция при трехуровневом селекторе выполняется за 0.003 мсек при 100 элементах и 0.36 мсек при 10000 элементах (ориентировочно 40 страниц приложения). Можно возразить, что это мелочи: 40 страниц не часто встречаются в реальной жизни, да и 0.36 мсек — копейки.

Но чистым JavaScript никто никогда практически не пользуется, а при использовании JQuery(до 2 версии) указанное время вырастает до 2.46 мс. А если учитывать, что кроме простого запроса необходимо также провести какие-либо манипуляции с DOM, то это уже может привести к заметным даже на глаз задержкам в достаточно сложном приложении.

Приведем небольшой СИНТЕТИЧЕСКИЙ тест, генерирующий документ с различным количеством элементов, и выводящий результат выборки двухуровнего CSS в консоль.

Результат его выполнения на Chrome 28.0.1500.63
start create 1 items index.js:12
none 1 items: 0.078ms index.js:38
none jquery 1 items: 0.774ms index.js:43
block 1 items: 0.131ms index.js:38
block jquery 1 items: 0.234ms index.js:43
jquery show1 items: 1.768ms index.js:52
start create 10 items index.js:12
none 10 items: 0.071ms index.js:38
none jquery 10 items: 0.138ms index.js:43
block 10 items: 0.139ms index.js:38
block jquery 10 items: 0.090ms index.js:43
jquery show10 items: 0.865ms index.js:52
start create 100 items index.js:12
none 100 items: 0.071ms index.js:38
none jquery 100 items: 0.099ms index.js:43
block 100 items: 0.103ms index.js:38
block jquery 100 items: 0.105ms index.js:43
jquery show100 items: 1.418ms index.js:52
start create 1000 items index.js:12
none 1000 items: 0.178ms index.js:38
none jquery 1000 items: 0.163ms index.js:43
block 1000 items: 0.156ms index.js:38
block jquery 1000 items: 0.176ms index.js:43
jquery show1000 items: 9.709ms index.js:52
start create 10000 items index.js:12
none 10000 items: 2.333ms index.js:38
none jquery 10000 items: 2.434ms index.js:43
block 10000 items: 1.810ms index.js:38
block jquery 10000 items: 1.810ms index.js:43
jquery show10000 items: 106.425ms

Как видно из теста, решение с «display: none» не помогает, так как это убирает работу только по отрисовке документа, но не меняет времени при запросах к «избыточному» DOM.
Это решение помогает нам избавиться только от reflow и repaint, поведение браузера при этих событиях великолепно рассмотрено в статье.

Еще раз напоминаем, что тест синтетический, не соответствующий реальным условиям, и некоторые позиции были специально «завалены». Но он прекрасно дает представление, что может произойти в реальном проекте с single-page приложением при большом количестве страниц и сложной верстке.

И хотя, время будет различаться на различных платформах (в различных браузерах), нетрудно увидить, что в мобильных браузерах ситуация будет еще хуже — в сложных одностраничных приложениях со стандартным подходом вы вряд ли получите плавную анимацию на мобильном устройстве.

В этом случае есть два варианта решения:

  • Грузить содержимое страниц ajax-запросами;
  • Если страница уже наверстана стандартным подходом, после ее загрузки в DOM нужно отсоединить ветви DOM, отвечающие за невидимые страницы от основного дерева DOM, сохранив ссылки на эти ветви в JavaScript (например с помощью api.jquery.com/detach), в этом случае GC не очистит отсоединенные ветви.

image

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

Не следует также забывать и об известных местах оптимизации.

И снова о DOM — проблема больших списков

Проблема больших списков является частью проблемы описанной в предыдущем разделе.
Чем больше элементов списка вы имеете, тем больше элементов HTML будет в странице, и тем медленнее будет происходить обновление и отрисовка списка.

В нативных компонентах это реализовано через кэш (пример реализации нативного компонента на Android).

image

Проблему можно решить или заменой данных в уже скрытом элементе и также перестановкой его позиции или удалением скрытого элемента списка и генерации нового. То есть, фактически на экране существует не список из 1000 элементов, а список из 10 видимых на экране элементов, и возможно несколько скрытых элементов, с которыми в данный момент происходит работа.

В веб-приложениях такую реализацию списков практически невозможно увидеть; как правило, все делается максимально просто: список из 1000 элементов. И если на десктопе это не настолько критично, то на мобильных платформах большие списки могут сыграть решающую роль в отказе от PhoneGap как платформы разработки.

В качестве решения данной проблемы можно порекомендовать «пейджинацию», то есть отображение списка по частям. Данное архитектурное решение реализуют множество js-библиотек; его можно очень красиво обыграть — например, свайпом.

image

Или же можно написать или найти JavaScript-библиотеку, реализующую функциональность аналогичную нативным компонентам; например, как сделано в InfiniteWall или здесь.

Напоследок хотелось бы дать несколько полезных советов, которые, как мы надеемся, помогут Вам сэкономить время и нервы:

  1. Чем меньше сторонних библиотек Вы используете, тем лучше, связано это с ограниченными ресурсами мобильного устройства. Для сравнения могу привести эскадру из «звездолетов» — сторонних библиотек. Вы хотите, чтобы эта эскадра перевезла один-единственный «груз» — выполнила бизнес-кейс Вашего приложения. Но топливо будет потреблять вся эскадра. Поэтому экономьте ресурсы (Ваше «топливо»), выбирайте библиотеки наиболее оптимально и пытайтесь наиболее полно использовать их возможности. К примеру, JQuery, начиная с версии 2, не на много уступает в производительности zepto, а функциональности намного больше.
  2. Ваше приложение совсем не обязательно должно выглядеть одинаково на всех платформах и версиях ОС. Возможно, стоит пойти на некоторые уступки в стилях и оформлении, чтобы сохранить быстродействие и функциональность программы. Вспомните ситуацию с IE;
  3. В списках не используйте атрибут «src» для тегов img, используйте CSS background для вывода изображения; в этом случае изображение будет подгружено только в том случае, если элемент списка виден на экране;
  4. Не всегда методы оптимизации, работающие в случае веб-страниц с клиент-серверной архитектурой, важны и оптимальны для приложения на PhoneGap. Например, нет смысла обращать внимание на на размер загружаемого JavaScript-файла или на минимизацию невидимых пикселей в изображении, так как в нашем случае нет долгих сетевых запросов для загрузки этих файлов. К сожалению, задержку в 250 миллисекунд перед загрузкой каждого файла никто не отменял, и Вам решать, как с этим бороться. Мы для себя выбрали ленивую предзагрузку и тайлы;
  5. Располагайте поля ввода в верхней части экрана — это позволит избежать различного поведения верстки страницы при отображении клавиатуры на мобильных устройствах;
  6. Избегайте больших списков — это сложная задача; беритесь за нее, когда у Вас уже есть хотя бы наметки для ее решения;
  7. Избавляйтесь по максимуму от теней, градиентов и полупрозрачности. Вся эта красота требует дополнительной мощности от мобильного устройства, поэтому используйте это только там, где действительно необходимо;
  8. Используйте мощность графического процессора через CSS, например так:
    transform: translate3d(0,0,0);
    -webkit-transform: translate3d(0,0,0);

    В частности, можно почитать о конкретной реализации.
    Или более подробно с тестами.


И еще несколько ссылок на статьи с советами: тут, тут или тут.

Но самое главное, что мы хотим сказать: На PhoneGap'e можно писать.

Хотя он не является панацеей для разработки. Каждый инструмент предназначен для своих задач. С помощью PhoneGap можно написать отзывчивое приложение и/или приложение с нестандартным дизайном (причем это даже легче сделать, чем при реализации нативным кодом). Но если Вам нужна обработка больших объемов данных, то скорее всего, PhoneGap Вам не подойдет, хотя иногда и с этим можно бороться.

Надеемся наши советы пригодятся.

P.S. Спустя 11 часов оптимизации UI баги остались, с теми же размерами кнопок, но приложению реально «полегчало».
Автор: @YuriyLuchaninov
MobiDev
рейтинг 32,95
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

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

  • +2
    Отличная статья.
    Сами сталкивались с кучей узких мест по производительности и отрисовке. Очень страдали от инпутов в контенте и свайпа меню — в результате отказались от андроидов 2.3.

    1) Смотрели ли вы в сторону Angularjs вместо Backbone?
    Сам тяготел к backbone, пока не заставили посмотреть 12-минутное видео (http://www.youtube.com/watch?v=WuiHuZq_cg4) про построение To-Do листа на ангуляре. Сразу для меня померкли мульки MVC от бэкбона.

    2) Почему RAD.js? Пробовали вместо него взять marionettejs для бэкбона?
    • 0
      Честно говоря даже не знаю как ответить коротко, просто ответы на данные два вопроса тянут на серию статей.

      Постараюсь коротко:
      1) Да смотрели, даже пытались реализовать свои расширения в виде сервисов, но столкнулись с тем что есть вещи которые невозможно исправить, например:
      — высокий уровень входа во фреймверк, что иногда критично для быстрого старта «джуну»
      — DI в angular — это фактически singleton(управление экземпляром не прозрачно)
      — скоуп полностью перерендеривается при новом отображении скрытого DOM
      — заточенность под CRUD приложения

      Мне лично angular крайне импонирует, но он не является оптимально «заточенным». К примеру, сами создатели angularjs на вопрос «почему они не занимаются оптимизацией производительности?», ответили: у нас фреймворк работает достаточно быстро чтобы выдавать те самые 60 fps.

      Кроме этого у angular и backbone немного разные уровни абстракции и реализации, то есть того за что отвечает фреймворк. Нам нужен был наиболее гибкий MV*(и только это) фреймворк, имеющий наибольшее комьюнити.

      Хотя на ангуляре вполне можно написать PhoneGap приложение.

      2) пробовали и marionettejs и chaplinjs (холивар устраивать не будем с создателями знакомы лично). Просто RAD.js это свое, «заточенное» под решение проблем описанных в данной статье. Легковестное ~10К, 2,2К строк кода. В данный момент переводится документация и будет выложена как opensource на github с примерами. Но это как я говорил ранее тема отдельной статьи и надеюсь в скором времени.

      Еще раз — это не повод для холивара между фреймворками ;)
    • +2
      спасибо за видео, весьма показательный пример ангулар ин экшн!..
      • 0
        Backbone же
        • +1
          вообще-то я благодарил первого комментатора (nod), а не автора статьи.
          а в первом комментарии — как раз «12-минутное видео» про применение ангулара.
          (прежде чем бездумно минусовать, — внимательно посмотрите на дерево комментариев, что-ли..)
  • 0
    На видео видно, что вы активно пользуетесь титаниумом.
    Отказываться от титаниума в пользу фонгап собираетесь?
    • +1
      Если не секрет, а где это видно ;)
      Видно не доглядели.

      У нас действительно есть тима которая занимается титатниумом, но отказываться ни от одной платформы мы не собираемся. Дело в том что хотя и фонгап и титаниум являются кросплатформеными, они по разному реализуют данный подход. И инструмент(титаниум, фонгап, ксамарин или тот же Cocoon (его, честно говоря даже не трогали — играми практически не занимаемся) ) для кроссплатформенной разработки у нас выбирается непосредственно под конкретную задачу, в зависимости от требований.

      Каждый инструмент предназначен для своих задач

      А в этой статье мы пытались расказать о PhoneGap
  • +2
    Вот что у нас получилось на фонгапе:
    play.google.com/store/apps/details?id=kz.ps.app
    Логин: demo
    Пасс: demo
    • +1
      симпатично, но есть мелкие баги: меню иногда залипает, если его потягать вниз, а список рефрешится (мб фича), скролл в списке подмораживает когда листаешь до самого низа, реакция на хардварый back странная — гоняет по кругу. тел. xperia U
  • +5
    Голоса на фоне радуют: «Кто взял третий айпад?» — «Да я на две минуты!» — «Подожди, видишь, ему видео нужно записать!»
    • +2
      Прошу прощения, просто видео снималось «на коленке» «по-быстренькому», поэтому честно не сообразил
  • 0
    Отличная статья, с подбором ссылок, добавил в избранное!
  • 0
    Очень хотелось бы увидеть приложения сделанные на PhoneGap, если знаете такие, покидайте ссылки в комментарии. За материал отдельное спасибо, достойный!
    • 0
      • 0
        Благодарю, недоглядел.
    • +1
      У нас с коллегой в августе в Одессе доклады. До этого события на appStore и GooglePlay будут размещены по два приложения на PhoneGap(с разными бизнес кейсами), что бы можно было оценить отзывчивость и быстродействие.

      К сожалению, в данный момент основной поток PhoneGap у нас попадает под NDA( non-disclosure agreement), в связи с чем мы не можем «пиарить» ссылки на маркет. Но думаю мы с Вами сможем дождаться 22 августа, обзорная статья с конкретными трудностями гарантируется.
  • 0
    Когда делал игру, понял 2 вещи Cocoon быстрее PhoneGap и чтобы адекватно делать касания надо при касании экрана создавать прозрачный спрайт небольшого размера и уже основываясь на коллизии с другими спрайтами (эл-тами инт-са) работать.
    • 0
      Не всегда есть смысл использовать кокон :(
  • 0
    Еще подход, который используют в некоторых пролиожениях — использовать вебкитовскую обертку вместо Фонгапа и проксировать только те нативные API, которые вашему приложению нужны.

    Ну и статья от ЛинкдИна по теме длинных списков: engineering.linkedin.com/linkedin-ipad-5-techniques-smooth-infinite-scrolling-html5 Ничего суперграндиозного, просто описывают, как можно поэтапно упрощать структуру DOM, оставляя интерфейс отзывчивым.
    • 0
      использовать вебкитовскую обертку вместо Фонгапа

      А есть ссылка на подробности?
  • +1
    Благодарю за статью. Особенно за очередную попытку сказать, что тормозит не phonegap а javasscript исходники программистов.

    Для нативного приложения народ не очень комплексует по поводу убирания невидимых элементов списка (при торможении). Когда подобное нужно сделать в phonegap — то с начала услышим маты по поводу ущербности фонгапа, а лишь потом пойдут оптимизации. Таких примеров можно привести огромное количество.

    Однажды показали пример 22 страничного приложения, которое «тормозило». После 3х дествий оно начало летать (1 не пихаем в дом не нужное, 2 при создании кэшируем ссылки на обьекты а не $('#aaa'), 3 используем css анимации вместо аналогичных скриптовых ). Эти изменения даже нельзя назвать оптимизацией — всего лишь кусок здравого смысла.

    — P.S. Большое кол-во проблем решаются автоматически, если использовать google closure library + closure compiler advanced optimization.
  • 0
    Еще плюс что для phonegap можно почти без боли писать плагины и пробрасывать из objc‎ почти всё что угодно, и огромный минус что ios отключает JIT оптимизацию для внешних webview:

    хотя это уже больше относится к бизнес логике чем к отрисовке.
  • 0
    Торт!

    Однозначное и огромное спасибо. Именно из-за незнания этих нюансов сложилось негативное мнение о мобильных HTML5-приложениях. Возродили мою веру в свои заброшенные поделки!
  • +1
    Я дилетант в этом вопросе, но был опыт использования Sencha Touch и jQuery Mobile. Как пользователя гуглофона меня производительность Sencha Touch вполне устроила, и я довольный начал на ней писать приложение. А потом решил для сравнения потыкаться в нативных приложениях на iPad, и счастье моё быстро улетучилось. Все те микроскопические задержки при листании и свайпе, косяки с распознаванием жестов (на том же видео видно, что свайп срабатывает не всегда, и порой нужно хорошенько провести пальцем по экрану, чтобы он сработал), легкие подтормаживания при анимации, всё это очень портит картину, если брать во внимание плавность работы приложений на iOS. Как компромисс между необходимостью выпуска на нескольких платформах и временем разработки такое решение вполне может сгодиться. Но если для заказчика (или вас самих, если вы сам себе заказчик) критична плавность работы интерфейса («чтобы было как на айфоне!»), то увы и ах, тут ни phone gap, ни кучи фреймворков для создания мобильных веб-приложений помочь не в силе, на мой взгляд.
    • +1
      Просто посмотрите ответ или попросите сделать нативно на андроиде следующее.

      А по указанным Вам фреймверкам:
      jQuery Mobile — недостатки обсуждались в статье.
      Sencha Touch — отдельный разговор, слишком огромный фреймворк, чтобы вэб-разработчик, который его только начал использовать(менее 9 месяцев) — смог «выжать» из него максимум. Кроме этого сами Sencha — не скрывают, что их фреймворк начал «шустро» работать только на androide 4.2(движок V8, до этого был V6 в webView)

      А по-поводу замечаний, мы совершенно с ними согласны:
      Но сегодня речь не о том, что что-то тормозит, дергается, или самописный свайп не всегда вовремя отрабатывает на 14000 объектах данных; речь о том, что на PhoneGap можно и нужно писать.

      • 0
        С phoneGap, как с php, мне кажется ситуация… Из-за низкого порога вхождения тонны прог, обвешанных фреймфорками с безбожными тормозами и программисты не понимающие что и как надо делать под конкретные задачи.
        Попробовал пописать на phonegap, очень понравилось, всё легко, просто и привычно, тем более что обычно мне нужен софт на уровне: выдернуть ajax-ом данные, показать и отправить на сервер что выбрал юзер. Скоро буду писать первое серьезное приложение, посмотрим что выйдет без лишних фреймворков.
        Фреймфорки не люблю использовать и люблю одновременно: с одной стороны почти всегда это излишня трата ресурсов, а с другой удобный и быстрый способ склепать приложение, не думая о костылях и нюансах.
        зы: еще и hp pre3 прикупил, где всё на web, довольно интересно — любую установленную прогу можно прям из консоли править без пересборок. В целом очень понравиля и девайс (взял с аксессуарами вроде беспроводной зарядки) и операционка и synergy в частности, не понимаю как эта ось не взлетела.
      • 0
        К сожалению, по поводу времени разработки:
        Как компромисс между необходимостью выпуска на нескольких платформах и временем разработки такое решение вполне может сгодиться

        вы совершенно правы — разработка кроссплатформенного приложения и оптимизация его UI под одну платформу: всегда будет дольше чем нативного(если мы не говорим о нестандартных элементах UI).
        Но… это время, как правило будет меньше чем суммарное для разработки под две или более платформы, и уж тем более если требуется нестандартный пользовательский интерфейс.
      • +1
        проверил этот Fastbook на одно-ядерном Андроиде 4.1, конечно о плавности сравнимой с native говорить не стоит, но в некоторых местах есть преимущества, например фото показывается быстро и не тормозит, при переключении по менюшкам всегда возвращаешься на место, где закончил, но то что адрес-бар не убирается это печально :)
      • 0
        Я всё же не могу понять, почему же на нем нужно писать, если интерфейс получается недостаточно отзывчивым? :) Я ни в коем случае не против phoneGap или веб-приложений, нет. Это отличный выход при отсутствии ресурсов для разработки приложений под разные платформы. Но тормоза, на мой взгляд, и есть основная причина, по которой нельзя использовать это решение повсеместно.
        • +1
          Все говорят о тормозах, а я их не вижу… Вот видео выше даже есть, 2 штуки, всё точно так же, как и с нативными приложениями, которые точно на тех же местах могут тормознуть (большой список без оптимизации, мало памяти, слабый проц, данные не ассинхронно принимаются и т.д.). Реальный тормоз всего один — 300мс, если использовать событие onclick, если использовать более логичное touch событие, то проблем не возникает. Плюсов море (если не рассматривать специфичные приложения вроде 3д игр или еще чего, требующего сложные алгоритмы), один из которых — если у вас в команде есть JS разработчик и веб дизайнер, то скорее всего вы сможете без лишних вложений сделать приложение.

          Простой пример: вы веб студия, вам заказали сайт отеля с бронированием и при этом заказчик захотел еще и приложение для iOS, Android и например Blackberry. Есть 2 пути: найти 3 разные команды, которые напишут приложение под каждую из осей или посидеть пару лишних дней с дизайнером и наваять точно такое же приложение на phoneGap под кучу платформ сразу (заодно не тратя время на обсуждения с третьими лицами веб-проект). Да, сперва может не получится идеально, но в будущем без головной боли и траты денег у вас будет не просто Web команда, но и еще и команда по разработке мобильных приложений (phoneGap еще и под Win8 собирает кстати) почти под все платформы в одном лице.

          phoneGap конечно же не панацея, но очень часто с ним можно сделать проще и быстрее (может у вас уже готова JS логика и надо только шкурку натянуть и собрать).
          • 0
            Тормоза наиболее заметны если сравнивать с работой нативных приложений на iOS. На Андроиде-то и нативные тормозят, это точно. Но что касается яблочной продукции, то тут уж извините, разница на лицо. Но для этого нужно не видео смотреть, а трогать. Если судить объективно, а не пытаться оправдать небольшие тормоза, то сразу станет понятно, в чём различие. Да, я придираюсь, но именно от таких мелочей зависит то, какие ощущения будет вызывать ваше приложение у пользователей. У меня самого гуглофон, но когда я беру в руки айфон, мне кажется, будто он реагирует на мои команды сразу после того, как я об этом подумал, ещё до того, как я коснулся дисплея. А всё потому, что мозг привыкает к этим надоедливым лагам на андроидо-девайсах, и начинает работать как бы позади. Точно так же и с веб-приложениями.

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

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

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