Олег Иванов, руководитель направления центра компетенций дистанционных каналов обслуживания департамента ИТ-развития дирекции информационных технологий Московского кредитного банка (МКБ)

Для нас разработка мобильного приложения начиналась с нуля, поэтому и в этой статье мы начнём с самых азов: с определения, что это такое и какие функции в нем должны быть. А дальше пройдем весь путь – от покупки новых гаджетов для тестирования приложения до его запуска. Мы будем рассказывать историю развития нашего приложения с технологическими отступами. Опишем, с какими проблемами мы при этом столкнулись. К сожалению, осветить в этой обзорной статье все подходы, принципы, технологические решения, которые использовались в разработке, мы не сможем, но остановимся на наиболее интересных моментах.

Далее будет акцент на разработку под iOS. Прежде чем начать, давайте определимся, что такое Мобильный банк.

Мобильный банк – это управление банковскими счетами с помощью приложения банка на смартфоне (iPhone и т. п.), планшетном компьютере (iPad, Samsung Galaxy Tab и т. п.). Для совершения банковских операций требуется двухэтапное подтверждение с использованием одноразовых кодов через СМС-сообщения.

Основные банковские операции Мобильного банка:

• использование продуктов банка (счета, карты, вклады, кредиты, пакеты услуг и т. п.)
• просмотр баланса счета
• выписка
• оплата счетов за услуги мобильной связи
• оплата услуг ЖКХ
• перевод средств с карты на карту
• осуществление регулярных платежей
• погашение кредитов
• перевод средств на вклад
• блокировка платежной карты
• и другие.

Приложения для мобильного банкинга – это приложения для интернет-банкинга, адаптированные под небольшие экраны смартфонов и под операционные системы (iOS компании Apple, Android компании Google), устанавливаемые в мобильных устройствах. Стоит отметить, что модельный ряд устройств, работающих под управлением операционной системы Android, очень широк: Samsung, LG, Xiaomi, Huawei и др., что утяжеляет разработку и поддержку приложения под Android.

Исток – MKBMobile 1.0

К нашей команде проект приложения Мобильного банка перешёл от сторонней компании, он был написан на Objective C.

Вот так выглядел проект глазами пользователя:





Этот проект стал стартапом и проверкой наших возможностей. Опыта разработки под мобильную платформу iOS у нашей команды было мало, но мы смело взялись за проект.

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

1. Нужен iMac

Компания Apple славится высокой ценой на свою продукцию. Но экономить здесь не стоит – это скорость вашей разработки!

Примерная, оптимальная конфигурация, которая нам подошла:

• 4-ядерный процессор Intel Core i5 седьмого поколения с тактовой частотой 3,8 ГГц (ускорение Turbo Boost до 4,2 ГГц)
• 32 ГБ памяти DDR4 2400 МГц
• Накопитель Fusion Drive ёмкостью 2 ТБ
• Графический процессор Radeon Pro 580 с 8 ГБ видеопамяти

Примерная стоимость подобной машины – 190 000 руб.

Бытует мнение – для Proграммистов нужны iMac Pro. Это так :) Но цена на них кусается, и если ваша компания готова их приобрести, это увеличит скорость вашей разработки, ну и конечно, повысит эстетический уровень вашего офиса.

2. Нужны iOS-устройства

«Сколько и какие?» – возникает первый вопрос. Всё зависит от вашего приложения.
Если ваше приложение поддерживает только iPhone, как минимум, 2 разного размера маленький (например, iPhone SE) и большой (например, iPhone 8 Plus).

Если ваше приложение поддерживает ещё и iPad, нужен один iPad.

Далее в ход идёт операционная система – её версионность. Если ваше приложение поддерживает минимальную версию, например, начиная с iOS 8.0, нужно запастись устройством с каждым порядковым номером iOS и не забывать «законсервировать» (не обновлять) эту версию на устройстве и следить за появлениями новых версий iOS, не забывая выделить под неё набор устройств.

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

В случае нежелания иметь свою ферму устройств можно смотреть в сторону сторонах компаний предлагающих эту услугу: AWS Device Farm, Xamarin Test Cloud и т. п.

Как уже упоминали, наше приложение поддерживается как под iPhone, так и под iPad. На момент написания статьи наша собственная (!) ферма составляет порядка 30 устройств разных видов и версий ОС.

