Комментарии 28
Увы, Windows Phone как обычно в пролете
+5
Хмм, а нативные UIView там получится открывать? Сомневаюсь, что я смогу стримить RTMP поток прямо из UIWebView…
0
Разобрался.
0
Можно подробней? Как получилось? Вы имели ввиду, показывать UIView поверх UIWebView?
0
Берете нативное приложение, прикручиваете Cordova. Потом прикручиваете ionic. Консольная утилита работать не будет, но все остальное будет. У меня просто уже есть готовые нативные штуки, но есть пару вьюх которые я бы лучше сделал с использованием css.
0
НЛО прилетело и опубликовало эту надпись здесь
Чуть-чуть? Да Вы, батенька, заядлый оптимист!
+4
Всё зависит от приложения и девайса. На моём Nexus 5 несложное приложение на Ionic летает, и реально разницы между нативными приложениями нет. Однако есть интересное приложение Vice Versa , также написанное на Ionic, и вот там уже заметны лаги. Всё относительно :)
+2
Ну это очевидно. Просто мне пришлось разрабатывать довольно сложное приложение и 2\3 всего времени разработки (если не 3\4) ушло именно на исправление:
1) Поведения отображения html на разных девайсах с разными ОС
2) Безумнейшие тормоза
3) Километры багов кордовы
Есть небольшой и очень краткий ридми с проблемами, с которыми я столкнулся и их решениями, которые обнаружились как на личном опыте, так и в интернете), может кому что будет интересно: gist.github.com/SerafimArts/de9900f9977780de355d
1) Поведения отображения html на разных девайсах с разными ОС
2) Безумнейшие тормоза
3) Километры багов кордовы
Есть небольшой и очень краткий ридми с проблемами, с которыми я столкнулся и их решениями, которые обнаружились как на личном опыте, так и в интернете), может кому что будет интересно: gist.github.com/SerafimArts/de9900f9977780de355d
+5
Мне по нраву WebView-приложения и возможность использовать всю мощь открытого стека веб-технологий, но, к сожалению, оратор выше прав. Баги кордовы, тормоза, различия в браузерах на самых неожиданных местах, краши JS в разных браузерах. Всё это умножается на пока что слабую отладку и малый запас собранных граблей на SO. Разработка WebView-приложений сейчас напоминает десктопный веб лет пять-семь назад, те же сложности. Но, надеюсь, у гибридного подхода есть будущее и он переборет свои детские проблемы.
0
Ну, в оправдание могу сказать, что 5ый андроид наконец поддерживает автоапдейт вебвью, так что не за горами «золотая эра». С другой стороны параллельно наступают Haxe и совсем молоденький Jphp, так что кто знает что будет…
0
Для полноты картины стоит здесь упомянуть React Native. Интересный подход на базе virtual DOM, по сути, приложение выступает в роли конструктора UI, на вход которому подаётся виртуальные элементы интерфейса (как это работает и в браузерном React, только сами виртуальные элементы другие, а подход тот же).
Это не совсем «открытый веб» на мобильном устройстве, хотя и гибридное приложение. Обещают хорошую производительность, засчёт того что графический слой нативный. Логика же приложения на JS.
Это не совсем «открытый веб» на мобильном устройстве, хотя и гибридное приложение. Обещают хорошую производительность, засчёт того что графический слой нативный. Логика же приложения на JS.
0
Да, интересно (и спасибо за гиперссылку, ведущую на Genymotion), но пробовать не буду, так как не осваивал Angular и не уверен, что сейчас есть смысл осваивать его (и знания, и потраченное время придётся выкинуть после выхода второй версии его).
+1
Если интересно мнение человека, который освоил первый и начал играться со вторым ангуляром, то вот оно:
Angular 2 другой. Но не настолько другой, чтобы между «знаю первую версию, начинаю изучать вторую» и «ничего не делал на ангуляре, начинаю изучать вторую версию» не было разницы.
Angular 2 сырой. Мне так кажется, что не меньше полугода пройдет, прежде чем можно будет просто вот так взять и выложить проект на нём в продакшен. Плюс от нескольких месяцев до полугода сам ионик после этого будет стабилизироваться.
Если есть и свободное время и интерес, не вижу ни одной настоящей причины не попробовать. Знания по устаревшим технологиям часто бывают ненужными, но никогда — лишними.
Angular 2 другой. Но не настолько другой, чтобы между «знаю первую версию, начинаю изучать вторую» и «ничего не делал на ангуляре, начинаю изучать вторую версию» не было разницы.
Angular 2 сырой. Мне так кажется, что не меньше полугода пройдет, прежде чем можно будет просто вот так взять и выложить проект на нём в продакшен. Плюс от нескольких месяцев до полугода сам ионик после этого будет стабилизироваться.
Если есть и свободное время и интерес, не вижу ни одной настоящей причины не попробовать. Знания по устаревшим технологиям часто бывают ненужными, но никогда — лишними.
+4
Спасибо за обзор! Сам сейчас пилю пару приложений на нем. Очень комфортно построена работа, я почти влюбился в этот фрэймворк) Почему нет варианта голосования «Уже разрабатываю\разработал приложения»? И, кстати, заявлена (в скором времени) поддержка push уведомлений, спешите подписаться!
P.S. Стоит-ли написать пост о разработке и подводных камешках если кому-то интересно?
P.S. Стоит-ли написать пост о разработке и подводных камешках если кому-то интересно?
+3
+1 за новый пост о разработке и подводных камнях
+2
Не подумал о таком пункте, но уже поздно добавлять.
Про пуш уведомления — тема тянет на отдельный пост, если делать с примером реализации. Можно и перевод оформить, есть много классных статей уже.
А статью о разработке конечно пишите. Я вообще удивлен, почему так мало информации на хабре про Ionic. Не то что мало, её просто нет.
Про пуш уведомления — тема тянет на отдельный пост, если делать с примером реализации. Можно и перевод оформить, есть много классных статей уже.
А статью о разработке конечно пишите. Я вообще удивлен, почему так мало информации на хабре про Ionic. Не то что мало, её просто нет.
+1
Вот именно! Такой фрэймворк и никто о нем не знает, это надо поправить… Вопрос: пост лучше сделать как tutorial для быстрого старта или посеръезнее (с этим сложнее)
0
НЛО прилетело и опубликовало эту надпись здесь
В ионике без костылей пока невозможно сделать нормальную навигацию вверх по предполагаемому стеку иерархии вьюх, если приложение инициируется на вложенном стейте. Очевидный пример — открытие приложения по тапу на push-уведомлении.
Допустим, нам надо перейти в диалог, а из него выйти в список диалогов, из которого можно выйти на дашборд. Когда мы начинаем с дашборда и идем вглубь по стеку, все хорошо. Ионик нам покажет кнопочку «Назад», потому что он следит, откуда и куда мы переходим. Но вдруг мы открылись сразу на диалоге! Ионик ни ухом ни рылом, стек навигации пустой. Казалось бы — чего проще: если стек пустой, по кнопке «Назад» идти на некий стейт по-умолчанию. «Гладко было на бумаге, да забыли про овраги» — системная, иониковская кнопка «Назад» показывается только при наличии в стеке навигации «предыдущей» вьюхи, и при пустом стеке она не покажется, даже если ее «форсить» с помощью $ionicNavBarDelegate.showBackButton. Ок, давайте сделаем свою кнопку «Назад» — можно. Только вот системная имеет свои хитрые стили и анимации. Например, умеет под платформы сама подстраиваться.
Открывал им feature, но они решили, что и так хорошо.
Вторая интересная история — с картинками. Как они пишут (и что подтверждают полевые испытания), установка src для img на iPhone 6 вызывает лаг 50-200ms. А у них скролл запилен на JS. А трэд общий. Что происходит при списке из 30 элементов с картинками — можно себе представить.
Пытаются решить двумя способами: загружая картинки через WebWorker и устанавливая вместо ссылки сразу base64, и используя нативный overflow-scroll вместо реализации на JS. С первым вариантом все еще есть вопросы, потому что с base64 все равно есть лаг, хоть и поменьше. Нативный скролл пока только для Android, потому что прикрутили (слава богу) Crosswalk, а iOS нужные события пока не поддерживает.
История с картинками становится еще хуже, когда хочется использовать картинки в элементах collection-repeat (это список, который переиспользует элементы DOM при скролле). Картинки лагают, список дергается как эпилептик.
Более того, раз элементы переиспользуются, картинки выкидываются из кеша браузера и при повторном появлении элемента с ранее отображавшейся картинкой, грузятся заново. Поэтому в случае с collection-repeat только base64.
А использовать его охота уже при величине списка элементов в 100.
Ну и всякое по мелочи, но может быть это мой 4s уже старичок. В десктопном браузере все «как по маслу», как же иначе.
Будем надеяться, что до релиза решат вопрос хотя-бы с картинками. А в целом мне он нравится, наверное, потому что я давно с ангуляром кувыркаюсь.
Допустим, нам надо перейти в диалог, а из него выйти в список диалогов, из которого можно выйти на дашборд. Когда мы начинаем с дашборда и идем вглубь по стеку, все хорошо. Ионик нам покажет кнопочку «Назад», потому что он следит, откуда и куда мы переходим. Но вдруг мы открылись сразу на диалоге! Ионик ни ухом ни рылом, стек навигации пустой. Казалось бы — чего проще: если стек пустой, по кнопке «Назад» идти на некий стейт по-умолчанию. «Гладко было на бумаге, да забыли про овраги» — системная, иониковская кнопка «Назад» показывается только при наличии в стеке навигации «предыдущей» вьюхи, и при пустом стеке она не покажется, даже если ее «форсить» с помощью $ionicNavBarDelegate.showBackButton. Ок, давайте сделаем свою кнопку «Назад» — можно. Только вот системная имеет свои хитрые стили и анимации. Например, умеет под платформы сама подстраиваться.
Открывал им feature, но они решили, что и так хорошо.
Вторая интересная история — с картинками. Как они пишут (и что подтверждают полевые испытания), установка src для img на iPhone 6 вызывает лаг 50-200ms. А у них скролл запилен на JS. А трэд общий. Что происходит при списке из 30 элементов с картинками — можно себе представить.
Пытаются решить двумя способами: загружая картинки через WebWorker и устанавливая вместо ссылки сразу base64, и используя нативный overflow-scroll вместо реализации на JS. С первым вариантом все еще есть вопросы, потому что с base64 все равно есть лаг, хоть и поменьше. Нативный скролл пока только для Android, потому что прикрутили (слава богу) Crosswalk, а iOS нужные события пока не поддерживает.
История с картинками становится еще хуже, когда хочется использовать картинки в элементах collection-repeat (это список, который переиспользует элементы DOM при скролле). Картинки лагают, список дергается как эпилептик.
Более того, раз элементы переиспользуются, картинки выкидываются из кеша браузера и при повторном появлении элемента с ранее отображавшейся картинкой, грузятся заново. Поэтому в случае с collection-repeat только base64.
А использовать его охота уже при величине списка элементов в 100.
Ну и всякое по мелочи, но может быть это мой 4s уже старичок. В десктопном браузере все «как по маслу», как же иначе.
Будем надеяться, что до релиза решат вопрос хотя-бы с картинками. А в целом мне он нравится, наверное, потому что я давно с ангуляром кувыркаюсь.
+1
Первая проблема не решается подменой роутера? Вроде как есть более модный роутер для ангуляра, со вложенными стейтами и прочим.
0
Можно заюзать localStorage как костыль, чтобы при запуске роутер брал оттуда значения, а вот с картинками да, засада, но обещают решить.
0
Нет опции в голосовании «Уже использую»
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ionic framework. Обзор экосистемы