Обзор разработки мобильных приложений на Ionic Framework
Стоит сказать, что я занимаюсь разработкой нативных мобильных приложений на iOS семь лет, немного умею писать под Android. Последние два года занимался оболочкой под iOS для webView-приложений.
Ionic Framework — вид сверху
Собрал демонстрационную версию компонентов, представленных в Ionic, и записал скринкаст с iPhone.
А тут по ссылке можно вживую посмотреть работу компонент, и как они будут отображаться и работать на iOS и Android. Как нативщик могу сказать, что выглядит и работает, как родные компоненты в операционной системе. Торможения и каких-либо лагов не заметил. На слабеньком Android всё замечательно.
Ionic Framework — копаем в глубь
Если сравнивать с нативной разработкой — неоспоримая экономия раза в два, так как разрабатываешь, смотря результат в браузере, потом проверяешь на обеих платформах. Огромный набор плагинов для доступа к нативным функциям тоже радует, не нужно лезть в нативный код.
Единственное, что я не нашёл, — авторизацию через «ВКонтакте» нативным образом через соответсвующее SDK, при этом Facebook присутствует. Позже напишу соответсвующий плагин, если не найду подходящее решение.
Если сравнить с гибридными приложениями, к которым я привык за последние два года, когда в приложении отображается веб-контент с сервера, тут подход несколько иной. В приложении уже лежат HTML-файлы вёрстки, в которые динамически вставляется контент с данными, полученные с сервера или внутренней базы данных. Так достигается высокая скорость работы интерфейса, в том числе и работа без интернета.
Набросал небольшое приложение по получению заявок с сервера, которое может работать без интернета.
Так как данные представляют из себя небольшой текстовый набор в пару килобайт, на плохом интернете всё это бодренько загружается без всяких проблем, чем если бы грузилась вся веб-страница.
Фишечки Ionic
LiveReload — отличная функция, которая позволяет сразу же видеть результаты работы в мобильном приложении, поправил, сохранил, увидел.
Так же в наборе инструментов Ionic есть возможность публиковать изменения в уже размещённом приложении в AppStore и Google Play, что очень удобно при исправлении критических ошибок.
Без всякого программирования можно собрать интерфейс в специальном редакторе, который позволяет набросать в прямом смысле компоненты и определить их параметры.
Интерфейс представляет из себя HTML, поэтому вёрстку можно заказать у любого веб-специалиста.
Немного кода — для общего понимания
Мне лично понравилось, что в вёрстке сразу можно заложить элементы логики поведения интерфейса, которые легко читаются. В шаблоне ниже видно, что в интерфейсе будут отображаться строки из массива messages, а также определено нажатие по клику.
А вот, например, строка с сообщением из чата, в котором сразу в интерфейсе обозначено, что данная строка будет отображена, только если ник написавшего не соответсвует текущему пользователю. Также в вёрстке сразу вставлены значения словаря message, который чуть выше и был определён.
Кнопку можно описать и в интерфейсе, чтобы она была неактивна, если отправлять ещё нечего.
Вот тут по большому счёту описан вывод массива в таблицу, а также действие при нажатии на ячейку.
Ещё пример вёрстки авторизации, где сначала предлагаем ввести номер телефона.
А затем при смене переменной isLogin интерфейс меняется на предложение ввести код из SMS.
Надеюсь, не перегрузил вас кодом, хотел лишь донести простоту вёрстки в базовом варианте, которая неплохо выглядит.
Сам программный код с логикой пишется на Angular, это производная от Javascript, которая легко осваивается при знании Javascript.
Первый практический опыт
Так как я считаю, что инструмент можно освоить лишь на практике, а не читая теорию, я решил написать мессенджер. Мессенджер позволит показать скорость работы мобильного приложения, а ещё это отличная основа для любого проекта с обменом данными в реальном времени.
Так и назову — RealTimePlatform. Платформа для создания мобильных приложений с обменом в реальном времени.
Я два года занимаюсь платформой по созданию сервисов поиска исполнителей, так вот и хотелось сделать некое ответвление в более онлайновую и быструю систему подбора исполнителя, как в такси. Модель Uber подразумевает быстрое назначение исполнителя, вся работа так или иначе похожа на систему сообщений.
Давайте разберёмся, какими сообщениями будем обмениваться при модели Uber:
- клиент отправляет заявку;
- исполнители в зависимости от отдалённости и рейтинга получают сообщение с заявкой;
- исполнитель откликается на заявку;
- клиент получает подтверждение выезда исполнителя;
- клиент получает GPS-маршрут приближения исполнителя;
- при достижении точки А исполнителем, клиент получает сообщение;
- клиент сообщает, что выходит;
- исполнитель отмечает начало выполнения заявки;
- исполнитель отмечает завершение задания;
- с клиента списывается оплата за заявку;
- исполнителю начисляются средства за выполненную заявку;
- клиент оценивает выполненную заявку.
Я реализовываю сейчас транспортную модель доставки данных в мобильном приложении для основы нового проекта.
Что готово на текущий момент:
- серверный скрипт на NodeJS для доставки данных между приложениями;
- авторизация по номеру телефона и коду из SMS, использован сервис Firebase, который даёт бесплатно 10 тысяч авторизаций в месяц;
- реализован общий чат с обменом в режиме реального времени;
- прокрутка к новому сообщению, если не листать вверх;
- звук при новом сообщении при открытом приложении;
- публикация роботом раз в 30 секунд тестовой заявки, тапнув по которой, можно посмотреть детальную информацию;
- подгрузка 20 последних сообщений с сервера в момент отсутствия пользователя;
- собрал iOS, доступно через TestFlight;
- собрал приложение для Android.
В мессенджере доработаю в ближайшее время:
- подтягивать старые сообщения при прокрутке вверх, те, что больше 20 уже подгруженных;
- push-уведомления о новых сообщениях.
Ближайший план:
- реализовать разные группы для чата;
- выстраивать платформу в Uber-модель.
На мой взгляд, получится отличная основа для различных сфер бизнеса: такси, курьерская служба, ремонт, дед мороз, юридическая помощь, помощь на дороге и другие. В общем, любой вид услуг, который необходимо получить в ближайшие десть минут.
Кстати, Ionic позволяет собрать PWA-приложение и под Windows Phone.
Ionic плох тем что не позволяет сделать нормальное web приложение, он заточен только под mobile. Вопрос производительности там открытый- мой опыт скорее негативный.
Я сейчас советую смотреть в сторону flutter - быстро писать и отлично работает.
а в чем конкретно негативный опыт?
flutter это тоже по сути веб + натив
flutter НЕ использует webview - у них собственный движок рендеринга нацеленный на производительность в 120 кадров в секунду. То есть каждый пиксель рендерит flutter и не зависит от версии операционный системы(если мы говорим о визуальном представлении widget)
Если не прототип, если нужны:
- стабильность / maturity
- производительность
- отсутствие костылей исп. инструмента (а они всегда будут)
- фичи которые не идут или не поддерживаются «из коробки»
- возможность релизнуть «последнюю» фичу под платформу без оглядки установленные рамки
То только Native.
Если нужна скорость и спецификация по проекту стабильна (фичи не требуют вмешательства в дописывании с нативки) - Welcome к универсальным решениям.
поддерживаю, именно такое же впечатление сложилось при использовании Ionic 2. Может ща там что-то изменилось, но без костылей нельзя было хоть как-то нормально оптимизировать приложение под web, кодесплиттинг не работал, NavController выдавал свои закидоны. В итоге переехали на чистый Angular.
Я сейчас советую смотреть в сторону flutter - быстро писать и отлично работает.Люто поддерживаю. Сначала отнесся скептически. Flutter работает совсем без JS-движка, как я понял, компилится в нативный код. Да, надо учить Dart, но если знаешь TypeScript, не сложно.
вы взяли платформу под мобайл и жалуетесь, что она плохо работает на десктоп?
Дак вроде разработчики её позиционируют её именно как универсальное решение для написания приложений под всё
Как человек, который создавал приложения еще в первой бета-версии Ionic, хочу добавить следующее:
- фреймворк уже не тот, что раньше, в хорошем смысле. В последней версии Ionic переписан на Stencil - генераторе веб компонентов. Stencil - это крутейшая штука, по моему мнению, за такими инструментами будущее веб-разработки. Он проще, быстрее, легче большинства современных js-фреймворков. Ionic V4 работает заметно шустрее своих предшественников (кому интересно, смотрите сравнение разных версий в их блоге https://blog.ionicframework.com/ionic-framework-4-0-rc-shipped-paving-way-for-final/)
- телефоны за последние несколько лет стали мощнее, веб-приложения уже почти не тормозят на мобильных, иногда их сложно отличить от натива
- Google и MS активно продвигают технологию PWA, которая потенциально может заменить установку приложений из магазина, и для .Ionic это одно из направлений использования
Я сделал на Ioinc V4 демку приложение для заказа еды, так что можете "пощупать" и самостоятельно оценить эту технологию
https://food-delivery-9b489.firebaseapp.com/#/catalog
Согласен, pwa это перспективная вещь, особенно когда сделают (или если сделают) пуши в ios
Я пробовал Ionic1 еще даже - пришел к такому выводу:
Для серьезной работы все таки WebView сильно тормозит, особенно если у клиента какой-нибудь старый Android.
Все свои аналогичные проекты перевел на React Native и очень доволен, причем даже не столько из-за самого RN, сколько нравится архитектурная стройность и сопровождаемость кода на React + Redux, в сравнении с тем, во что превращается код на Angular в сложном проекте.
Ну во-первых, ionic теперь есть и на react (https://reactionic.github.io/), во-вторых, Angular просто надо нормально готовить, а то напишут кучу говна без state managment и использования сервисов для хранения данных, засунут все в компоненты, а потом у них проект на angular сложный... Redux в Angular тоже притащили)
Вот согласен, почему то на Angular часто получается куча говна. Выглядит так будто фреймворк не бьет по рукам и требуются реально хорошие разрабы чтобы понимали где говно а где нет.
То что Ionic на React - гуд, я рад, хотя конкретно этот линк выглядит заброшенным
просто там не нужно строить монстра state managment чтобы сделать кучу вещей,в итоге при отстуствии грамотного подхода, все как бы работает, но со временем выходит печаль.
А в чём вы увидели принципиальное преимущество реакта перед иоником?
RN – это не webview.
ionic тоже
ionic без webview всё ещё в разработке и не годится для прода.
Это какой такой ионик без вебвью?
https://capacitor.ionicframework.com/
Это тот же вебвью
Да, это всего-лишь форк кордовы, переоценил их конечно))
React Native - это не WebView. Это именно Native контролы, поэтому скорость и плавность при обработке большого количества данных в RN все таки выше.
На вопрос чем мне не угодил Ionic и React - корректнее сравнивать React vs Angular, это вопрос флеймовый, мне лично нравится именно стройность концепции одностороннего потока данных в React + Redux, а также разделение состояния приложения и рендеринга
В Angular проектах по сути отсутствует какое-то явно требование к архитектуре, в итоге я видел несколько проектов где пишут кто во что горазд и цена сопровождения проекта становится ну просто невероятной, более того - знаю один проект который просто был закрыт именно по причине возрастающей сложности.
Интересно узнать мнение у автора, как нативного разработчика:
Какие проекты точно не надо разрабатывать как гибридное приложение?
Те, где нужна плотная интеграция с аппаратной частью, что может дать нативная разработка. Любые приложения, работающие с мультимедиа, дополненной реальностью, кастомным сетевым стеком (сложные чаты и voip) итд.
игры и приложения с большой долей анимации
аппаратная часть практически вся доступна в плагинах
дополненная реальность точно натив само собой
1. Там где важна скорость загрузки приложения, тут ионик серьёзно проигрывает.
2. Если нужна анимация интерфейса.
п.1 ээ но это получается 99% всех приложений.. Все ж хотят чтоб "не тормозило"
Хотят и готовы оплачивать хотелки - разные вещи, тем более если речь об MVP.
Иногда этим можно пренебречь, особенно если приложение не является основным бизнес-активом. Например, если какая-нибудь пиццерия хочет сделать приложение для заказа доставки, и сразу на две платформы. В этом случае Ионик подходит отличным образом, тут не так важно, будет приложение загружаться за 0.5с или за 2-3с.
2-3 секунды считаете при старте существенная проблема чтобы тратить на нативную разработку?
Да, например, если это мессенджер или таск-менеджер или ещё что-то для частого использования.
А ссылки на код не планируется ?
Это контент-маркетинг конторы, которая допиливает такие приложения под заказ, поэтому исходников не будет :)
А иначе смысл этой статьи.
Я примерно такую же могу написать про хамарин
Ну для программистов прямо скажем - и в исходниках этого проекта смысла никакого, и никакого секретного ингридиента, я на RN + Firebase за несколько дней такой базовый каркас напишу, как и любой разработчик.
Вся трата времени и аналитика происходят потом, при реальной эксплуатации, анализе процесса клиентов и доработках под конкретные ситуации. Кому-то важно realtime обновление, кому-то - бронебойная режима без интернета совсем с редкими синхронизациями, у кого-то сложное движение задачи по workflow. Разные механизмы обработки невыполненных заявок. Разные механизмы распределения заявок по исполнителям.
Ну почему же
Для программиста, который ещё не работал с этой технологий - будет полезно рабочее приложение посмотреть.
время покажет...
Мы тоже сейчас на нем разрабатываем первое приложение. Согласен по простоте тестирования и настройки интерфейса - даже не имея никакого опыта выходит вполне работоспособный продукт. Для MVP точно хватит
Мы на Ionic тоже разработали приложение для интернет магазинов и успешно его продаем как сервис. Очень довольны фреймворком. Скорость разработки значительно быстрее натива ( на нативе тоже писали ).
Ионик и реакт нейтив ок для мвп. Главное не влазить в суппорт таких продуктов, когда заказчик хочет мвп превратить в кастомный продукт. Там уже стоимость будет расти по экспоненте.
Я выбрал из набора кроссплатформенных тулз Appcelerator Titanium. Он почему-то не такой популярный, как остальные, хотя и был одним из первых, виню в этом беспонтовый маркетинг.
Отличие Titanium-а в том, что вы создаёте нативные компоненты: Кнопки, Лейбы, Вьюшки, которыми управляете из JavaScript.
В JS: "Titanium.UI.createLabel({})" => Отправляет код в нативную среду и создаётся настоящий Label, а не div обёртка.
Минус, как всегда в скорости UI/UX, это в данном случае bottleneck заключается в мосту (Kroll bridge), соединяющему JavaScript среду с нативной, а так же в однопоточности JS.
Решение:
- избегать частых "дёрганий" моста, например на часто вызываемых Listener-ах (e.g. 'change') можно юзать _.debounce(). _.throttle()
- Титаниум позволяет дописывать нативные модули на Java/ObjC, куда можно вытянуть долгие операции
- Или напрямую писать нативный код на JavaScript при помощи Hyperloop технологии (вообще магия!) - https://www.appcelerator.com/mobile-app-development-products/hyperloop/
Юзал Titanium несколько лет до этого, но сейчас бы выбрал Flutter или ReactNative — всё же декларативный подход это must have.
А как на такое юнит-тесты писать?
так речь о сообщении от другого пользователя всего лишь
Но тестами это всё равно ведь нужно покрыть.
Ionic можно для MVP только. А лучше сразу на RN.
А можете код на гитхаб выложить?)
Цель была в обзоре инструмента, а приложение было для демонстрации работы фреймворка.
Подскажите такой вопрос мы планируем выпустить приложение наподобие “Fishbook” возможно использовать ionic ?