Однажды в понедельник утром к нам пришёл клиент, которому необходимо было разработать мультиплатформенное мобильное приложение для банкинга. У него был прототип со всеми экранами, это и стало нашим техзаданием. «Окей, круто». Теперь мы должны воплотить в жизнь эту идею, которая была размером примерно в 50 экранов. И у нас есть всего три месяца. Вау.
С чего начать? Какую технологию использовать? Ту, которая уже устоялась на рынке или лучше сделать ставку на современный стек? Эти вопросы не переставали звучать в наших головах.
Мы подумали, что стоит попробовать каждое решение, перед тем, как выбрать одно. Затем мы начали анализировать все виды возможных решений в надежде найти решение нашей проблемы. Ох, стоп… Это была плохая идея! Этот анализ привёл нас к невозможности сделать выбор вообще. И этот пост как раз об этом. ( Мы как раз начали разработку после написания этой статьи {33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a}) )
(В прототипе было более 50 экранов; требовались такие вещи, как камера, NFC, сервисы локации, Push нотификации и т.д.)
Какова наша цель?
В совершенстве воплотить идею в мобильное приложение, которое полностью удовлетворит нашего клиента, пользователей и НАС ( а нас очень сложно чем-либо удовлетворить 😛 )
Мы считаем, что всё, над чем мы работаем, должно приносить удовлетворение. Мы никогда не хотели бы и не будем делать что-то, чем мы не сможем впоследствии гордиться.
Обойдём дерево возможных решений…
Native Apps: Приложения, разработанные на нативных языках, таких как Java, Objective-C или Swift.
Hybrid Apps: Приложения, разработанные с применением веб-технологий, которые располагаются внутри нативного контейнера, что даёт доступ через API к нативным плагинам
Almost Native Apps: Приложения, выполняемые в виртуальной машине JavaScript, но использующие родные для платформы компоненты пользовательского интерфейса
Нативные приложения
Если вы уже дошли до этой части, то должны понимать, о чём мы говорим. ДА! ЭТО КОШМАР ДЛЯ РАЗРАБОТЧИКА. Создание одинакового приложения на разных языках — это как пролетать через преисподнюю раз за разом. Вы только представьте, как тяжело будет исправлять, дорабатывать и обновлять разные кодовые базы.
Конечно, будет супер-мега-круто, если мы будем разрабатывать и поддерживать чисто нативные приложения. Но мы верим, что это не стоит усилий в этом проекте и просто невозможно уложиться в то время, что у нас есть.
Погодите… а как же Xamarin
Xamarin, поддерживаемый компанией Microsoft, предоставляет возможность сохранять до 75{33d8302486bd10b0fde64d2037652320e6f176a736d71849c0427b0d7398501a} общей кодовой базы, при этом разрабатывая пользовательский интерфейс отдельно для каждой платформы. Это просто ВАУ, не так ли?
Нативный пользовательский интерфейс, нативный доступ к API, нативная производительность. И это абсолютно бесплатно!
Да, Xamarin был бы великолепным вариантом, но здесь всё не так просто. Есть несколько минусов, которые заставляют нас взглянуть и на другие варианты:
- Имеющиеся сроки (у нас есть только 3 месяца)
– Высокие издержки разработки
– Разработка и тестирование UI под каждую платформу отнимает много времени
– Некоторые пожелания клиента могут заставить нас писать библиотеки, а мы хотели бы избежать этого - Решение, которое мы предлагаем, нуждается в быстрой разработке
- Сообщество вокруг Xamarin не такое большое, как хотелось бы
- Наша команда не любит разработку на языке c# 🙁
Но достаточно разговоров. Мы просто перейдём к другому варианту, так как этот не подходит нам по времени на разработку.
(Но если у вас есть достаточно ресурсов и времени, то Xamarin будет отличным вариантом)
Поговорим о гибридах
Гибридные приложения — в таких компоненты интерфейса расположены в контейнере с web-view, то есть фактически в браузере. И здесь первая западня: web-view состоит из DOM и это приводит к существенному замедлению приложений в сравнении с нативными.
Окей. Мы знаем, что это будет медленнее, но посмотрим, чем этот вариант силён.
- Разработка современных веб-приложений (Progressive App)
- Доступны почти все нативные функции через различные обёртки
- Веб технологии (HTML5, CSS, и JS нам очень близки)
- Очень простая поддержка приложений (как минимум, в сравнении с другими вариантами)
- Потрясающая поддержка сообщества
- многое другое…
Нам нужно обдумать, на какие компромисы мы можем пойти с учётом плюсов/минусов…
Посмотрим на имеющиеся здесь варианты:
- Ionic 1.3 с angularJS
– Превосходная поддержка сообщества
– Angularjs — наш давний друг - Framework 7
-Впечатляющий и отлично документированный, но слабая поддержка сообщества
-Кривая обучения довольно крута, так как этот фреймворк самодостаточен - Sencha UI, Appcelerator
-Крутая кривая обучения
-Меньшая поддержка сообщества
-Не бесплатный… - Создание собственного компонента
-Очень многообещающе. Но стоит ли оно усилий? - Ionic 2 с angular 2
-Хмм… Я думаю, что это подойдёт… но… Погодите… Ionic 2 всё ещё в бете
IONIC 1
Пока мы обсуждали только варианты разработки гибридных приложений. Поддержка сообщества у ionic и самого angularJS очень впечатлила нас. Сперва мы взяли ionic 1.3.
- Хорошая документация
- Фреймворк достаточно зрелый
- Мы отлично знаем этот стек технологий
- Очень лёгкое планирование разработки
- Мы в принципе знаем каждый подводный камень в этом проекте
Наверное, нам стоит взять без лишних раздумий ionic 1.3…
Ionic 1.3 построен на angularJS. У нас есть ужасный опыт мобильной разработки на angularJS. Учитывая наши прототипы и сложность будущего приложения, мы уже могли предсказать недостаток производительности, который будет у будущей программы.
IONIC 2
Новая архитектура недавно вышедшего Angular 2 давала нам надежду на увеличение производительности. Ionic 2, с другой стороны, предоставлял гораздо лучший интерфейс и давал ощущение нативного приложения, а это просто фантастика!
Перед тем, как остановиться на Ionic 2, мы видим несколько проблем:
- Всё-таки это гибридное приложение и оно не покажет супер-производительности
- Ionic 2 всё ещё в состоянии беты
- Angular 2 это совершенно новый стек, который нам предстоит освоить
Так почему же нам не хочется расставаться с ionic 2?
- Ionic 2 недавно (примерно 20/12/2016) заморозил свой API, что означает для нас отсутствие крупных проблем с фреймворком в ближайшее время.
- Целевые смартфоны для нашего проекта будут иметь хорошую производительность (в идеале, Galaxy S3 и более поздние версии).
И в этом контексте, будет ли производительность проблемой вообще? Мы так не считаем. И думаем, что хорошее сообщество не станет поддерживать мобильный фреймворк, если он не соответствует ожидаемой производительности
Так, мы сделали ставку на сообщество за angular 2 и ionic 2, которые станут великолепным решением нашей задачи.
И всё начинается… начинается с angular 2
Мы начали исследование angular 2 и Ionic 2 с создания простого прототипа. В процессе создания прототипа мы сфокусировались на переосмыслении UX-части приложения и показывали скетчи интерфейса в sketch.io одновременно для нашего клиента и разработчиков (Времени на проект было мало, поэтому нам нужно было избежать ненужных корректировок проекта от кого-либо).
Почти нативные решения
Пока мы продолжали изучать Ionic 2 и не сделали окончательный выбор, мы не переставали думать и о другом варианте: Почти-нативных приложениях.
Это React Native и Native Script…
Оба фреймворка гордятся своей нативной производительностью. Они используют JavaScript для логики, тогда как UI отрисовывается нативными компонентами.
Звучит очень многообещающе!
- Меньше времени на разработку
- Знакомые технологии (ну… почти)
- Растущее сообщество
- Производительность
Очень тяжело сделать выбор между React Native и Native Script. Это в конце концов окончится битвой между Angular 2 против React JS.
Мы проанализировали доступные компоненты и библиотеки, необходимые нашему приложению.
Наши опасения
- Необходимые плагины:
– Сканер штрихкодов
– NFC
– Card.io
– Push-нотификации
– Сканер отпечатков пальца
– API камеры
– Голосовой API
– Google карты
– Bluetooth - Возможность кастомизации стиля приложения
- Стабильность предлагаемых API
(мы не хотим, чтобы приложение сломалось в будущих версиях фреймворка)
С точки зрения наших опасений, оба фреймворка идеальны.
- +1 за React Native из-за имеющегося у него плагина к Card.io, тогда как у Native Script пока не было такого.
- +1 за Native Script за имеющиеся возможности стилизации приложения.
Снова ничья!
Окончательный вердикт
Что нам выбрать…? Ionic 2? React Native? Или Native Script?
И мы выбрали Ionic 2… Бабах!
Слишком тяжело выбрать лучшего из всего перечисленного. Всё, что мы могли, это выбрать самое удобное решение для нашего проекта (По крайней мере, мы надеемся на это).
Но почему Ionic 2?
Вот несколько причин…
- У Ionic 2 наибольшее сообщество
- Все нужные нам плагины уже есть в нём
- Мы также можем собрать windows-приложение на этой базе
- Нам уже известен этот стек и ничего не нужно изучать
- Typescript — Лучший инструмент!
- Большой +1 за кастомизацию и стили
Это всё?
Одна из главных причин выбора Ionic 2 — это Angular 2! Вы удивлены? Всё просто…
В будущем, когда клиент решит перейти на нативные приложения, Native Script станет нашим спасением. Мы уверены, что Native Script к этому времени уже будет иметь поддержку windows-приложений. И нам не нужно будет переписывать всю логику заново! Нам нужно будет просто создать недостающие компоненты интерфейса и пересобрать приложение.
Вы не думаете, что это офигенный план?
Заключение
Два ключевых момента, на которых мы сделали ставку
- Здоровое сообщество это ключ к успеху
- Angular 2 и Typescript — фантастический дуэт
Предупреждение
Эта история появилась в наших больных головах, пока мы искали наше решение. Будьте готовы удивиться 😛
Оригинал статьи
