Comments 55
Почему вы ушли с phonegap? По опыту — работа на нем получается хуже, чем на Titanium?
Мы с него ушли довольно давно. Тогда на проекте мы собрали много глюков интерфейса, с большинством из которых сумели справиться. Проблемы были в основном от сырых библиотек, возможно, с ними сейчас получше. Главная причина, по которой ушли — это полностью нерабочее приложение на больших объемах данных. Т.е. пока тестировали — все было хорошо, как только попробовали загрузить реальные данные — приложение зависло.
Недавно видели чужое приложение на Phonegap, которое нам предложили доделать. Первая проблема, которая бросилась в глаза сродни проблемы дабл-кликов: по нажатию на кнопку в приложении, открывается новый экран и на нем срабатыает то же самое событие, если там тоже кнопка на этом месте — то вызывается обработка нажатия на нее, и так далее, как будто клик проходит сквозь экраны.
Главная проблема Phonegap, на мой взгляд, это снижение скорости реакции по сравнению с нативными приложениями. Если в нативном приложении вы хотите запустить камеру, или выполнить любую другую стандартную функцию операционной системы — вы просто делаете соответствующий вызов. И функция исполняется настолько быстро, насколько это позволяет устройство и операционная система. В phonegap вызов должен быть пропущен из веб-котента в Cordova, а оттуда попадет в систему, где и будет обработан нативными средствами.
Вполне допускаю, что подобные технологии могут заинтересовать тех, кто делает свое первое мобильное приложение, и еще не знает к чему стремиться, и как круто можно сделать натив. Может заинтересовать веб-разработчиков, которые хотят сделать какое-то несложное приложение. Но проблемы останутся те же, что и на многих кросплатформенных приложениях: вы связаны проблемами самой системы, вы все время ждете обновлений библиотеки, когда новая платформа уже на рынке, и ваши пользователи все время ждут. И каждый раз, когда у вашего приложения проблемы — будь то зависания, глюки, неспособность работать с большими данными или устаревший дизайн — вы теряете пользователей, имидж и, в конечном счете, деньги.
Недавно видели чужое приложение на Phonegap, которое нам предложили доделать. Первая проблема, которая бросилась в глаза сродни проблемы дабл-кликов: по нажатию на кнопку в приложении, открывается новый экран и на нем срабатыает то же самое событие, если там тоже кнопка на этом месте — то вызывается обработка нажатия на нее, и так далее, как будто клик проходит сквозь экраны.
Главная проблема Phonegap, на мой взгляд, это снижение скорости реакции по сравнению с нативными приложениями. Если в нативном приложении вы хотите запустить камеру, или выполнить любую другую стандартную функцию операционной системы — вы просто делаете соответствующий вызов. И функция исполняется настолько быстро, насколько это позволяет устройство и операционная система. В phonegap вызов должен быть пропущен из веб-котента в Cordova, а оттуда попадет в систему, где и будет обработан нативными средствами.
Вполне допускаю, что подобные технологии могут заинтересовать тех, кто делает свое первое мобильное приложение, и еще не знает к чему стремиться, и как круто можно сделать натив. Может заинтересовать веб-разработчиков, которые хотят сделать какое-то несложное приложение. Но проблемы останутся те же, что и на многих кросплатформенных приложениях: вы связаны проблемами самой системы, вы все время ждете обновлений библиотеки, когда новая платформа уже на рынке, и ваши пользователи все время ждут. И каждый раз, когда у вашего приложения проблемы — будь то зависания, глюки, неспособность работать с большими данными или устаревший дизайн — вы теряете пользователей, имидж и, в конечном счете, деньги.
проблема ghost-кликов довольно известна, и у этой проблемы есть масса решений. Одно из таких — использование нативных гестур. Ничего нету сложного в том, что бы пробрасывать все события, типа tap, double-tap, swipe, pinch и т.д. в webview и инициировать событие для js.
Об этом и речь: можно написать работающее приложение, если исправить проблемы, которые привносит кроссплатформенная разработка. У большинства из них есть решения, да, но какой смысл решать проблемы, когда можно провести время за более приятным занятием, например, реализуя удобную фичу для пользователей.
Решение добавить еще один уровень обработки событий только сильнее отдаляет пользователя от желаемого действия. На флагманах, конечно, это будет не очень заметно, а на остальных устройствах — пользователи останутся недовольны.
Решение добавить еще один уровень обработки событий только сильнее отдаляет пользователя от желаемого действия. На флагманах, конечно, это будет не очень заметно, а на остальных устройствах — пользователи останутся недовольны.
Решение добавить еще один уровень обработки событий
это не еще один уровень обработки событий, это вынос оного в нативный код. В этом случае в вашем приложении вы можете подписываться на события tap, swipe и т.д. и не нужно будет писать огромные обработчики touchstart/touchmove/touchend. Как результат, количество обработчиков событий снижается, количество вызовов этих обработчиков так же (что освободит для webview немного процессорного времени), генерация же ивента (найти элемент по координатам и инициировать событие) не создает такого уж большого оверхэда.
Вы в итоге остались на титаниуме, или еще куда-то перепрыгнули? Лично я, увидев такое количество реальных проблем, весьма недоумеваю, зачем было уходить с фонгапа. (комменты ниже читал). Сам разрабатываю на фонгапе, да, проблемы имеются, но их гораздо меньше, чем здесь описано у вас и все более-менее решаемые.
Про падения фонгапа с большими данными интересны конкретные примеры с цифрами.
Про падения фонгапа с большими данными интересны конкретные примеры с цифрами.
А пробовали xamarin? Мне просто интересно мнение людей которые пробовали писать на этих трех инструментах (phonegap, xamarin, titanium) кросс-платформенные приложения и к чему в результате они пришли.
xamarin все же не получится поставить в один ряд с phonegap и titanium.
Вы действительно правы: Xmarin — это порт платформы Mono на мобильные устройства, т.е. среда выполнения кода на С# и ее нельзя ставить в один ряд с Титаниум и Phonegap. У нас есть опыт работы с Ксамарин и мы обязательно поделимся, сейчас однозначно можем сказать, что есть довольно много сложнестей с тем, чтобы совместить MVC и MVVM Andriod и WinPhome 8 — т.е. по сути тот же if код получается.
По сути при создании xamarin авторы и не имели перед собой такой цели как унифицировать ui и избавить вас от необходимости писать if-код. На самом деле я считаю что такой подход оправдан, так как гайдлайны по ui и на одной и на другой платформе сильно различаются. Да, какие-то вещи дублируются, так что это довольно сложно реализовать ui одинаково для всех платформ.
>>чтобы совместить MVC и MVVM Andriod и WinPhome 8
Пробовали MvvmCross? С ним получается перенести практически всё кроме разметки и некоторых вещей. Вообще мне даже нравится что на xamarin нет возможности писать разметку одну на всех — вас как бы физически заставляют писать нативный UI.
Пробовали MvvmCross? С ним получается перенести практически всё кроме разметки и некоторых вещей. Вообще мне даже нравится что на xamarin нет возможности писать разметку одну на всех — вас как бы физически заставляют писать нативный UI.
Titanium не получится поставить в один ряд с phonegap.
Как раз в titanium и xamarin есть сходство. Там Node.ASC, а там Mono.
А phonegap это просто браузер с несколькими дополнительными функциями.
Как раз в titanium и xamarin есть сходство. Там Node.ASC, а там Mono.
А phonegap это просто браузер с несколькими дополнительными функциями.
Xamarin не стоит воспринимать как средство для создания переносимого кода (все что касается GUI не переносимо по умолчанию, а GUI это часто процентов так 50 кода). Скорее, это возможность писать под любую мобильную платформу на одном и том же C#, который знают очень многие. Со всеми нативными плюшками и быстродействием.
Если у вас GUI — 50% кода, то конечно, лучше делать нативно. В относительно среднем проекте, как я уже писал выше, мы добились того от 60 до 80% кода приложения на платформе общие с другими платформами. Детально разделение примерно следующее: 80% на wp7, так как весь GUI описывается в XAML и нет почти Behind-кода. 70% на Android, так как есть различные адаптеры, которые нужно писать из кода, но основная часть интерфейса все равно декларативная в AXML. И 60% у iOS, в основном из-за скудных возможностей InterfaceBuilder.
При мало-мальски сложной бизнес-логике и необходимости дальнейшего её развития, кросс-платформенный подход себя оправдывает. Xamarin оправдывает себя потому, что пользователи хотят видеть качественный, нативный интерфейс в стилистике платформы, и Xamarin позволяет это сделать.
При мало-мальски сложной бизнес-логике и необходимости дальнейшего её развития, кросс-платформенный подход себя оправдывает. Xamarin оправдывает себя потому, что пользователи хотят видеть качественный, нативный интерфейс в стилистике платформы, и Xamarin позволяет это сделать.
Не совсем понятно, что Вы имеете ввиду, говоря о «дабл-кликах». Нативные приложения не блокируют автоматически управляющие элементы. Потому что это нужно далеко не всегда. И именно разработчик должен это сделать, если такая необходимость есть.
Например, в iOS есть понятие MainThread, где происходит обработка событий от пользователя. Функция-обработчик события всегда вызывается в MainThread, и элемент, с которого получено событие, становится недоступным. Если в обработчике не написать переход в другой тред, то на время обработки интерфейс как бы подвисает, что правильно для коротких действий или например для открытия экрана. Если же требуется длительная обработка — загрузка данных и т.п., то кнопка блокируется вручную, и делается вызов обработки в другом треде.
Если, например, рассмотреть нативные таблицы, то часто реализуют открытие экрана с подробной информацией по клику на элемент списка. По умолчанию, т.е. без лишнего кода, после клика на один элемент списка, пользователь не сможет выбрать другой, пока событие не обработано, в том числе пока не открыт экран с подробной информацией. Опять же, если для того, чтобы показать более подробную информацию, нужно что-то загрузить или посчитать, то можно вынести обработку в другой тред, но для пользователя понятнее, если откроется новый экран и на нем будет показан индикатор загрузки с поясняющим сообщением, и там уже запустится загрузка в отдельном треде. Элемент, с которого поступило событие, не может быть нажат второй раз во время обработки первого события.
На титаниуме же, вы можете дважды нажать на кнопку и открыть два экрана. Стоит уточнить, что на тот момент, блокировка кнопки установкой enabled = false не работала, а на некоторых элементах интерфейса не работает до сих пор jira.appcelerator.org/browse/TIMOB-12668
Если, например, рассмотреть нативные таблицы, то часто реализуют открытие экрана с подробной информацией по клику на элемент списка. По умолчанию, т.е. без лишнего кода, после клика на один элемент списка, пользователь не сможет выбрать другой, пока событие не обработано, в том числе пока не открыт экран с подробной информацией. Опять же, если для того, чтобы показать более подробную информацию, нужно что-то загрузить или посчитать, то можно вынести обработку в другой тред, но для пользователя понятнее, если откроется новый экран и на нем будет показан индикатор загрузки с поясняющим сообщением, и там уже запустится загрузка в отдельном треде. Элемент, с которого поступило событие, не может быть нажат второй раз во время обработки первого события.
На титаниуме же, вы можете дважды нажать на кнопку и открыть два экрана. Стоит уточнить, что на тот момент, блокировка кнопки установкой enabled = false не работала, а на некоторых элементах интерфейса не работает до сих пор jira.appcelerator.org/browse/TIMOB-12668
И за этот титаниум надо платить деньги?!
Спасибо за вести с полей.
Подозревал, что с кроссплатформенными фреймворками не очень хорошо все, но чтоб настолько печально…
Подозревал, что с кроссплатформенными фреймворками не очень хорошо все, но чтоб настолько печально…
И вообще хотелось бы узнать, а выгодно ли писать на кроссплатформенным фреймворке. Код заметно выпростает и усложняется из-за различий платформ. И писать его опять же сложней. Может статься, что время написания двух версий с нуля будет меньше чем единой универсальной. Плюс написание сразу двух версий под разные платформы отлично распараллеливается.
P.S. По моему личному мнений динамически-типатизируемые языки сильно замедляют процесс обработки. Ибо просто не встречал сред разработки для javascript которые позволяют быстро и не отходя от кассы понять какого типа эта переменная и какие функции / поля у нее есть.
P.S. По моему личному мнений динамически-типатизируемые языки сильно замедляют процесс обработки. Ибо просто не встречал сред разработки для javascript которые позволяют быстро и не отходя от кассы понять какого типа эта переменная и какие функции / поля у нее есть.
Все очень сильно зависит от задачи. Если речь идет о бизнес-приложениях, для которых все левые свистоперделки не особо нужны, то с тем же phonegap (к сожалению статистики по ксамарину и титаниуму у меня нету), если дизайн разрабатывался с учетом того что мы имеем дело с гибридом, оценка проекта всего на 10-20% выше чем у нативных проектов. Причем добавление новой платформы это все те же 10% времени, так что если нам (а точнее если это нужно клиенту) нужно реализовать проект на 3 платформы, то клиенту это обойдется раза в ~2.5 дешевле. Но это при наличии команды, у которой есть опыт разработки таких приложений, и если задача оптимизирована под гибриды, ну и было бы неплохо иметь нативщиков, на которых можно переложить задачи, которые проще и лучше реализовать нативно.
Но опять же все зависит от проекта, задач и требований.
Но опять же все зависит от проекта, задач и требований.
По поводу javascript, если вам нужна статическая типизация, вы можете вооружиться dart
Поверю специалистам что оценка времени на проект, всего лишь на 10-20% больше чем у нативного. А как с качеством и быстротой работы у гибридов? Судя по выше написанному существует определенные проблемы с большим количеством нажатий в секунду. Скажем скрол list view и тут же мгновенный выбор ячеек и открытие нового окна нормально работает? Или же с точки зрения пользователя интерфейс 0.5 сек лагает?
ну начнем с того что у вас нету ничего типа «list view» и окон. Лаг к 0,3 секунды при нажатии обходится обработкой тач-событий либо же обработкой нативных событий как я уже описывал выше. Лаги с отрисовкой — все зависит от верстки и количества элементов. Определенный лаг всеравно будет, но не настолько критичный. К слову я и в нативных проектах видел проблемы с подобным. Ну и еще все зависит от платформы, скажем на ios в силу некоторых особенностей ui рендрится намного быстрее (приоритет процесса с webview повыше), а на андроиде уже нехилые лаги заметны. Хотя на 4.4 этих налогов уже нету.
Опять же все нужно оценивать. Если основной фичей вашего приложения должно быть отображение огромной таблицы, с переходом по клику на ячейку, и будут поддерживаться только две платформы, возможно будет эффективнее реализовать это дело нативно. Еще как вариант, если это только часть функционала, реализовать только саму таблицу нативно, и открывать скрин с webview (так делают, есть так же steroids.js но он уныл и проприетарный).
Опять же все нужно оценивать. Если основной фичей вашего приложения должно быть отображение огромной таблицы, с переходом по клику на ячейку, и будут поддерживаться только две платформы, возможно будет эффективнее реализовать это дело нативно. Еще как вариант, если это только часть функционала, реализовать только саму таблицу нативно, и открывать скрин с webview (так делают, есть так же steroids.js но он уныл и проприетарный).
>Если основной фичей вашего приложения должно быть отображение огромной таблицы, с переходом по клику на ячейку, и будут поддерживаться только две платформы, возможно будет эффективнее реализовать это дело нативно
Если это действительно огромная таблица, то практически только нативно, либо трансляцией в нативный код (как у Xamarin). Иначе будет падать по памяти на каждом шагу, а ничего поправить вы не сможете, ибо работа с памятью web view это вещь в себе.
Если это действительно огромная таблица, то практически только нативно, либо трансляцией в нативный код (как у Xamarin). Иначе будет падать по памяти на каждом шагу, а ничего поправить вы не сможете, ибо работа с памятью web view это вещь в себе.
А сколько это, огромная таблица? Я думаю что если в таблице больше 100К ячеек, то что-то пошло не так при проектировании интерфейса.
Подозреваю что проект на javasript спокойно может загнуться и при просмотре списка товаров из 100 наименований с картинками
Любая галерея, сотня — другая картинок, например.
у вас падает браузер при просмотре google images с мобильного устройства?
У гугла хорошие инженеры. Если тупо загнать картинки в DOM — да, все упадет нафиг. Их надо асинхронно загружать и выгружать. И все это будет дергаться и тупить, прямо как у гугла или фликра, о 60fps речи не будет никакой.
я о том и говорю, смотря как сделать. И нативный вариант да, будет лучше, но опять же если говорить о том, что бы делать такую галерею с нуля, и для нативного ui придется делать подобные оптимизации.
Оптимизации делать придётся, но прослойка между программой и системой будет меньше.
>для нативного ui придется делать подобные оптимизации.
Да, еще как придется. Я возился с быстрым скроллом сотен картинок очень долго. Оперативки выделяемой приложению в том же айфоне хватает на несколько десятков полноразмерных картинок, поэтому обычно этого не замечают. Но если речь о сотнях то все, вешалка и накручивание всякого разного.
Да, еще как придется. Я возился с быстрым скроллом сотен картинок очень долго. Оперативки выделяемой приложению в том же айфоне хватает на несколько десятков полноразмерных картинок, поэтому обычно этого не замечают. Но если речь о сотнях то все, вешалка и накручивание всякого разного.
Как здесь уже правильно заметили, проблему дабл-кликов следует решать путем обработки touch-ивентов, а не кликов. И потом, возможно я чего-то не понимаю, но что вам мешает в коллбеке на клик или тап проставлять event.currentTarget'у атрибут disabled до момента полной обработки события?
Тут по поводу Xamarin вспомнили, вставлю и свои 5 копеек, так как имею честь с ним работать в последнее время. Хороший фреймворк, в целом багов особо не заметил(если несколько неудобных моментов, которые впринципе автоматизируются). Но для работы с ним нужно знать, как минимум азы разработки под конкретную платформу. Если пишешь под iOS, нужно изучить разработку под iOS, тоже самое с Android. Хотя и Xamarin делает библиотеку Monotouch.Dialog, Monodroid.Dialog для унификации работы с интерфейсами, в целом все же надо знать как работать с конкретной платформой.
Но Xamarin дает возможность выносить работу с бизнес-логикой, с датой, с сервисами в отдельные Portable Library, остается только писать интерфейс. Ну и в ООП хватает стратегий и паттернов, что бы унифицировать ядро приложение, главное им уметь правильно следовать.
Резюмируя вышесказнное могу сказать, что порог вхождения в Xamarin довольно высок, с виду он решает меньше проблем, чем тот же Titanium, да и шаблоны проектирования нужно подтягивать. Но с другой стороны, Xamarin надежней того же Titanium и имеет высокую производительность, а так же доступ к более менее богатой инфраструктуре Mono(.Net). Так например я спокойно использую в проекте библиотеки по работе с Rest (RestSharp), работа с json (Newton json.net) и другие. Применяю Linq, generics и другие прелести C#. К тому же вся бизнес логика вынесена в отдельную библиотеку, а работа с ресурами(картинки, звуки и т.п.) решаются с помощью build скрипта.
Но Xamarin дает возможность выносить работу с бизнес-логикой, с датой, с сервисами в отдельные Portable Library, остается только писать интерфейс. Ну и в ООП хватает стратегий и паттернов, что бы унифицировать ядро приложение, главное им уметь правильно следовать.
Резюмируя вышесказнное могу сказать, что порог вхождения в Xamarin довольно высок, с виду он решает меньше проблем, чем тот же Titanium, да и шаблоны проектирования нужно подтягивать. Но с другой стороны, Xamarin надежней того же Titanium и имеет высокую производительность, а так же доступ к более менее богатой инфраструктуре Mono(.Net). Так например я спокойно использую в проекте библиотеки по работе с Rest (RestSharp), работа с json (Newton json.net) и другие. Применяю Linq, generics и другие прелести C#. К тому же вся бизнес логика вынесена в отдельную библиотеку, а работа с ресурами(картинки, звуки и т.п.) решаются с помощью build скрипта.
Так же замечу, что в Xamarin можно строить интерфейс родными стредствами (iOS Interface Builder), а для Дроида есть встроенный редактор в саму Xamarin Studio. Так же есть plugin для Visual Studio, в том числе и для iOS(но в случае с iOS build server должен быть все еще на маке).
мы тоже работаем с Xamarin. Фреймворк замечательный, но проблем у него хватает тоже, и надо очень хорошо понимать и устройство каждой платформы, и как работает сам Моно
Попробуйте Steroids.js. Это дополнение к Phonegap, которое позволяет поднять уровень производительности обычных Phonegap-приложений за счет использования сразу нескольких WebView'ов. Также у них в поставке есть интересные кроссплатформенные дополнения к Phonegap.
Я сейчас консультирую одну команду, которая пишет проект на связке Angular.js + Steroids.js, в целом процесс идет хорошо. Есть некоторые проблемы, озвученные Вами выше, но нам инструменты нравятся.
Я сейчас консультирую одну команду, которая пишет проект на связке Angular.js + Steroids.js, в целом процесс идет хорошо. Есть некоторые проблемы, озвученные Вами выше, но нам инструменты нравятся.
у стероидов есть один минус, который на корню убил желание с ним работать. Сборка только через их cloud-сервис, слабая поддержка android (в плане нативных фич, причем законтрибьютить не выйдет ибо нативная часть является закрытой).
Вообще идея интересная, и я даже пытался такое соорудить сам, но увы пришел к выводу что лучше заложить часов 8 на интеграцию нативного drawer (например), чем возиться с multiple webview. Хотя и это так же не проблема.
Вообще идея интересная, и я даже пытался такое соорудить сам, но увы пришел к выводу что лучше заложить часов 8 на интеграцию нативного drawer (например), чем возиться с multiple webview. Хотя и это так же не проблема.
А то нибудь использовал Intel XDK или ionic framework?
Javascript — отсутствие типизации замедляет процесс написания кода и усложняет сопровождение.
Дальше можно не читать…
Дальше можно не читать…
А почему вы считаете что это не так? Процесс написания кода оно конечно не замедляет, но усложняет поиск багов что влияет на процесс сопровождения. Хотя опять же все относительно.
Поддерживаю отсутствие типизации довольно ощутимо сказывается на скорости разработки уже даже на средних проектах ( 10 000+ строчек кода). Просто не возможно удержать в голове все объекты и какими полями они обладают. Постоянно приходится лазить по коду, чтобы просто вспомнить с каким объектом ты работаешь.
ну обычно все же пытаются юзать какой jsdoc что бы не держать все это в голове, да и размеры функций стараются держать не такими уж большими…
Попытка разбиения на множество мелких функций в этом случае приводит к умножению сущностей. Приходится помнить что принимает эта функция на вход, что отдает. Комментарии же имеют свойство устаревать, и изначально могут быть некорректными.
В итоге приходится тратить много времени на вещь на побочные вещи, а не собственно кодить.
В итоге приходится тратить много времени на вещь на побочные вещи, а не собственно кодить.
Sign up to leave a comment.
Кроссплатформенная разработка на Titanium – это ужасный конец или ужас без конца?