причем не только в терминах быстрее/медленнее, но и в конкретных цифрах.
Порой мне кажется, что основное достижение команды разработчиков iOS очень часто остается без внимания рецензентов: факт того, что на всех iOS устройствах движение пальцев по экрану вызывает точно соответствующее им перемещение объектов. Не подмораживает, не вздрагивает, создается иллюзия, будто вы физически управляете объектом. Всякий раз когда я беру в руки новое устройство под управлением Android и пользуюсь им, я удивляюсь, обнаружив, что его интерфейс не так отзывчив, как на устройствах iOS.Jason Snell
Статья может и познавательная в цифрах, только вот пользователи выбирают программы не по цифрам а потому — нравятся им они или нет, и мне почему-то кажется что пользователь не будет пользоваться приложением которое ему не нравится. На рынке сейчас достаточная конкуренция, чтобы выбрать альтернативу.
Но даже этот факт не дает мне права утверждать, что все фреймворки, которые помогают нарисовать стандартный UI бесполезны.
А я это не утверждал — будьте внимательны. Я утверждал:
более чем в 90% случаев
можно к примеру посмотреть скриншоты много там программ со стандартными кнопками? Возможно я и преувеличил, но все равно нестандартного больше половины. Прошу заметить, что и раньше и сейчас, речь не идет о стандартных UI патернах, а именно о стандартных элементах управления реализованных в указаном фреймверке.
позволяет откастомизировать UI в соответствии с требованиями
Не хочу вас расстраивать, но на мобильных браузерах это не всегда приемлемо использование css фреймверка для UI, мало того, как правило это идет во вред приложению. К примеру здесь предлагают отказаться от слайд анимации на андроиде, а у нас она летает даже на двойке. Это не потому что мы такие 'умные', а просто потому что мы понимаем как надо сделать чтобы конечному юзеру понравилось. А JQueryMobile посильнее будет PhoneJS.
Если Вам показались мои замечания не конструктивными, мне жаль — потому как я пытался объяснить, что из трех мной прочитанных статей об этом фреймверке, я не увидел ни одного преимущества перед уже существующими фреймверками.
И я не увидел
зачем и какие проблемы они решают
то что не делают другие фреймверки.
Хочу пригласить Вас в Одессу мы с коллегой прочитаем доклады именно по мобильной разработке: о PhoneGap, да и о том как влияет впечатление от программы на прибыль заказчика приложения.
Если именно об этом демо:
1)то была неправильно сделана анимация при свайпе, с аналога адаптервью на андроиде(установка онлайн стилей для каждого элемента), перешли на аналог hamer.js — двигаем рут, а чаилдам просто меняем место по окончании анимации.
2) на некоторых андроидах был баг транзишен с лефтом — вызывалась «доводка» после анимации с translate3D — просто translate3D выполнялся сразу так как эта анимация юзает графический ускоритель, а лефт потом. При этом на iOs хватало быстродействия а на андроиде нет.
Очень ОЧЕНЬ спорная ссылка. Я например больше доверяю собственному опыту и http://caniuse.com/webgl а они утверждают что чистого WebGL нет ни на иосе ни на андроиде. Единственный вариант это если они имплементировали собственный вэбвью…
1) на андроиде нет WebWorkers, поэтому о каком их использовании может идти речь?
2) приведенная ссылка абсолютно не обясняет тонкостей и проблем мобильных приложений. «Масло масляное», поверте я когда перобретаю смартфон я догадываюсь что он будет медленее моего десктопа или ноута.
3)«Так мы берём на себя заботу об UI, а пользователь пишет UI-independent логику, которая на 99% не зависит от браузера.» извините, но это не самое необходимое. Как раз наоборот: более чем в 90% случаев — заказчик хочет нестандартный UI(поверьте, наша компания имеет опыт в разработке более чем 150 мобильных приложений, из них только 4 для собственного бренда), и что потом делать?
и т.д.
Просто на момент чтения данной статьи у меня на компе лежит статья как раз о тонкостях и проблемах PhoneGap, ждем реквизитов для оплаты корпоративного акка на хабре.
В качестве затравки видео на програму которая делает абсолютную хрень.
PhoneGap программа была написана за 6 часов и UI оптимизация 11 часов, в первом виджете отображается через слайд 14 000 объектов данных.
Хочу также обратить внимание на UI, его верстка не вошла во время разработки — просто парень сел и наваял кнопки и бары которые ему нравятся за 4 часа. Это по поводу «хочу кнопочки, но не такие»
Для того чтобы педалить фреймверки надо понимать зачем и какие проблемы они решают.
если вы его сделаете невидимым(каковым он является по умолчанию в чистом андроиде) — его не надо перемещать — он не будет мешать
А хаки… Можем поговорить и о них)) если вам нравится iOS — посмотрите на его реализацию скрола при точе, который дропает зет индекс, рабер эффект или тотже позишен фиксед, если WP8 — давайте поговорим о поинтерах и т.д. можно продолжать бесконечно О ЛЮБОЙ ПЛАТФОРМЕ
ИДЕАЛЬНЫХ ПЛАТФОРМ НЕТ, даже в нативщине, просите андроид девелопера к примеру наверстать список который вы верстеите float:left с переходом на следующую строку. Если не хотите матов — не спрашивайте.
Это я к тому что если кто то за что то берется — он должен понимать что любое новое дело требует приложить усилие и разобратся.
Прошу прощения за безграмотные комментарии или стиль изложения, но к сожалению статья не дает представления кроссплатформеной разработке упущены некоторые ключевые моменты, до разработки и во время.
Просто все статьи которые встречались написаны или нативными программистами которые решили попробовать кросс или фрондэдщиками которые решили попробовать новую для себя стезю. Это не нативщина и не фронтэнд! и подходы здесь другие.
Т.к. судя по статьям тема интересна — буду катать статью с аналитикой и легкий туториал без частностей(только с основными моментами), начну завтра.))
Верстка в процентах лично мне не нравится — едет в зависимости от разрешения, я бы использовал следующий подход:
несколько, к примеру 3, media-query в которых прописана в пикселях высота хэдера и футера а контент вывешен на абсолют по топу и ботому совпадающему с высотой футера и хедера. Чудненько работает.
PS Не надо экономить 300 кб — вы их не качаете с инета, разница между тем что вы добавите или нет какой либо JS файл от 250мск до 300 мск и то если вы не поставили асинхронность. Читайте Закаса или читайте здесь статьи
Если Вы пишете под фонгап и Вас смущают двойные инпуты — есть смысл обратится к нативному программисту чтобы он в методе onCreate активити повесил листенер на вэбвью — если у него появился чаилд — сделать его не видимым
костыли не надо пилить — надо понимать как это работает. Именно в андроиде клавиатура является СИСТЕМНЫМ СЕРВИСОМ, который пользователь может заменить, в связи с этим платформа нуждается в валидируещем прокси объекте для ввода текста. И платформа не виновата, что некоторые БЕЗГРАМОТНЫЕ ПРОИЗВОДИТЕЛИ тупо забыли вынести этот объект за пределы видимости или сделать его прозрачным
5) «Хочется также отметить, что в случае, если вам не нужны расширенные функции работы с телефоном: акселерометр, компас, камера, медиа и т.д. подключать библиотеку cordova не обязательно (а это примерно 300 килобайт). Геолокация, кстати, доступна и без нее.» — cordova ЭТО НЕ БИБЛИОТЕКА. cordova — это возможность запускать js/html (заметьте без 5) приложение как нативное, и только как дополнительные фитчи — позиционируются интерфейсы доступа к хардварным фитчам мобильного телефона. По сути cordova состоит из нативной части — расширенного webview, характерного именно для данной платформы и js обеспечивающего инекцию объекта доступа в яваскрипт
Смертельные ошибки:
1) Кроссплатформеная разработка только под одну платформу — «Итак, мое рабочее задание звучало так: Разработать клиентское приложение, под ОС Android»
2) Выбор фремверка — их не 2, к примеру мы перепрбоволи более 3 десятков под фонгап www.google.com.ua/search?q=js+mobile+ui+framework&oq=js+mobile+ui+&aqs=chrome.1.57j0l3j62l2.21266j0&sourceid=chrome&ie=UTF-8
3) Никто никогда не верстает с «И самый последний нюанс это position:fixed.» если есть поддержка iOs, на андроиде кстати вполне работает
4) «мобильная платформа была указана как Android 2.3» — SenchaTouch и андроид до 4.1 НЕСОВМЕСТИМЫ!
и.т.д.
Я наверное расстрою, но то что написано в данной статье не жизнеспасобно. Именно после таких статей и приложений — люди выступают с заявлениями типа
Хотя есть и положительная сторона — четко описаны все стадии разработки
Крайне странная подборка
сравнивать PhoneGap и SenchaTouch или Titanium c Enyo это по крайней мере не корректно(я бы сказал «бред»). Свалили в одну кучу титаниум как платформу, фонгап или джсные либы для UI
Уважаемый, NermaN
Я не буду доказывать Вам что вы правы или не правы. Просто хотелось бы сделать пару замечаний:
1)
(кстати рекомендую Overthrow и крайне не рекомендую iscroll-4 по причине ужасной скорости работы).
Сравнение абсолютно не корректно: Overthrow — полифил, iscroll-4 — либа. Кроме того о каком nativelook может идти реч если Overthrow, по умолчанию добавляет rabber эффект на iOS и дропает все z-index внутри себя. iScroll — он НАМНОГО более широк в функциональном плане, и у него намного больше возможностей — это не просто полифил скрола. И если у Вас на андроиде проблема с ним — скорее всего вы не правильно наверстали страничку, он просто сильно критичен к корректной верстке
2)
но сделать хорошую галерею в iOS стиле точно не получится.
Можно и делали, причем со свайпом и 3D, сразу и под андроид и под иос. Основные тонкости которые нужно учесть при этом это:
а) 300ms
б) галерея = адаптер вью
в) трансформации должны быть аля -webkit-transform: translate3d(100%, 0, 0); transform: translate3d(100%, 0, 0); причем в покое тоже должна быть трансформаця с нулевыми параметрами что бы избежать первоначатьного дерганья. А на андроиде к свайпу добавил бы -webkit-transform: translateZ(0); и включил hardware acseleration в манифесте
3)
Приложение работает медленнее и выглядит не так в итоге. Как будто это приложение с какого-то китайского клона а не с этой платформы.
Тут даже сказать нечего — просто не согласен и все, релизнули более полутора десятков апликух на фонгапе, замечаний небыло.
Основная проблема при начале работы с фонгап состорит в следующем в непонимании следующих моментов:
1)PhoneGap это не web — это абсолютно другая специфическая платформа
2)PhoneGap — выполняется на различных МОБИЛЬНЫХ устройствах, поэтому он НАМНОГО более требователен к оптимизации и знанию тонкостей работы браузера, и лепить в одно приложение несколько десятков либ(одна скролит, одна работает с DOM, одна биндит данные, одна структурирует код и т. д. ) здесь не очень корректно — представьте вы налепили эскадру из «звездолетов» и хотите чтобы эта эскадра довезла у вас один единственный ящик. А топлива то жрать будет вся эскадра. Это я не про Вас, просто по опыту код ревью разных PhoneGap «шедевров»
3)В PhoneGap НЕТ UI — это платформа для доступа из html/js приложения к нативной функциональности мобильного устройства такой как компас, БД, акселерометр, контакты и т. д. Представте на секунду что у вас нет нативной реализации лист вю(адаптер вю) — скажите долго ли Вы будете его реализовывать? Вот и я о томже — я пока на данный момент не встречал пока КОРРЕКТНО заточеный, КРОССПЛАТФОРМЕНЫЙ UI JS фреймверк для мобильных устройств? Sencha JQMobile и т. д. — лучше не обсуждать — просто ОЧЕНЬ ДОЛГО = у каждого свои недостатки, а изучили мы их более 3 десятков
Поэтому на фонгапе можно писать: это всегда будет дольше чем нативное приложение под одну конкретную платформу. Но это всегда будет меньше чем под две платформы, даже с учетом оптимизации UI под каждую платформу. И конечно же как и на любой другой платформе — ВАМ НУЖНО ЗНАТЬ ТОНКОСТИ ПЛАТФОРМЫ(немного само рекламы — костно язычный доклад о тонкостях фонгапа, слайды)
Но к сожалению, подход очень похож на ангуляровский, т.е. вместо использования методов addEventListener или on в JQuery на уже существующем контенте, я вынужден исползовать: data-dojo-event=«onClick» data-dojo-args=«evt» то есть прописаные ивенты и аргументы во фреймворке.
Если вы имели ввиду — habrahabr.ru/company/yandex/blog/151700/? То да может, просто то что использует яндекс намного более сложный и нагруженный фреймворк. И кроме того у него немного другой подход — у нас шаблонизация на стороне клиента с использованием DOM машины браузера, у них перд компиляция в JS функцию и потом шаблонизация, тоесть фактически «Подход 2» из статьи + декларативное использование шаблона.
К сожалению, вы не увидели главного — и человек не использовал UI фреймверков
Просто взять и использовать UI фрейверк +MV* — не поможет написать программу на Phontgap — тут надо «понимать все сразу»
Вы это называете частью?
Без комментариев.
Порой мне кажется, что основное достижение команды разработчиков iOS очень часто остается без внимания рецензентов: факт того, что на всех iOS устройствах движение пальцев по экрану вызывает точно соответствующее им перемещение объектов. Не подмораживает, не вздрагивает, создается иллюзия, будто вы физически управляете объектом. Всякий раз когда я беру в руки новое устройство под управлением Android и пользуюсь им, я удивляюсь, обнаружив, что его интерфейс не так отзывчив, как на устройствах iOS. Jason Snell
Статья может и познавательная в цифрах, только вот пользователи выбирают программы не по цифрам а потому — нравятся им они или нет, и мне почему-то кажется что пользователь не будет пользоваться приложением которое ему не нравится. На рынке сейчас достаточная конкуренция, чтобы выбрать альтернативу.
А я это не утверждал — будьте внимательны. Я утверждал: можно к примеру посмотреть скриншоты много там программ со стандартными кнопками? Возможно я и преувеличил, но все равно нестандартного больше половины. Прошу заметить, что и раньше и сейчас, речь не идет о стандартных UI патернах, а именно о стандартных элементах управления реализованных в указаном фреймверке.
Не хочу вас расстраивать, но на мобильных браузерах это не всегда приемлемо использование css фреймверка для UI, мало того, как правило это идет во вред приложению. К примеру здесь предлагают отказаться от слайд анимации на андроиде, а у нас она летает даже на двойке. Это не потому что мы такие 'умные', а просто потому что мы понимаем как надо сделать чтобы конечному юзеру понравилось. А JQueryMobile посильнее будет PhoneJS.
Если Вам показались мои замечания не конструктивными, мне жаль — потому как я пытался объяснить, что из трех мной прочитанных статей об этом фреймверке, я не увидел ни одного преимущества перед уже существующими фреймверками.
И я не увидел то что не делают другие фреймверки.
Хочу пригласить Вас в Одессу мы с коллегой прочитаем доклады именно по мобильной разработке: о PhoneGap, да и о том как влияет впечатление от программы на прибыль заказчика приложения.
1)то была неправильно сделана анимация при свайпе, с аналога адаптервью на андроиде(установка онлайн стилей для каждого элемента), перешли на аналог hamer.js — двигаем рут, а чаилдам просто меняем место по окончании анимации.
2) на некоторых андроидах был баг транзишен с лефтом — вызывалась «доводка» после анимации с translate3D — просто translate3D выполнялся сразу так как эта анимация юзает графический ускоритель, а лефт потом. При этом на iOs хватало быстродействия а на андроиде нет.
2) приведенная ссылка абсолютно не обясняет тонкостей и проблем мобильных приложений. «Масло масляное», поверте я когда перобретаю смартфон я догадываюсь что он будет медленее моего десктопа или ноута.
3)«Так мы берём на себя заботу об UI, а пользователь пишет UI-independent логику, которая на 99% не зависит от браузера.» извините, но это не самое необходимое. Как раз наоборот: более чем в 90% случаев — заказчик хочет нестандартный UI(поверьте, наша компания имеет опыт в разработке более чем 150 мобильных приложений, из них только 4 для собственного бренда), и что потом делать?
и т.д.
Просто на момент чтения данной статьи у меня на компе лежит статья как раз о тонкостях и проблемах PhoneGap, ждем реквизитов для оплаты корпоративного акка на хабре.
В качестве затравки видео на програму которая делает абсолютную хрень.
PhoneGap программа была написана за 6 часов и UI оптимизация 11 часов, в первом виджете отображается через слайд 14 000 объектов данных.
Хочу также обратить внимание на UI, его верстка не вошла во время разработки — просто парень сел и наваял кнопки и бары которые ему нравятся за 4 часа. Это по поводу «хочу кнопочки, но не такие»
Для того чтобы педалить фреймверки надо понимать зачем и какие проблемы они решают.
А хаки… Можем поговорить и о них)) если вам нравится iOS — посмотрите на его реализацию скрола при точе, который дропает зет индекс, рабер эффект или тотже позишен фиксед, если WP8 — давайте поговорим о поинтерах и т.д. можно продолжать бесконечно О ЛЮБОЙ ПЛАТФОРМЕ
ИДЕАЛЬНЫХ ПЛАТФОРМ НЕТ, даже в нативщине, просите андроид девелопера к примеру наверстать список который вы верстеите float:left с переходом на следующую строку. Если не хотите матов — не спрашивайте.
Это я к тому что если кто то за что то берется — он должен понимать что любое новое дело требует приложить усилие и разобратся.
Просто все статьи которые встречались написаны или нативными программистами которые решили попробовать кросс или фрондэдщиками которые решили попробовать новую для себя стезю. Это не нативщина и не фронтэнд! и подходы здесь другие.
Т.к. судя по статьям тема интересна — буду катать статью с аналитикой и легкий туториал без частностей(только с основными моментами), начну завтра.))
Прошу автора извинить меня — наболело.
Верстка в процентах лично мне не нравится — едет в зависимости от разрешения, я бы использовал следующий подход:
несколько, к примеру 3, media-query в которых прописана в пикселях высота хэдера и футера а контент вывешен на абсолют по топу и ботому совпадающему с высотой футера и хедера. Чудненько работает.
костыли не надо пилить — надо понимать как это работает. Именно в андроиде клавиатура является СИСТЕМНЫМ СЕРВИСОМ, который пользователь может заменить, в связи с этим платформа нуждается в валидируещем прокси объекте для ввода текста. И платформа не виновата, что некоторые БЕЗГРАМОТНЫЕ ПРОИЗВОДИТЕЛИ тупо забыли вынести этот объект за пределы видимости или сделать его прозрачным
1) Кроссплатформеная разработка только под одну платформу — «Итак, мое рабочее задание звучало так: Разработать клиентское приложение, под ОС Android»
2) Выбор фремверка — их не 2, к примеру мы перепрбоволи более 3 десятков под фонгап www.google.com.ua/search?q=js+mobile+ui+framework&oq=js+mobile+ui+&aqs=chrome.1.57j0l3j62l2.21266j0&sourceid=chrome&ie=UTF-8
3) Никто никогда не верстает с «И самый последний нюанс это position:fixed.» если есть поддержка iOs, на андроиде кстати вполне работает
4) «мобильная платформа была указана как Android 2.3» — SenchaTouch и андроид до 4.1 НЕСОВМЕСТИМЫ!
и.т.д.
Я наверное расстрою, но то что написано в данной статье не жизнеспасобно. Именно после таких статей и приложений — люди выступают с заявлениями типа
Хотя есть и положительная сторона — четко описаны все стадии разработки
сравнивать PhoneGap и SenchaTouch или Titanium c Enyo это по крайней мере не корректно(я бы сказал «бред»). Свалили в одну кучу титаниум как платформу, фонгап или джсные либы для UI
Я не буду доказывать Вам что вы правы или не правы. Просто хотелось бы сделать пару замечаний:
1) Сравнение абсолютно не корректно: Overthrow — полифил, iscroll-4 — либа. Кроме того о каком nativelook может идти реч если Overthrow, по умолчанию добавляет rabber эффект на iOS и дропает все z-index внутри себя. iScroll — он НАМНОГО более широк в функциональном плане, и у него намного больше возможностей — это не просто полифил скрола. И если у Вас на андроиде проблема с ним — скорее всего вы не правильно наверстали страничку, он просто сильно критичен к корректной верстке
2) Можно и делали, причем со свайпом и 3D, сразу и под андроид и под иос. Основные тонкости которые нужно учесть при этом это:
а) 300ms
б) галерея = адаптер вью
в) трансформации должны быть аля
-webkit-transform: translate3d(100%, 0, 0); transform: translate3d(100%, 0, 0);причем в покое тоже должна быть трансформаця с нулевыми параметрами что бы избежать первоначатьного дерганья. А на андроиде к свайпу добавил бы-webkit-transform: translateZ(0);и включил hardware acseleration в манифесте3) Тут даже сказать нечего — просто не согласен и все, релизнули более полутора десятков апликух на фонгапе, замечаний небыло.
Основная проблема при начале работы с фонгап состорит в следующем в непонимании следующих моментов:
1)PhoneGap это не web — это абсолютно другая специфическая платформа
2)PhoneGap — выполняется на различных МОБИЛЬНЫХ устройствах, поэтому он НАМНОГО более требователен к оптимизации и знанию тонкостей работы браузера, и лепить в одно приложение несколько десятков либ(одна скролит, одна работает с DOM, одна биндит данные, одна структурирует код и т. д. ) здесь не очень корректно — представьте вы налепили эскадру из «звездолетов» и хотите чтобы эта эскадра довезла у вас один единственный ящик. А топлива то жрать будет вся эскадра. Это я не про Вас, просто по опыту код ревью разных PhoneGap «шедевров»
3)В PhoneGap НЕТ UI — это платформа для доступа из html/js приложения к нативной функциональности мобильного устройства такой как компас, БД, акселерометр, контакты и т. д. Представте на секунду что у вас нет нативной реализации лист вю(адаптер вю) — скажите долго ли Вы будете его реализовывать? Вот и я о томже — я пока на данный момент не встречал пока КОРРЕКТНО заточеный, КРОССПЛАТФОРМЕНЫЙ UI JS фреймверк для мобильных устройств? Sencha JQMobile и т. д. — лучше не обсуждать — просто ОЧЕНЬ ДОЛГО = у каждого свои недостатки, а изучили мы их более 3 десятков
Поэтому на фонгапе можно писать: это всегда будет дольше чем нативное приложение под одну конкретную платформу. Но это всегда будет меньше чем под две платформы, даже с учетом оптимизации UI под каждую платформу. И конечно же как и на любой другой платформе — ВАМ НУЖНО ЗНАТЬ ТОНКОСТИ ПЛАТФОРМЫ(немного само рекламы — костно язычный доклад о тонкостях фонгапа, слайды)
Но к сожалению, подход очень похож на ангуляровский, т.е. вместо использования методов addEventListener или on в JQuery на уже существующем контенте, я вынужден исползовать: data-dojo-event=«onClick» data-dojo-args=«evt» то есть прописаные ивенты и аргументы во фреймворке.