Обзор разработки мобильных приложений на Ionic Framework

Стоит сказать, что я занимаюсь разработкой нативных мобильных приложений на iOS семь лет, немного умею писать под Android. Последние два года занимался оболочкой под iOS для webView-приложений.

Ionic Framework — вид сверху

Собрал демонстрационную версию компонентов, представленных в Ionic, и записал скринкаст с iPhone.

Скринкаст компонентов Ionic Framework

А тут по ссылке можно вживую посмотреть работу компонент, и как они будут отображаться и работать на iOS и Android. Как нативщик могу сказать, что выглядит и работает, как родные компоненты в операционной системе. Торможения и каких-либо лагов не заметил. На слабеньком Android всё замечательно.

Ionic Framework — копаем в глубь

Если сравнивать с нативной разработкой — неоспоримая экономия раза в два, так как разрабатываешь, смотря результат в браузере, потом проверяешь на обеих платформах. Огромный набор плагинов для доступа к нативным функциям тоже радует, не нужно лезть в нативный код.

Единственное, что я не нашёл, — авторизацию через «ВКонтакте» нативным образом через соответсвующее SDK, при этом Facebook присутствует. Позже напишу соответсвующий плагин, если не найду подходящее решение.

Если сравнить с гибридными приложениями, к которым я привык за последние два года, когда в приложении отображается веб-контент с сервера, тут подход несколько иной. В приложении уже лежат HTML-файлы вёрстки, в которые динамически вставляется контент с данными, полученные с сервера или внутренней базы данных. Так достигается высокая скорость работы интерфейса, в том числе и работа без интернета.

Набросал небольшое приложение по получению заявок с сервера, которое может работать без интернета.

Работа мобильного приложения без интернета

Так как данные представляют из себя небольшой текстовый набор в пару килобайт, на плохом интернете всё это бодренько загружается без всяких проблем, чем если бы грузилась вся веб-страница.

Работа приложения с плохим интернетом

Фишечки Ionic

LiveReload — отличная функция, которая позволяет сразу же видеть результаты работы в мобильном приложении, поправил, сохранил, увидел.

Функция LiveReload в действии

Так же в наборе инструментов Ionic есть возможность публиковать изменения в уже размещённом приложении в AppStore и Google Play, что очень удобно при исправлении критических ошибок.

Без всякого программирования можно собрать интерфейс в специальном редакторе, который позволяет набросать в прямом смысле компоненты и определить их параметры.

Интерфейс представляет из себя HTML, поэтому вёрстку можно заказать у любого веб-специалиста.

Немного кода — для общего понимания

Мне лично понравилось, что в вёрстке сразу можно заложить элементы логики поведения интерфейса, которые легко читаются. В шаблоне ниже видно, что в интерфейсе будут отображаться строки из массива messages, а также определено нажатие по клику.

<ion-row *ngFor="let message of messages" (click)="goToDetailPage(message)">

А вот, например, строка с сообщением из чата, в котором сразу в интерфейсе обозначено, что данная строка будет отображена, только если ник написавшего не соответсвует текущему пользователю. Также в вёрстке сразу вставлены значения словаря message, который чуть выше и был определён.

<ion-col col-9 *ngIf="message.from !== nickname"> <span class="user_name">{{ message.from }}</span><br> <span>{{ message.text }}</span> <div class="time">{{message.created | date:'dd.MM hh:MM:ss'}}</div> </ion-col>

Кнопку можно описать и в интерфейсе, чтобы она была неактивна, если отправлять ещё нечего.

<button ion-button clear color="primary" (click)="sendMessage()" [disabled]="message === ''"> Отправить </button>

Вот тут по большому счёту описан вывод массива в таблицу, а также действие при нажатии на ячейку.

<ion-list [virtualScroll]="listData"> <ion-item *virtualItem="let item" (click)="goToDetailPage(item)"> <h2>{{item.title}}</h2> <p>{{item.timestamp}}</p> </ion-item> </ion-list>

Ещё пример вёрстки авторизации, где сначала предлагаем ввести номер телефона.

<div *ngIf="isLogin"> <ion-item> <ion-label stacked>Номер телефона</ion-label> <ion-input type="number" [(ngModel)]="phoneNumber"></ion-input> </ion-item> <button ion-button id="sign-in-button" (click)="signIn(phoneNumber)"> Войти </button> </div>

