Pull to refresh

Comments 31

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

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

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

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

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

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

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

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

Еще раз — это не повод для холивара между фреймворками ;)
UFO just landed and posted this here
UFO just landed and posted this here
На видео видно, что вы активно пользуетесь титаниумом.
Отказываться от титаниума в пользу фонгап собираетесь?
Если не секрет, а где это видно ;)
Видно не доглядели.

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

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

А в этой статье мы пытались расказать о PhoneGap
симпатично, но есть мелкие баги: меню иногда залипает, если его потягать вниз, а список рефрешится (мб фича), скролл в списке подмораживает когда листаешь до самого низа, реакция на хардварый back странная — гоняет по кругу. тел. xperia U
Голоса на фоне радуют: «Кто взял третий айпад?» — «Да я на две минуты!» — «Подожди, видишь, ему видео нужно записать!»
Прошу прощения, просто видео снималось «на коленке» «по-быстренькому», поэтому честно не сообразил
Отличная статья, с подбором ссылок, добавил в избранное!
Очень хотелось бы увидеть приложения сделанные на PhoneGap, если знаете такие, покидайте ссылки в комментарии. За материал отдельное спасибо, достойный!
UFO just landed and posted this here
У нас с коллегой в августе в Одессе доклады. До этого события на appStore и GooglePlay будут размещены по два приложения на PhoneGap(с разными бизнес кейсами), что бы можно было оценить отзывчивость и быстродействие.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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