3. Нужно определиться с подходом разработки под iOS (нативный или альтернативный).

Мы попробовали следующие альтернативные варианты разработки под iOS:

PhoneGap / Cordova

PhoneGap исходно был создан компанией Nitobi. В 2011 году Adobe приобретает Nitobi и бренд PhoneGap. Adobe затем передает одну из версий PhoneGap, назвав её Cordova, в Apache Foundation, оставив себе бренд PhoneGap и сам этот продукт. В результате Cordova можно рассматривать как движок, стоящий под капотом PhoneGap (а также некоторые другие гибридные фреймворки). PhoneGap, в свою очередь, добавляет к возможностям Cordova свои, дополнительные функции.

PhoneGap во многих отношениях очень похож на Ionic. Он так же дает разработчикам возможность создавать кросс-платформенные приложения при помощи веб-технологий, и так же построен на базе Apache Codova. Однако PhoneGap не привязан к какому-то определенному Javascript-фреймворку, поэтому разработчики имеют больший выбор, на чем и как они будут создавать свои приложения.

Увы, PhoneGap использует WebView (который в iOS работает довольно медленно), так что со скоростью у приложений, созданных на базе этого фреймворка, дела не всегда обстоят блестяще.

Xamarin

Основанная в 2011 году компания Xamarin, выпускающая семейство продуктов Xamarin, через пять лет своего существования была куплена компанией Microsoft. Сегодня продукты Xamarin представляют на рынке очень интересный подход к разработке кросс-платформенных мобильных приложений: приложения пишутся на C#, затем Xamarin компилирует его в нативное приложение для iOS, либо для Android, при этом в качестве базовой технологии Xamarin использует Mono, чем кросс-платформенность и обеспечивается. Разработчики Xamarin говорят, что полученные на выходе приложения используют нативное API платформы, для которой приложение компилируется, так что поведение полученного приложения никак не отличается от поведения любого другого приложения на этой же платформе. Разработку, кстати, можно вести при помощи Visual Studio (что совсем неудивительно).

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

Но подобные подходы дают так называемое «гибридное» приложение.

Плюсы альтернативных вариантов:

• кросс-платформенность (сделав одно приложение, его можно экспортировать под любую ОС);
• сроки разработки меньше, чем нативного.

Минусы альтернативных вариантов:

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

И мы решили продолжать «нативную» разработку нашего проекта.

Нативный путь от Apple

4. Прежде всего, нам нужно средство для разработки и написания кода – нам нужен IDE Xcode

Xcode – интегрированная среда разработки (IDE) программного обеспечения для платформ macOS, iOS, watchOS и tvOS, разработанная корпорацией Apple. Первая версия выпущена в 2001 году. Стабильные версии распространяются бесплатно через Mac App Store. Зарегистрированные разработчики также имеют доступ к бета-сборкам через сайт Apple Developer.

Вот так выглядит создание и работа над простым приложением типа Single View App в Xcode:





Несколько интересных моментов на тему Xcode:

Xcode предлагает очень удобный инструментарий для создания UI (user interface — пользовательский интерфейс) – Storyboard.





Но большинство проектов (приложений) для iOS обслуживает не один разработчик, а несколько (команда разработчиков) и при использовании одного Storyboard для всех экранов приложения при использовании распределённых систем управления версиями (SVN, Mercurial, GIT и т.п.) слияние наработок превращает в сущий ад.

Наша команда договорилась о подходе: один Storyboard – один ViewController.
При таком подходе описанная выше проблема исчезает, так как обычно один разработчик реализует одну фичу, то есть все экраны этой фичи.

Для снижения нагрузки в Storyboard при использовании Segue можно использовать функцию ‘Refactor to storyboard’. Этот рефакторинг раскадровки как бы создаёт ссылку в родительском Storyboard, которая ведёт на новый, отдельный Storyboard, где реализуется нужный ViewController.

Также стоит отметить и инструмент отладки от Xcode – Breakpoint.
Breakpoint – это инструмент отладки, который позволяет приостановить выполнение программы до определенного момента. Что позволит нам исследовать код программы (узнать значения переменных в этом моменте, производить некоторые расчеты и т. п.), чтобы узнать, где возникают ошибки.