А затем при смене переменной isLogin интерфейс меняется на предложение ввести код из SMS.

<div *ngIf="!isLogin"> <ion-item> <ion-label stacked>Проверочный код</ion-label> <ion-input type="number" [(ngModel)]="confirmationCode"></ion-input> </ion-item> <button ion-button id="confirm-sms" (click)="confirmSMS(confirmationCode)"> Подтвердить </button> </div>

Надеюсь, не перегрузил вас кодом, хотел лишь донести простоту вёрстки в базовом варианте, которая неплохо выглядит.

Сам программный код с логикой пишется на Angular, это производная от Javascript, которая легко осваивается при знании Javascript.

Первый практический опыт

Так как я считаю, что инструмент можно освоить лишь на практике, а не читая теорию, я решил написать мессенджер. Мессенджер позволит показать скорость работы мобильного приложения, а ещё это отличная основа для любого проекта с обменом данными в реальном времени.

Так и назову — RealTimePlatform. Платформа для создания мобильных приложений с обменом в реальном времени.

Я два года занимаюсь платформой по созданию сервисов поиска исполнителей, так вот и хотелось сделать некое ответвление в более онлайновую и быструю систему подбора исполнителя, как в такси. Модель Uber подразумевает быстрое назначение исполнителя, вся работа так или иначе похожа на систему сообщений.

Давайте разберёмся, какими сообщениями будем обмениваться при модели Uber:

  • клиент отправляет заявку;
  • исполнители в зависимости от отдалённости и рейтинга получают сообщение с заявкой;
  • исполнитель откликается на заявку;
  • клиент получает подтверждение выезда исполнителя;
  • клиент получает GPS-маршрут приближения исполнителя;
  • при достижении точки А исполнителем, клиент получает сообщение;
  • клиент сообщает, что выходит;
  • исполнитель отмечает начало выполнения заявки;
  • исполнитель отмечает завершение задания;
  • с клиента списывается оплата за заявку;
  • исполнителю начисляются средства за выполненную заявку;
  • клиент оценивает выполненную заявку.

Я реализовываю сейчас транспортную модель доставки данных в мобильном приложении для основы нового проекта.

Что готово на текущий момент:

  • серверный скрипт на NodeJS для доставки данных между приложениями;
  • авторизация по номеру телефона и коду из SMS, использован сервис Firebase, который даёт бесплатно 10 тысяч авторизаций в месяц;
  • реализован общий чат с обменом в режиме реального времени;
  • прокрутка к новому сообщению, если не листать вверх;
  • звук при новом сообщении при открытом приложении;
  • публикация роботом раз в 30 секунд тестовой заявки, тапнув по которой, можно посмотреть детальную информацию;
  • подгрузка 20 последних сообщений с сервера в момент отсутствия пользователя;
  • собрал iOS, доступно через TestFlight;
  • собрал приложение для Android.

В мессенджере доработаю в ближайшее время:

  • подтягивать старые сообщения при прокрутке вверх, те, что больше 20 уже подгруженных;
  • push-уведомления о новых сообщениях.

Ближайший план:

  • реализовать разные группы для чата;
  • выстраивать платформу в Uber-модель.

На мой взгляд, получится отличная основа для различных сфер бизнеса: такси, курьерская служба, ремонт, дед мороз, юридическая помощь, помощь на дороге и другие. В общем, любой вид услуг, который необходимо получить в ближайшие десть минут.

Кстати, Ionic позволяет собрать PWA-приложение и под Windows Phone.

0
49 комментариев
Написать комментарий...
Игорь Кравченко

Ionic плох тем что не позволяет сделать нормальное web приложение, он заточен только под mobile. Вопрос производительности там открытый- мой опыт скорее негативный.
Я сейчас советую смотреть в сторону flutter - быстро писать и отлично работает.

Ответить
Развернуть ветку
Евгений Малаховский
Автор

а в чем конкретно негативный опыт?
flutter это тоже по сути веб + натив

Ответить
Развернуть ветку
Игорь Кравченко

flutter НЕ использует webview - у них собственный движок рендеринга нацеленный на производительность в 120 кадров в секунду. То есть каждый пиксель рендерит flutter и не зависит от версии операционный системы(если мы говорим о визуальном представлении widget)

