Comments 50
iOS/Android/WP — не получиться сделать универсально и удобно, для каждой из ОС приходиться допиливать UI, тем самым теряя смысл кроссплатформенного приложения.
Я уже молчу о том, что в Android WebView не настолько хороший, что бы на нем делать красивое и быстрое UI, ну и скорость довольно сильно уступает нативному.
А в итоге получаем проблем больше (с одним только JS), чем если вести разработку на нативной платформе.
Я уже молчу о том, что в Android WebView не настолько хороший, что бы на нем делать красивое и быстрое UI, ну и скорость довольно сильно уступает нативному.
А в итоге получаем проблем больше (с одним только JS), чем если вести разработку на нативной платформе.
Действительно ли больше? Если не так важна производительность, то на весах оказываются две проблемы:
1) Учить Java & C# & Objective C и разрабатывать интерфейс для каждой платформы.
2) Просто переделать интерфейс для каждой платформы (везде используя HTML+JS).
И тут действительно есть что взвесить.
1) Учить Java & C# & Objective C и разрабатывать интерфейс для каждой платформы.
2) Просто переделать интерфейс для каждой платформы (везде используя HTML+JS).
И тут действительно есть что взвесить.
Я вам гарантирую, что с JS вы получаете проблем больше, чем с Java + Obj-C вместе взятые. Это касается более или менее функциональных приложений т.е. где много логики.
А кто спорит?
В статье были примеры применимости веб-фреймворков для создания приложений. Много ли функционала и логики в приложениях для таксопарка? Скорее всего нет. Вот для них JS — самое оно. А для функциональных приложений лучше Native SDK, никто и не спорит.
В статье были примеры применимости веб-фреймворков для создания приложений. Много ли функционала и логики в приложениях для таксопарка? Скорее всего нет. Вот для них JS — самое оно. А для функциональных приложений лучше Native SDK, никто и не спорит.
А если использовать TypeScript?
Это зависит исключительно от ровности рук и выбранных средств разработки. Я абсолютно согласен с Вами, если вы о jQuery-style.
Но
К примеру использую google closure library. Размер исходников десятки мегобайт.
Проблем с размером приложения итп не имею вообще. Контроль типов, пространства имён, автоматическое документирование, кодхинтинг в иде — всё это абсолютно так-же как и в Java + Obj-C.
В результате 95% кода отлично работают от вэба до андроида или иоса.
Но
К примеру использую google closure library. Размер исходников десятки мегобайт.
Проблем с размером приложения итп не имею вообще. Контроль типов, пространства имён, автоматическое документирование, кодхинтинг в иде — всё это абсолютно так-же как и в Java + Obj-C.
В результате 95% кода отлично работают от вэба до андроида или иоса.
Мдя, похоже, не получилось у Юры обьяснить нишу применимости HTML в мобильных приложениях.
Ну вот давайте на примерах. Вот два гибридных приложения:
Untappd — это пример успешного гибридного приложения для appstore которое сразу надо было нативным делать. Сейчас не видно, что оно не нативное, но сил на это, уверен, потрачено уже больше, чем сэкономлено.
Fly Delta — а это пример приложения которое имеет смысл делать в HTML, потому что функционально это интерфейс к вебсервисам компании Delta, и HTML/JS вполне справятся с такими задачами.
Нюансы здесь в том, что если бы Untappd выглядело криво, то даже при хорошей задумке быстро бы сделали более красивый аналог и все. А число пользователей Fly Delta зависит не от вылизанности программы, а насколько она полезна и юзабельна. Меню работает? Зачекиниться на рейс можно? Удобнее чем на сайт лезть с мобильника? Нотификации приходят? Все — что еще нужно? В данном случае скорость доступа к удаленным данным все равно не зависит от того на чем написано. Скорость работы JavaScript достаточна чтобы пришедшие данные показать. Ощущения от работы с приложением данного типа зависят больше от юзабилити, чем от того, какой код рисует UI и какими средствами.
Ну вот давайте на примерах. Вот два гибридных приложения:
Untappd — это пример успешного гибридного приложения для appstore которое сразу надо было нативным делать. Сейчас не видно, что оно не нативное, но сил на это, уверен, потрачено уже больше, чем сэкономлено.
Fly Delta — а это пример приложения которое имеет смысл делать в HTML, потому что функционально это интерфейс к вебсервисам компании Delta, и HTML/JS вполне справятся с такими задачами.
Нюансы здесь в том, что если бы Untappd выглядело криво, то даже при хорошей задумке быстро бы сделали более красивый аналог и все. А число пользователей Fly Delta зависит не от вылизанности программы, а насколько она полезна и юзабельна. Меню работает? Зачекиниться на рейс можно? Удобнее чем на сайт лезть с мобильника? Нотификации приходят? Все — что еще нужно? В данном случае скорость доступа к удаленным данным все равно не зависит от того на чем написано. Скорость работы JavaScript достаточна чтобы пришедшие данные показать. Ощущения от работы с приложением данного типа зависят больше от юзабилити, чем от того, какой код рисует UI и какими средствами.
От себя добавлю что PhoneGap не такой уж и быстрый. Если приложению не так важны какие-то функции, советую посмотреть на CocoonJS. Он и WebGL поддерживает (но плагины доступны премиум юзерам), есть webView. На android play достапны примеры скорости, и один пример у меня в профайле
Ну, если быть точным, то на 99% скорость обоих (PhoneGap и CocoonJS) зависит от скорости встроенного WebView контрола на каждой конкретно взятой платформе, они своих браузеров или JS engine не предоставляют. Нюансы могут быть в реализации «моста» между JS и нативным кодом, но это обычно не самые критичные имеено к скорости места.
Не совсем так, 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
Вот пример игр запечатаных на 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
Насколько я знаю, у какуна только ускоренный(прямой) вывод канваса. Этим он и отличается от кордовы
Очень ОЧЕНЬ спорная ссылка. Я например больше доверяю собственному опыту и http://caniuse.com/webgl а они утверждают что чистого WebGL нет ни на иосе ни на андроиде. Единственный вариант это если они имплементировали собственный вэбвью…
Прошедшие комментарии только подтверждают мысли против вчерашнего заминусованного перевода в этой статье
коммент к «9 признаков того, что не стоит нанимать этого Веб-разработчика»: — HTML5 довольно часто всё ещё спорно для разработки.
коммент к «9 признаков того, что не стоит нанимать этого Веб-разработчика»: — HTML5 довольно часто всё ещё спорно для разработки.
Как раз на днях была развернутая статья на тему «почему мобильные веб-приложения такие медленные».
Статья и обсуждение (англ.).
Статья и обсуждение (англ.).
Работаем над приложением для iPhone, используем технологии Sencha Touch/Cordova с небольшим числом нативных плагинов.
Скорость рендеринга на iPhone 4 слабоватенькая, то есть это выражается в небольшом притормаживании анимации переходов из одной карточки в другую, но в целом работает и пользоваться можно. На iPhone 4S/5 работает хорошо, вполне удобно пользоваться. Уже запущена и работает версия под iPad. Под Android — работает шустро на топовых устройствах aka Samsung Galaxy S4.
Из плюсов, которые я вижу в использовании Sencha Touch — это неплохие компоненты, биндинг.
Для себя решил работать в этом напрвалении.
Из других плюсов (имею ввиду использование HTML5 на моб устройствах) — это проще найти и переучить специалиста, до этого работающего с клиентскими технологиями.
Скорость рендеринга на iPhone 4 слабоватенькая, то есть это выражается в небольшом притормаживании анимации переходов из одной карточки в другую, но в целом работает и пользоваться можно. На iPhone 4S/5 работает хорошо, вполне удобно пользоваться. Уже запущена и работает версия под iPad. Под Android — работает шустро на топовых устройствах aka Samsung Galaxy S4.
Из плюсов, которые я вижу в использовании Sencha Touch — это неплохие компоненты, биндинг.
Для себя решил работать в этом напрвалении.
Из других плюсов (имею ввиду использование HTML5 на моб устройствах) — это проще найти и переучить специалиста, до этого работающего с клиентскими технологиями.
Jiayu G2, загрузил семпл workout, все списки тормозят очень сильно, да и любое изменение в UI. А ведь это приложения вообще практически логикой не обремененные, насколько я понимаю (код не смотрел, мало ли что там происходит о_О)
Сейчас еще на айфоне потестим…
Сейчас еще на айфоне потестим…
iPhone 4 немного шустрее, но все равно не юзабельно. Привыкший к плавности нативных приложений человек сразу снесет такого ужасного монстра)
Автор пытается подтвердить гипотезу о том, что существуют такие типы приложений, для которых желаемый результат можно получить с использованием HTML5, затратив при этом гораздо меньше ресурсов чем с использованием нативной разработки. Другими словами, типы приложений, для разработки которых HTML5 более эффективен. И здесь речь идет не о том, когда человек выбирает одно из десятка приложений опубликованных в аппсторе, и может безболезненно снести одно и поставить другое, а о том когда ему приходится выбирать между «объехать все точки в городе, записать на бумажку и вечером перенести все в базу данных вручную» и «воспользоваться мобильным приложением, которое местами притормаживает и провести 2 оставшихся вечером часа за кружечкой пива или в кругу семьи». Для меня выбор был бы очевиден. Минус здесь в том, что приложений подобного типа нет в списке демок продукта.
Я столкнулся со следующими проблемами HTML5 фреймворков: svg в андроидах 2, воспроизведение звуков, возможность создания экранов на время загрузки приложения, реакция на кнопки выхода из приложения.
всё что вы перечислили я делал в phonegap без каких либо проблем. другое дело что это работает медленнее чем нативные приложения…
Фактически пользователь пишет приложение, а фреймворк делает так, чтобы под каждой платформой оно смотрелось максимально нативно, в соответствии с требованиями платформы.
А есть какой-то фреймворк, который НЕ старается придать интерфейсу OS-нативный вид?
Если я хочу сделать простое приложение в нейтрально-минималистичном стиле. Мне только нужно, чтобы все работало, максимально надежно, быстро и совместимо.
Все зависит от того, что конкретно Вам нужно от фреймворка. Если нейтральный UI, можно посмотреть на twitter bootstrap или jQueryMobile, где можно воспользоваться конструктором тем. А так, конечно, все познается в сравнении :)
Я про другое. Фреймворк (обертка, интерфейс, не знаю как лучше назвать), который:
— даст движок с роутером урлов;
— даст доступ к железным функциям телефона (типа геолокации);
— позволит приложению работать в полноэкранном режиме на всех популярных мобильных ОС (ну как минимум iOS+Andriod, но желательно и прочие).
Но при этом чтобы он не влезал в вопросы отрисовки кнопок. Во-первых, 100% аутентичности все равно не достичь, а во-вторых, CSS-код я прекрасно умею писать сам.
— даст движок с роутером урлов;
— даст доступ к железным функциям телефона (типа геолокации);
— позволит приложению работать в полноэкранном режиме на всех популярных мобильных ОС (ну как минимум iOS+Andriod, но желательно и прочие).
Но при этом чтобы он не влезал в вопросы отрисовки кнопок. Во-первых, 100% аутентичности все равно не достичь, а во-вторых, CSS-код я прекрасно умею писать сам.
Для роутинга можно найти множество бесплатных JavaScript библиотек. API для геолокации доступно в большинстве современных браузеров. Если нужно больше, то можно воспользоваться PhoneGap API. Для упаковки в нативный контейнер, можно использовать PhoneGap build. Если не хочется самому реализовывать транзишны между вьюшками и другие аспекты SPA, то можно взять тот же PhoneJS, которому посвящена эта статья и отказаться от использование встроенных виджетов и лейаутов, сверстав UI самому, тем более если Вы это прекрасно умеете делать, а фреймворк позволяет. Разве что заплатить за виджеты все равно придется (если планируется коммерческое использование), т.к. они не поставляются отдельно.
Спасибо за ссылку на статью про эффект “Зловещей долины”, очнулся через минут 15 читая статью про «Плачущего мальчика».
Посмотрел демки PhoneJS на своем телефоне (недорогой андроидофон) — плане скорости все о-очень печально. Лаги такие, что в реальной жизни этим пользоваться невозможно. К большому сожалению.
Обладатели пятых Афонов и Геллакси S3/4 — хотя бы у вас нормально?
Обладатели пятых Афонов и Геллакси S3/4 — хотя бы у вас нормально?
Говорю как обладатель бюджетного андроид-девайса. На айфонах начиная с 4S и андроидах с хорошим железом все намного лучше.
Текущее, разрабатываемое нами HTML5-приложение (+Cordova), которое достаточно интенсивно использует Canvas + библиотеку Sencha Touch тестировалось на Prestigio. С производительностью явные проблемы. Так же тестировалось на Galaxy S4 — субъективно, производительность выше, чем на iphone 4s.
Текущее, разрабатываемое нами HTML5-приложение (+Cordova), которое достаточно интенсивно использует Canvas + библиотеку Sencha Touch тестировалось на Prestigio. С производительностью явные проблемы. Так же тестировалось на Galaxy S4 — субъективно, производительность выше, чем на iphone 4s.
Я там снизу линканул видео на фонгап демо, сенча не идеальна — она просто самая раскрученая.
Да, согласен. Просто они одни из первых начали интересоваться и делать что то.
Да, библиотека громоздкая — комопненты-обертки практически для всех мелких элементов. Это естесственно выливается в большие затраты в производительности. Но порог вхождения за счет такого подхода снижается.
То есть имеем и плюсы и минусы. Все нужно оптимизировать, чем мы переодически занимаемся.
Одна из оптимизаций — использование вместо списков Ext.dataview.List самописного компонента, реализующего самые простые фичи данного компонента — просто вывод списка кнопок и пару событий. И такими оптимизациями приходится заниматься.
Тем не менее, на выходе мы имеем в короткие сроки приложение для топовых айфонов и андроид устройств ну и потенциально для веба.
Да, библиотека громоздкая — комопненты-обертки практически для всех мелких элементов. Это естесственно выливается в большие затраты в производительности. Но порог вхождения за счет такого подхода снижается.
То есть имеем и плюсы и минусы. Все нужно оптимизировать, чем мы переодически занимаемся.
Одна из оптимизаций — использование вместо списков Ext.dataview.List самописного компонента, реализующего самые простые фичи данного компонента — просто вывод списка кнопок и пару событий. И такими оптимизациями приходится заниматься.
Тем не менее, на выходе мы имеем в короткие сроки приложение для топовых айфонов и андроид устройств ну и потенциально для веба.
UFO just landed and posted this here
Думал задать вопрос в Q&A и скорее всего там и задам, но какие «движки» html5 видит сообщество для разработки игр, мы сейчас рассматриваем альтернативы?
1) на андроиде нет WebWorkers, поэтому о каком их использовании может идти речь?
2) приведенная ссылка абсолютно не обясняет тонкостей и проблем мобильных приложений. «Масло масляное», поверте я когда перобретаю смартфон я догадываюсь что он будет медленее моего десктопа или ноута.
3)«Так мы берём на себя заботу об UI, а пользователь пишет UI-independent логику, которая на 99% не зависит от браузера.» извините, но это не самое необходимое. Как раз наоборот: более чем в 90% случаев — заказчик хочет нестандартный UI(поверьте, наша компания имеет опыт в разработке более чем 150 мобильных приложений, из них только 4 для собственного бренда), и что потом делать?
и т.д.
Просто на момент чтения данной статьи у меня на компе лежит статья как раз о тонкостях и проблемах PhoneGap, ждем реквизитов для оплаты корпоративного акка на хабре.
В качестве затравки видео на програму которая делает абсолютную хрень.
PhoneGap программа была написана за 6 часов и UI оптимизация 11 часов, в первом виджете отображается через слайд 14 000 объектов данных.
Хочу также обратить внимание на UI, его верстка не вошла во время разработки — просто парень сел и наваял кнопки и бары которые ему нравятся за 4 часа. Это по поводу «хочу кнопочки, но не такие»
Для того чтобы педалить фреймверки надо понимать зачем и какие проблемы они решают.
2) приведенная ссылка абсолютно не обясняет тонкостей и проблем мобильных приложений. «Масло масляное», поверте я когда перобретаю смартфон я догадываюсь что он будет медленее моего десктопа или ноута.
3)«Так мы берём на себя заботу об UI, а пользователь пишет UI-independent логику, которая на 99% не зависит от браузера.» извините, но это не самое необходимое. Как раз наоборот: более чем в 90% случаев — заказчик хочет нестандартный UI(поверьте, наша компания имеет опыт в разработке более чем 150 мобильных приложений, из них только 4 для собственного бренда), и что потом делать?
и т.д.
Просто на момент чтения данной статьи у меня на компе лежит статья как раз о тонкостях и проблемах PhoneGap, ждем реквизитов для оплаты корпоративного акка на хабре.
В качестве затравки видео на програму которая делает абсолютную хрень.
PhoneGap программа была написана за 6 часов и UI оптимизация 11 часов, в первом виджете отображается через слайд 14 000 объектов данных.
Хочу также обратить внимание на UI, его верстка не вошла во время разработки — просто парень сел и наваял кнопки и бары которые ему нравятся за 4 часа. Это по поводу «хочу кнопочки, но не такие»
Для того чтобы педалить фреймверки надо понимать зачем и какие проблемы они решают.
А в чем заключалась UI оптимизация? Хотя бы в общих чертах.
по пунктам:
1) речь может идти о об их использовании с фоллбэком (fallback, он же graceful degradation). Работает — хорошо, не работает — запустили в основном потоке выполнения
3а) это, очевидно, кастомно-красивые приложения. А PhoneJS ориентирован во многом на бизнес-составляющую
3б) ну и это — «берём заботу...» — это то, что предлагают, а не навязывают. Хочешь, бери. Не хочешь — не бери, пиши своё. Хочешь — бери только навигацию, а кнопочки верстай как душе угодно…
по демке:
хорошая штука получилась. Статью жду )
По перформансу:
на канве вот товарищ из твиттера показал 60 fps.
просто к слову пришлось )
1) речь может идти о об их использовании с фоллбэком (fallback, он же graceful degradation). Работает — хорошо, не работает — запустили в основном потоке выполнения
3а) это, очевидно, кастомно-красивые приложения. А PhoneJS ориентирован во многом на бизнес-составляющую
3б) ну и это — «берём заботу...» — это то, что предлагают, а не навязывают. Хочешь, бери. Не хочешь — не бери, пиши своё. Хочешь — бери только навигацию, а кнопочки верстай как душе угодно…
по демке:
хорошая штука получилась. Статью жду )
По перформансу:
на канве вот товарищ из твиттера показал 60 fps.
просто к слову пришлось )
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 в соответствии с требованиями, если это необходимо. Хоть с нуля можно наверстать.
В качестве затравки видео на програму которая делает абсолютную хрень.
Без комментариев.
Для того чтобы педалить фреймверки надо понимать зачем и какие проблемы они решают.
Вот с этим сложно не согласиться.
что глупо отказываться от использования какой-то фичи, только из-за того что ее не поддерживает какая-то часть целевых устройств.
Вы это называете частью?
Без комментариев.
причем не только в терминах быстрее/медленнее, но и в конкретных цифрах.
Порой мне кажется, что основное достижение команды разработчиков iOS очень часто остается без внимания рецензентов: факт того, что на всех iOS устройствах движение пальцев по экрану вызывает точно соответствующее им перемещение объектов. Не подмораживает, не вздрагивает, создается иллюзия, будто вы физически управляете объектом. Всякий раз когда я беру в руки новое устройство под управлением Android и пользуюсь им, я удивляюсь, обнаружив, что его интерфейс не так отзывчив, как на устройствах iOS. Jason Snell
Статья может и познавательная в цифрах, только вот пользователи выбирают программы не по цифрам а потому — нравятся им они или нет, и мне почему-то кажется что пользователь не будет пользоваться приложением которое ему не нравится. На рынке сейчас достаточная конкуренция, чтобы выбрать альтернативу.
Но даже этот факт не дает мне права утверждать, что все фреймворки, которые помогают нарисовать стандартный UI бесполезны.
А я это не утверждал — будьте внимательны. Я утверждал:
более чем в 90% случаевможно к примеру посмотреть скриншоты много там программ со стандартными кнопками? Возможно я и преувеличил, но все равно нестандартного больше половины. Прошу заметить, что и раньше и сейчас, речь не идет о стандартных UI патернах, а именно о стандартных элементах управления реализованных в указаном фреймверке.
позволяет откастомизировать UI в соответствии с требованиями
Не хочу вас расстраивать, но на мобильных браузерах это не всегда приемлемо использование css фреймверка для UI, мало того, как правило это идет во вред приложению. К примеру здесь предлагают отказаться от слайд анимации на андроиде, а у нас она летает даже на двойке. Это не потому что мы такие 'умные', а просто потому что мы понимаем как надо сделать чтобы конечному юзеру понравилось. А JQueryMobile посильнее будет PhoneJS.
Если Вам показались мои замечания не конструктивными, мне жаль — потому как я пытался объяснить, что из трех мной прочитанных статей об этом фреймверке, я не увидел ни одного преимущества перед уже существующими фреймверками.
И я не увидел
зачем и какие проблемы они решаютто что не делают другие фреймверки.
Хочу пригласить Вас в Одессу мы с коллегой прочитаем доклады именно по мобильной разработке: о PhoneGap, да и о том как влияет впечатление от программы на прибыль заказчика приложения.
Все же считаю что WebWorkers не заслуживают такого внимания, которое мы им здесь уделяем, думаю это вопрос времени, учитывая популярность, которую набирает Android. Ваши 90% я бы еще умножил на процент пересечения рынков вашей компании и целевого рынка PhoneJS, к сожалению сложно сказать насколько сильно они пересекаются. Эта информация была бы действительно ценной. Т.к. пока не понятно почему же эти 90% не хотят стандартный интерфейс и готовы платить за это (перекрасить кнопки в зеленый цвет — не считается). Ваш доклад с удовольствием бы послушал, спасибо за приглашение. Ну и если у вас действительно есть какие-то революционные наработки в области мобильной веб-разработки, ждем реализации PropertyCross.
В качестве затравки видео на программу которая делает абсолютную хрень.
Без комментариев.
К сожалению, вы не увидели главного —
программа была написана за 6 часови человек не использовал UI фреймверков
сел и наваял кнопки и бары которые ему нравятся за 4 часа
Просто взять и использовать UI фрейверк +MV* — не поможет написать программу на Phontgap — тут надо «понимать все сразу»
К сожалению, главное не это, главное когда будет написано конечное приложение в соответствии с требованиями и будет летать также как и спайк созданный на коленке за полчаса. По опыту было много случаев когда команда с горящими глазами после реализации такого спайка допиливала его до real-life приложения и все становилось уже не так радужно как до этого. Хочется пожелать вам успехов в этом нелегком деле и, конечно, попробовать что-нибудь готовое на ощупь :)
Если именно об этом демо:
1)то была неправильно сделана анимация при свайпе, с аналога адаптервью на андроиде(установка онлайн стилей для каждого элемента), перешли на аналог hamer.js — двигаем рут, а чаилдам просто меняем место по окончании анимации.
2) на некоторых андроидах был баг транзишен с лефтом — вызывалась «доводка» после анимации с translate3D — просто translate3D выполнялся сразу так как эта анимация юзает графический ускоритель, а лефт потом. При этом на iOs хватало быстродействия а на андроиде нет.
1)то была неправильно сделана анимация при свайпе, с аналога адаптервью на андроиде(установка онлайн стилей для каждого элемента), перешли на аналог hamer.js — двигаем рут, а чаилдам просто меняем место по окончании анимации.
2) на некоторых андроидах был баг транзишен с лефтом — вызывалась «доводка» после анимации с translate3D — просто translate3D выполнялся сразу так как эта анимация юзает графический ускоритель, а лефт потом. При этом на iOs хватало быстродействия а на андроиде нет.
UFO just landed and posted this here
Занятно, что статьи про PhoneGap и его success stories как правило рассматривают его с перспективы iOS.
Вообще пока что ситуация выглядит примерно так:
1. приложение на PhoneGap будет тормозить. Просто by design. Вопрос только — насколько сильно.
2. Как только появляется более-менее развесистый DOM и/или JS для визуальных эффектов (здравствуй Sencha Touch) — начинаются тормоза
От того, насколько тормозной будет интерфейс зависит в принципе успех приложения. Более-менее шустрый GUI создать на PG можно, если
1) использовать минималистичную верстку
2) делать анимацию только на CSS (ибо ускоряется на GPU)
3) использовать минимальный набор фреймворков и библиотек (если можете написать сами — пишите сами)
4) следить за чисткой неиспользованных фрагментов DOM
И похоже что идеального UI HTML5 фреймворка в этом смысле нет.
Вообще пока что ситуация выглядит примерно так:
1. приложение на PhoneGap будет тормозить. Просто by design. Вопрос только — насколько сильно.
2. Как только появляется более-менее развесистый DOM и/или JS для визуальных эффектов (здравствуй Sencha Touch) — начинаются тормоза
От того, насколько тормозной будет интерфейс зависит в принципе успех приложения. Более-менее шустрый GUI создать на PG можно, если
1) использовать минималистичную верстку
2) делать анимацию только на CSS (ибо ускоряется на GPU)
3) использовать минимальный набор фреймворков и библиотек (если можете написать сами — пишите сами)
4) следить за чисткой неиспользованных фрагментов DOM
И похоже что идеального UI HTML5 фреймворка в этом смысле нет.
Странно что в таких топиках нет ни слова о MoSync — www.mosync.com/
Для кроссплатформенной разработки это наилучший выбор. Тем более если хочется быстрых приложений без проблем с производительностью.
Для кроссплатформенной разработки это наилучший выбор. Тем более если хочется быстрых приложений без проблем с производительностью.
Просто оставлю здесь занимательный факт, что игра из под Construct2 под PhoneGap безбожно лагает но при этом тот же дистрибутив скомпилированный под CocoonJs летает на ура
Нам нужно было выбрать способ разработки мобильных приложений для существующего веб-сервиса.
Решения с HTML5 + WebView отпали сразу же, ибо они все же подтормаживают.
Выбор был между Xamarin и Appcelerator Titanium.
Принимая во внимание, что javascript у нас сейчас используется для Web UI, я подумал, что даже хорошо знакомый C# в нашем случае не так хорош для мобильных приложений. Кроме этого, конечно нужно иметь ввиду, что лицензия на Xamarin, стоит тысячу долларов на каждого разработчика и каждую платформу.
Да, там есть свои плюсы, так как используется «родная» Visual Studio, но дорого, когда есть бесплатное решение и тоже со своими плюсами помимо бесплатности.
А mac придется покупать в любом случае((
Решения с HTML5 + WebView отпали сразу же, ибо они все же подтормаживают.
Выбор был между Xamarin и Appcelerator Titanium.
Принимая во внимание, что javascript у нас сейчас используется для Web UI, я подумал, что даже хорошо знакомый C# в нашем случае не так хорош для мобильных приложений. Кроме этого, конечно нужно иметь ввиду, что лицензия на Xamarin, стоит тысячу долларов на каждого разработчика и каждую платформу.
Да, там есть свои плюсы, так как используется «родная» Visual Studio, но дорого, когда есть бесплатное решение и тоже со своими плюсами помимо бесплатности.
А mac придется покупать в любом случае((
Sign up to leave a comment.
HTML5 в мобильной разработке — что выбрать?