Данный инструмент интеллектуальный: нам доступны кнопки управления исполнением (Step Over, Step Into), манипулируя которыми мы осуществляем навигацию по нашему коду. Также нам доступны для анализа значения переменных и работа с логами в console output.
При Control-click на индикаторе точки остановки отображается меню команд. Здесь можно установить дополнительные условия срабатывания точки остановки, добавить действия и т. д.
Например, поставим для точки остановки условие срабатывания: переменная step примет значение 4. И после запуска приложения программа остановит свое выполнение в данной точке остановки, только когда переменная step примет значение 4 и не раньше.



Мы можем добавлять дополнительные Expression (свойства и даже вычисления!).

5. Нужно определиться с языком программирования Objective C или новый Swift

Доставшийся нам проект был написан на Objective C, но новый язык программирования Swift уже был на горизонте.

Что из себя представляют эти языки программирования?

Objective C — компилируемый объектно-ориентированный язык программирования, используемый корпорацией Apple, построенный на основе языка Си и парадигм Smalltalk. В частности, объектная модель построена в стиле Smalltalk — то есть объектам посылаются сообщения.

Язык Objective-C существует с 1989 года, последний раз обновлялся в 2006 году, более
10 лет назад. Популярность iOS постоянно растёт, что требует повышение качества приложения. Для работы с Objective C требуется высокая квалификации разработчика.

Всё это стало предпосылками к созданию языка программирования Swift.

Компания Apple начала разрабатывать Swift в 2010 году. 2 июня 2014 года этот язык был официально представлен на всемирной конференции разработчиков на платформах Apple (WWDC). Бесплатное 500-страничное руководство по его использованию было доступно на сервисе iBook Store.

Релиз Swift 1.0 состоялся 9 сентября 2014 года вместе с Gold Master-версией Xcode 6.0 для iOS.
8 июня 2015 года Apple выпустила новую версию Swift 2.0 с повышенной производительностью и новым API обработки ошибок. Улучшился синтаксис языка, появилась функция проверки доступности функций Swift для целевых ОС.

3 декабря 2015 года была выпущена бета-версия Swift 3.0 с поддержкой операционных систем OS X, iOS и Linux, лицензированная под открытой лицензий Apache 2.0.

19 сентября 2017 года была выпущена версия Swift 4.0.

В сентябре 2018 года, вместе с новой версией iOS 12, была выпущена новая стабильная версия языка Swift 4.2, и появилась бета-версия Swift 5.0. В версии 5.0 заявлена, наконец, стабильная работа ABI со стандартными библиотеками (Swift Dynamic Library), поддержка регулярных выражений и первоклассное решение для параллельной обработки данных с асинхронным режимом обработки async/await.

Исходя из всего вышеизложенного, мы решили в новых формах использовать только Swift, осуществлять поддержку старых форм, постепенно переписывая их.

6. Далее нужно разобраться с архитектурой проекта — решили оставить архитектуру MVC от Apple

Model-View-Controller (MVC) назначает объектам в приложении одну из трех ролей: модель, представление или контроллер. Архитектура определяет не только роли, которые объекты играют в приложении, но и способ взаимодействия объектов друг с другом. Каждый из трех типов объектов отделен от других абстрактными границами и взаимодействует с объектами других типов через эти границы (https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html).



Но, применив этот подход, мы столкнулись со следующими проблемами, решить которые смогли, лишь перейдя на новую архитектуру в версии MKBMobile 3.0:

• MVC не дает четких инструкций о том, какие сущности и классы вам нужно создавать, а какие нет. Структура и архитектура модели, а также ее взаимодействие с controller’ом остаются полностью на совести и воображении разработчика(ов).
• Плохое понимание доменной области. Т.е. когда разработчик добавляет новый функционал, вместо создания новых сущностей и рефакторинга существующей архитектуры добавляется новый функционал во ViewController. Что привело к следующей проблеме: Massive View Controller — много кода внутри ViewController.