Ответить
Развернуть ветку
Shadlance Darking

Если не прототип, если нужны:
- стабильность / maturity
- производительность
- отсутствие костылей исп. инструмента (а они всегда будут)
- фичи которые не идут или не поддерживаются «из коробки»
- возможность релизнуть «последнюю» фичу под платформу без оглядки установленные рамки
То только Native.
Если нужна скорость и спецификация по проекту стабильна (фичи не требуют вмешательства в дописывании с нативки) - Welcome к универсальным решениям.

Ответить
Развернуть ветку
Владимир

поддерживаю, именно такое же впечатление сложилось при использовании Ionic 2. Может ща там что-то изменилось, но без костылей нельзя было хоть как-то нормально оптимизировать приложение под web, кодесплиттинг не работал, NavController выдавал свои закидоны. В итоге переехали на чистый Angular.

Я сейчас советую смотреть в сторону flutter - быстро писать и отлично работает.

Люто поддерживаю. Сначала отнесся скептически. Flutter работает совсем без JS-движка, как я понял, компилится в нативный код. Да, надо учить Dart, но если знаешь TypeScript, не сложно.

Ответить
Развернуть ветку
Evgeniy Dobryansky

вы  взяли платформу под мобайл и жалуетесь, что она плохо работает на десктоп?

Ответить
Развернуть ветку
Zy2ba

Дак вроде разработчики её позиционируют её именно как универсальное решение для написания приложений под всё

Ответить
Развернуть ветку
Игнат Донцов

Как человек, который создавал приложения еще в первой бета-версии 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

Ответить
Развернуть ветку
Eugene Basov

Согласен, 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 чтобы сделать кучу вещей,в итоге при отстуствии грамотного подхода, все как бы работает, но со временем выходит печаль.

Ответить
Развернуть ветку
Денис Гордиенко

А в чём вы увидели принципиальное преимущество реакта перед иоником?

Ответить
Развернуть ветку
Andrew R.

RN – это не webview.

Ответить
Развернуть ветку
Денис Гордиенко

ionic тоже

Ответить
Развернуть ветку
Леонид Лютов

ionic без webview всё ещё в разработке и не годится для прода.

Ответить
Развернуть ветку
Eugene Basov

Это какой такой ионик без вебвью?

Ответить
Развернуть ветку
Леонид Лютов
Ответить
Развернуть ветку
Eugene Basov

Это тот же вебвью

Ответить
Развернуть ветку
Леонид Лютов

Да, это всего-лишь форк кордовы, переоценил их конечно))

Ответить
Развернуть ветку
Георгий Хромченко

React Native - это не WebView. Это именно Native контролы, поэтому скорость и плавность при обработке большого количества данных в RN все таки выше.

На вопрос чем мне не угодил Ionic и React - корректнее сравнивать React vs Angular, это вопрос флеймовый, мне лично нравится именно стройность концепции одностороннего потока данных в React + Redux, а также разделение состояния приложения и рендеринга

В Angular проектах по сути отсутствует какое-то явно требование к архитектуре, в итоге я видел несколько проектов где пишут кто во что горазд и цена сопровождения проекта становится ну просто невероятной, более того - знаю один проект который просто был закрыт именно по причине возрастающей сложности.

Ответить
Развернуть ветку
Nikolay Lebedev

Интересно узнать мнение у автора, как нативного разработчика:
Какие проекты точно не надо разрабатывать как гибридное приложение?

Ответить
Развернуть ветку
Зеленый и громкий

Те, где нужна плотная интеграция с аппаратной частью, что может дать нативная разработка. Любые приложения, работающие с мультимедиа, дополненной реальностью, кастомным сетевым стеком (сложные чаты и voip) итд.

Ответить
Развернуть ветку
Евгений Малаховский
Автор

игры и приложения с большой долей анимации
аппаратная часть практически вся доступна в плагинах
дополненная реальность точно натив само собой

Ответить
Развернуть ветку
Eugene Basov

1. Там где важна скорость загрузки приложения, тут ионик серьёзно проигрывает.
2. Если нужна анимация интерфейса.

Ответить
Развернуть ветку
Nikolay Lebedev

п.1 ээ но это получается 99% всех приложений.. Все ж хотят чтоб "не тормозило"

Ответить
Развернуть ветку
Shadlance Darking

Хотят и готовы оплачивать хотелки - разные вещи, тем более если речь об MVP.

Ответить
Развернуть ветку
Eugene Basov

Иногда этим можно пренебречь, особенно если приложение не является основным бизнес-активом. Например, если какая-нибудь пиццерия хочет сделать приложение для заказа доставки, и сразу на две платформы. В этом случае Ионик подходит отличным образом, тут не так важно, будет приложение загружаться за 0.5с или за 2-3с.

Ответить
Развернуть ветку
Евгений Малаховский
Автор

2-3 секунды считаете при старте существенная проблема чтобы тратить на нативную разработку?

Ответить
Развернуть ветку
Eugene Basov

Да, например, если это мессенджер или таск-менеджер или ещё что-то для частого использования.

Ответить
Развернуть ветку
Андрей Пронин

А ссылки на код не планируется ?

Ответить
Развернуть ветку
Георгий Хромченко

Это контент-маркетинг конторы, которая допиливает такие приложения под заказ, поэтому исходников не будет :)

Ответить
Развернуть ветку
Андрей Пронин

А иначе смысл этой статьи.

Я примерно такую же могу написать про хамарин

Ответить
Развернуть ветку
Георгий Хромченко

Ну для программистов прямо скажем - и в исходниках этого проекта смысла никакого, и никакого секретного ингридиента, я на RN + Firebase за несколько дней такой базовый каркас напишу, как и любой разработчик.

Вся трата времени и аналитика происходят потом, при реальной эксплуатации, анализе процесса клиентов и доработках под конкретные ситуации. Кому-то важно realtime обновление, кому-то - бронебойная режима без интернета совсем с редкими синхронизациями, у кого-то сложное движение задачи по workflow. Разные механизмы обработки невыполненных заявок. Разные механизмы распределения заявок по исполнителям.

Ответить
Развернуть ветку
Андрей Пронин

Ну почему же

Для программиста, который ещё не работал с этой технологий - будет полезно рабочее приложение посмотреть.

Ответить
Развернуть ветку
Евгений Малаховский
Автор

время покажет...

Ответить
Развернуть ветку
Da Apricot

Мы тоже сейчас на нем разрабатываем первое приложение. Согласен по простоте тестирования и настройки интерфейса - даже не имея никакого опыта выходит вполне работоспособный продукт. Для MVP точно хватит

Ответить
Развернуть ветку
Артем

Мы на Ionic тоже разработали приложение для интернет магазинов и успешно его продаем как сервис. Очень довольны фреймворком. Скорость разработки значительно быстрее натива ( на нативе тоже писали ).

Ответить
Развернуть ветку
Зеленый и громкий

Ионик и реакт нейтив ок для мвп. Главное не влазить в суппорт таких продуктов, когда заказчик хочет мвп превратить в кастомный продукт. Там уже стоимость будет расти по экспоненте.

Ответить
Развернуть ветку
Ingvar K

Я выбрал из набора кроссплатформенных тулз 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.

Ответить
Развернуть ветку
Ildar Karimov
А вот например строка с сообщением из чата, в котором сразу в интерфейсе обозначено что данная страка будет отображена, только если ник написавшего не соответсвует текущему пользователю.

А как на такое юнит-тесты писать?

Ответить
Развернуть ветку
Евгений Малаховский
Автор

так речь о сообщении от другого пользователя всего лишь

Ответить
Развернуть ветку
Ildar Karimov

Но тестами это всё равно ведь нужно покрыть.

Ответить
Развернуть ветку
Denis Novikov

Ionic можно для MVP только. А лучше сразу на RN.

Ответить
Развернуть ветку
Sultan Karybaev

А можете код на гитхаб выложить?)

Ответить
Развернуть ветку
Евгений Малаховский
Автор

Цель была в обзоре инструмента, а приложение было для демонстрации работы фреймворка.

Ответить
Развернуть ветку
Roman Bessonov

Подскажите такой вопрос мы планируем выпустить приложение наподобие “Fishbook” возможно использовать ionic ?

Ответить
Развернуть ветку
46 комментариев
Раскрывать всегда