7. И самое сладкое — iOS SDK (https://developer.apple.com/documentation/)

iOS SDK предоставляет большое количество Frameworks.

Следующий список frameworks мы с особым энтузиазмом использовали в банковском приложении:

• PushKit и UserNotifications для работы с push-уведомлениями;
• PassKit для работы с Apple Pay;
• CallKit (в купе с WebRTC) для работы с VoIP сервисами;
• AVFoundation для работы с аудио ресурсами;
• Contacts для получения доступа к контактам пользователя;
• CommonCrypto для работы с криптографическими функциями.

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

Некоторое время новые фичи (функциональность – новые переводы, платежи, продукты банка (карты, кредиты и др.) хорошо встраивались в приложение.

Но потом приложение стало громоздким и неудобным.

Так появился проект MKBMobile 2.0 со смелой интерфейсной идеей – Trello Pages.

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




Плюсы этого подхода:

• масштабируемость, бесконечное пространство влево/вправо и вниз;
• разделяемость, каждый тип функционала размещался на отдельной странице;
• идеально подходит как для iPad, так и для iPhone.

Но в этой идее оказались и некоторые недостатки:

• пункты верхнего навигационного меню были в сложной доступности;
• приходившие push-уведомления и СМС-уведомления создавали дополнительные сложности в работе с верхним навигационным меню;
• данный подход не соответствовал Human Interface Guidelines от Apple.

Так появилась на свет текущая версия мобильного банка от МКБ — MKBMobile 3.0.

В этой версии мы приняли на вооружение классическую модель навигации от Apple HIG (Human Interface Guidelines) нижний TabBar.





Переходя к этой версии, мы накопили много негативного опыта использования классической архитектуры MVC от Apple.

Наша команда росла, и нужен был низкий порог вхождения в проект новых сотрудников.
Плюс ещё один момент не давал нам покоя: модульное тестирование поведения графических элементов, для которого использовалось тестирование через UI Test от Xcode, что представляло собой долгий процесс запуска приложения на эмуляторе (устройстве) с эмуляцией пользовательских действий.

Все эти требования вылились в использование нового архитектурного подхода – VIPER.
Классическая модель VIPER:



Но, просмотрев множество подходов в реализации VIPER для iOS, мы остановились на решении Rambler&Co со своими отступлениями.

За основу мы положили книгу от Rambler&Co.



Основные задачи, которые нам помог решить VIPER:

• разбиение крупных классов (Massive View Controllers) с более-менее четко определенными границами ответственности;
• применение принципов SOLID во всей их красе;
• низкий порог вхождения в проект новых сотрудников;
• модульное тестирование UI.

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

Как стал выглядеть наш проект:



Структура VIPER-модуля в нашей реализации:

1. Самый «главный» – класс Module, он знает всё обо всех, создаёт объекты сервисов, необходимых для Interactor, умеет связывать все части между собой View, Router, Presenter и др.



Также он обуславливает связь с другими VIPER-модулями через протоколы входа и выхода ModuleInput и ModuleOutput.

Подобные протоколы входа и выхода имеют все части VIPER-модуля (View, Router, Presenter и др.).

Мы пошли на соглашение: если в протоколах или частях VIPER-модуля нет необходимости, мы их не используем и не резервируем под них пустые классы.

2. Интеракторы (Interactor) – скрывают в себе бизнес-логику.

Мы ввели дополнительный слой сервисов. Сервис – объект, отвечающий за работу со своим определенным типом данных. Например, сервис справочной системы отвечает за справочники (файлы соглашений, реквизитов и т. п.)

3. Presenter – получает от View информацию о действиях пользователя и преображает ее в запросы к Router, Interactor, а также получает данные от Interactor, подготавливает их и отправляет View для отображения.

4. Router – отвечает за навигацию между модулями.

5. View – отвечает за отображение данных на экране и оповещает Presenter о действиях пользователя. Пассивен, сам никогда не запрашивает данные, только получает их от Presenter.

Наши модули могут быть составными.

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

Все эти части независимы и могут жить своей жизнью – имеют собственное API с сервером банка, имеют независимые модели данных. Для их отображения на главной странице подготавливаются контейнеры (Parent View), куда эти виджеты (View) и вставляются.





Наше мобильное приложение под iOS постоянно растёт и развивается. Им пользуется всё больше наших клиентов.




Какие следующие инструменты мы планируем ввести:

• SwiftLint, утилита от разработчиков Realm для автоматической проверки Swift-кода;
• полноценный CI на основе fastlane;
• Полноценное применение Instruments от Xcode(Allocations, Leaks, Zombies и т. п.)

Следите за нашими статьями! До встречи и спасибо за внимание!