Как создать банковское приложение

Обновлено: 25.04.2024

Концепт был разработан в рамках тестового задания для банка X.

Основной задачей проекта является — разработка мобильного приложения для отправки денег от одного физ. лица другому.

Какие же цели могу быть.

Ускорить и упростить процесс перевода денежных средств с карты на карту,
Повысить лояльность своей аудитории
Привлечь новых клиентов банка
Сделать возможность перевода максимально удобной и мобильной
Увеличить оборот проведения средств по карте
Изменить стереотипное понимание о том, что перевод с карты одного банка на карту другого банка — очень денежно-затратный процесс в плане снятия доп. комиссий
Имея карту другого банка, пользоваться приложением ПСБ
Дать возможность пользователю, у которого есть карты нескольких банков переводить средства с одного приложения
Продвигать банковский продукт — карты

Посмотрим на прямых конкурентов нашему будущему приложению и узнаем, какие интересные фичи уже существуют на рынке. Рассмотрим приложения на Android.

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

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

В меню присутствует тех поддержка , рубрика вопрос — ответ и информация о комиссиях и лимитах. Авторизация принудительная, но занимает минимальное время. Есть возможность сохранять информацию в шаблонах.

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

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

После окончания выбора и создания пароля для приложения, я попадаю на главный экран и вижу подсказки — приятно.

Приложение показывает какие у меня есть скидки при оплате их виртуальной картой и какие переводы денег я могу совершать.Так же есть возможность запросить деньги. Вводишь номер своей карты и способ через который ты хочешь запросить средства — Смс, почта, чаты, мессенджеры и тд.

В начале приложение рассказывает нам обо всех преимуществах пользования. Обращение с деньгами представляется в 2 видах — запросить или перевести.

Если я хочу перевести деньги, то автоматически получаю выборку по всем странам. После чего, вводя необходимую сумму, я получаю конвертацию в местную валюту и снимаемую комиссию за перевод.

Эти данные основаны на реальных отзывах Ца, использующие эти приложения. Отзывы из Play Маркет от Google

Быстрота
Простота
Удобство
Поддержка карт любых банков
Поддержка всех платежных систем
Возможность иностранных переводов
Надежность и сохранность перевода
Минимальный размер комиссии
Безопасность приложения от взлома
Оперативность поддержки

Просмотрев данные приложения, были выявлены следующие особенности, объединяющие данные приложения. Выявлена приоритетность функционала и разбита по блокам.

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

1) Авторизация и подтверждение через push-уведомление
2) На первом/главном экране возможность перевода с карты на карту
3) Преимущества при первом запуске приложения
4) Перевод денег по номеру телефона, а так же иностранные переводы
5) История переводов
6) Шаблоны операций
7) Защита при помощи пин кода или отпечатком пальца
8) Добавить карту при помощи сканирования
9) Производить аналитику расходов по карте
10) Возможность посмотреть и заказать банковский продукт через приложение

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

Сколько времени нужно, чтобы сделать крутое банковское приложение?
Чтобы это узнать, мы взяли статистику Finextra: на создание полноценного мобильного банка нужно до года. И 5% компаний успевают это сделать за 3 месяца. Нам удалось попасть в эти 5% и сделать топовое банковское приложение.

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

Исходные данные

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

Задача

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

Дополнительные условия

Каркас приложения уже есть, поэтому нужно быстро разобраться в существующем коде и переработать архитектуру;
Мы начали работу в составе трех команд: одни работали над дизайном, мы — над приложением, третья команда — над серверной частью. Скорость разработки и интеграции приложения зависели от разработчиков сервера;
Координация 3 распределенных команд в условиях жестких сроков — верх искусства. Работа идет медленнее, чем могла бы.

Компоненты успешной разработки

Product owner (Владелец продукта)

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

Слаженная команда

На проект подключилась команда разработчиков, не раз работавших вместе. Такая команда работает быстрее: разработчики легко читают код друг друга, знают сильные и слабые стороны друг друга и в зависимости от этого распределяют задачи. Им не надо тратить время на знакомство и адаптацию;
Идеально, если одна команда делает клиентскую и серверную части. Мы поначалу делали только клиентскую часть, и нам приходилось ждать сервер. Когда сроки начали поджимать, мы подключились и к бекенду. С этого момента можно было легко уточнять информацию у коллег и быстрее интегрировать готовый функционал;
Готовность клиента и разработки к расширению команды, если это помогает ускорить разработку.

Ринат и Марина: вместе тимлидят уже третий проект.

iOS и Android вместе

Мы объединили общение Android и iOS разработчиков. Одно из извечных противостояний стоит отложить, когда делаешь классный продукт для обеих платформ. Разработчики помогают друг другу: ошибки, которые возникли в ходе разработки одной версии не всплывут в другой, или если одна версия обгоняет другую, то “отстающие” быстрее подтянутся с помощью коллег с другой платформы.

ТЗ в Google doc

Когда ритм работы высок, а требования меняются несколько раз в день, мы воспользовались Google документами. Ведение задач в системах типа Jira или Youtrack хороши, когда все планомерно, но в наших условиях они были не удобны. Команда видела замечания и новые требования по каждому экрану в одном документе и моментально реагировала на изменения.
Позже, после релиза, мы переехали на YouTrack, но когда нужно было сделать быстро, возвращались в Google док.

Видео новых функций

Когда дизайн делается по ходу разработки, не все детали UX можно учесть сразу. На скриншотах не всегда понятно, будет ли пользователю удобно.
После добавления новой функции, команда записывала видео экрана с изменениями и отправляла юзабилисту и product owner’у. Они сразу вносили правки, когда было нужно.
Были случаи, когда неудобство функций было видно не сразу, трансляция отдельных этапов дала возможность незамедлительно исправлять такие моменты, а не ждать общей демонстрации.

Например, мы добавили в приложение поиск организаций через сервис dadata. Приложение показывает метки надежности организаций: зеленый - надежный контрагент; желтый - сомнительный; красный - есть риски при работе с контрагентом.

В дизайне не было экранов поиска компаний. Разработчик спроектировал их и снял, как они будут отображаться. Product owner решал, что можно улучшить.

Эти составляющие помогли нам доработать и выпустить приложение за 3 месяца. Важно собрать все компоненты успеха вместе и выстроить единый процесс работы, чтобы получить на выходе достойный результат. По итогам 2017 года созданный нами мобильный банк занял 4-ю строчку в рейтинге эффективности мобильных банков для малого бизнеса.

Мы продолжаем улучшать приложение, чтобы оно приносило еще больше пользы нашим партнерам и их клиентам.

Весной 2017 года мы выпустили новое мобильное приложение «РосЕвроБанка». О вызовах, с которыми пришлось столкнуться двум командам — Redmadrobot и «РосЕвроБанка» — в процессе разработки, тестирования и внедрения мобильного продукта, рассказываем в нашем очередном кейсе. Итак, «Мобильный РосЕвроБанк: behind the scenes».

К моменту, когда к нам обратился «РосЕвроБанк», мы уже сделали несколько мобильных банковских продуктов: приложения банка “Открытие”, финансовой группы “Лайф” и др. И хорошо представляли себе всю “кухню” — процессы, правила, потребности операторов финансовых услуг, поэтому приступить к разработке смогли очень оперативно.

Артем Гребнев, Product owner, «РосЕвроБанк»
«В начале 2016 года мы собрали внутрибанковскую команду для работы над проектом и стали экспериментировать. К середине года стало окончательно ясно: писать мобильную версию на базе существующих у нас решений нерационально, нужно все переделать с самого начала, и сделать это должен грамотный, подготовленный, с опытом работы с банковским ПО разработчик. Мы изучали рынок, приглашали несколько команд — было открытое предложение, могли участвовать все желающие, но у нас были четкие критерии отбора: во-первых, выделенная команда разработки, во-вторых, плотное взаимодействие вплоть до «высадки» команды разработки непосредственно в офис банка, если это поможет ускорить работу. Рассмотрев все предложения, мы признали, что именно Redmadrobot наилучшим образом соответствует нашим ожиданиям».

В августе 2016 года банк передал нам подробнейшее ТЗ на 64 страницах: в нем содержалось все то, что клиент хотел видеть в будущем приложении. Эти ожидания от продукта нам пришлось совместно корректировать. ТЗ «РосЕвроБанка», в сущности, состояло из трех функциональных блоков: качественный сервис для существующих клиентов, дополнительный сервис вроде электронного кошелька для не-клиентов и платежный агрегатор для любых операций. Все блоки правильные, но их реализация — это огромное количество работы и очень длинный time-to-market: минимум год-два разработки, а за это время — потеря аудитории и огромное отставание от лидеров отрасли. Поэтому мы предложили банку подход, который часто используется на рынке мобильных приложений и FinTech-продуктов: выпуск в стор первой версии приложения с минимальным функционалом за 6-8 месяцев, а затем планомерное развитие продукта.

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

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

Что умеет приложение

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

Алиса Морозова, менеджер проекта, Redmadrobot
«Все, что связано с банковскими продуктами, у нас собрано на одном экране — счета, кредиты, карты «РосЕвроБанка» и других банков. Можно сразу понять, что у тебя сейчас с деньгами, можно легко перекидывать их туда-сюда».

Внешняя привязанная карта позволяет делать платежи, бесплатно пополнять баланс карт «РосЕвроБанка» и совершать переводы с нее на любые другие карты. Между картами других банков можно совершать переводы с комиссией всего 1%. Для операций с внешними привязанными картами нужно только вводить их CVV/CVC коды.

Для платежей выделена отдельная вкладка и реализовано несколько типов умных автоплатежей. Первый — регулярный: указывается сумма и периодичность переводов, можно настроить ограничения — выполнять до определенной даты или указанного количества переводов.

Второй вид автоплатежей — нерегулярные переводы по факту наступления события: оплата налогов, штрафов, ЖКХ. Здесь можно настроить оплату с лимитом каждой операции и общим лимитом в месяц (например, оплачивать штрафы до 500 рублей автоматом, но не более пяти раз в месяц).

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

Архитектура системы

Как устроена архитектура банка? Есть Business Process Enterprise Layer (BPEL), где можно быстро реализовывать бизнес-логику обработки всех процессов на основе действующих и разрабатываемых сервисов в формате WSDL. Мобильное приложение смотрит на middle-прослойку, та смотрит на BPEL, а BPEL общается со всеми банковскими системами через WSDL через шину.

Middle-прослойка выполняет функцию CMS и одновременно производит трансформацию JSON в WSDL, так как все внутренние сервисы работают с WSDL, а мобильное приложение адаптировано под работу с JSON.

Плюс в ней же хранятся все данные для контента приложения: иконки платежей, логотипы, цветовые схемы и т.д. Например, начинаем добавлять карту «Сбербанка», и после ввода первых цифр номера, фон карты меняется на зеленый цвет. А при оплате МТС фон подсветится красным. Все эти цветовые схемы, логотипы и иной контент хранится как раз в прослойке.

Middle-прослойка — часть работающей наружу DMZ, в которую также вынесены сайт банка и «Виртуальный Офис» (интернет-банк). За DMZ находится основная сеть банка, где работают все остальные системы. Именно там расположен слой бизнес-логики мобильного приложения, который принимает и обрабатывает запросы исключительно от прослойки.

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

Алексей Щербаков, IT-руководитель «цифрового банка», «РосЕвроБанк»
«Сейчас мы и веб-приложение переделываем под эту же схему с контент-прослойкой. Ранее оно использовало собственную контент-систему и общалось через WSDL c BPEL. Но на мобильном приложении мы успешно опробовали смену архитектурного подхода, и теперь веб- и мобильное приложения будут синхронизированы и по функциональности, и с архитектурной точки зрения. Унификация упростит дальнейшее развитие банка: любой новый продукт мы можем быстро вывести на все доступные digital-каналы – web, mob, sms, ussd и так далее».

Дмитрий Корчмарек, тим-лид разработки, «РосЕвроБанк»
«Когда мы делали для банка веб-приложение, времени на него ушло гораздо больше — это был огромный проект с множеством требований, для него создавалось много новых систем. Несколько месяцев заняли только подготовительные процессы по реализации API всех систем и началу интеграции, плюс еще несколько месяцев – сама интеграция. Но зато нам удалось объединить все эти системы с точки зрения пользовательской, а не банковской логики. В результате на мобильной версии процесс разработки нового API и нового функционала пошел в очень агрессивном темпе. Нам понадобилось только верхнеуровневое бизнес-требование к мобильной версии, и с помощью Redmadrobot мы всего за несколько месяцев подготовили для него API. Оно получилось не таким уж идеальным, чистым и прозрачным, как хотелось бы (там одних спецификаций 117 страниц, из которых 17 – история изменений), но сама архитектура позволяет нам разрабатывать и внедрять новые функции, не затрагивающие текущую реализацию, на «боевой» сервер прямо на ходу».

iOS-версия приложения писалась на Swift. У нас в Redmadrobot много собственных библиотек – для транспортного уровня, баз данных и так далее, что здорово экономит время.

Ольга Ворона, iOS-разработчик Redmadrobot
«Мы стремимся работать внутри всех проектов компании в одной парадигме, и наш главный архитектор продвигает слоистую архитектуру. Большие слои – сервисный уровень и UI. Сервисный уровень включает транспорт, работу с базой данных, и все это разбивается на отдельные сервисы. Подробно об уровне бизнес-логики можно почитать здесь. Когда-то мы использовали MVVM (Model, View, ViewModel), потом MVPM (Model, View, PresentationModel), сейчас для навигации мы используем Router. Стараемся как можно меньше оставлять во ViewController, больше выносим в PresentationModel. Presentation берет модели из сервисного уровня и создает из них набор ViewModel. View Controller использует эти ViewModel для конфигурации View, которые пользователь видит на экране. Router же мы используем во ViewController’ах для перехода между сценариями или внутри сценария».

Банковские нюансы

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

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

Дизайн

Банк был настроен на лаконичный и легкий дизайн, поэтому мы использовали минимум графики, крупные шрифты, простую цветовую гамму.

Татьяна Гущина, дизайнер, Redmadrobot
«Для ускорения разработки максимально применялись стандартные элементы дизайна, разбавленные интересными анимациями. Их задача — дать пользователю обратную связь при выполнении медленных операций, например, загрузке больших массивов данных. Поначалу у нас были только Refresh и Activity Indicator, блокирующий весь экран. Но из-за специфики запросов — их может быть несколько на одном экране, и при прокрутке это должно отображаться — мы отрисовали еще и Loader. Еще одна тема возникла с главным экраном: поскольку в приложении ничего не кэшируется из соображений безопасности, при загрузке экран оставался пустым. Это нарушало ожидания пользователей, и мы добавили специальный промежуточный экран, имитирующий основной, на котором идет процесс загрузки».

Коммуникация в двух командах

Виталий Пальчиков, product manager, «РосЕвроБанк»
«Внутри банка у нас комфортная экосистема взаимодействия между подразделениями: внутрикорпоративный чат, внутренний файлообменник, система управления проектами. Сложность данного проекта состояла, во-первых, в работе распределенной командой, состоящей, с одной стороны, из администраторов, менеджеров, разработчиков и тестировщиков на стороне банка, с другой – «внешней» для экосистемы банка команды. Во-вторых, вызовом для нас был короткий срок запуска проекта. Мы не стали изобретать колесо — чат в WhatsApp из 15-20 людей был экстремальным, но работающим решением :)

Было сложно: наши “центры компетенций” развивались на лету, до проекта у нас не было острой нужды в QA, и первое время приходилось лично проверять API наших разработчиков на соответствие спецификации; в рамках тестирования мобильного приложения “снифать” трафик; сравнивать ответ бэка и поведение приложения. А после выпуска приложения — самостоятельно обрабатывать приходящие обращения клиентов, формировать FAQ-базу с предзаготовленными скриптами для передачи функционала обратно на первую линию, пока доработки еще не были реализованы. Нагрузка на менеджеров проектов со стороны обеих команд возросла в разы, но все отлично справились со сложностями».

Командное общение в чате позволило выстроить эффективную коммуникацию по проекту 24/7. В результате общение разработчиков двух команд не замыкалось на администраторе проекта, и между ними выстроилось полноценное, очень тесное взаимодействие.

Мы могли в десять вечера сообщить, что вызов метода дал сбой, в банке оперативно связывались с дежурным админом, узнавали, что сейчас внепланово накатывается срочное обновление, и тут же отвечали “подождите 10 минут, и все заработает”. А не так, что метод не принимается, в Jira заводится баг, и банк реагирует на него на следующий рабочий день. Это существенно ускорило разработку и дало возможность программистам работать в удобное для них время.

По необходимости «РосЕвроБанк» подключал к чату специалистов, отвечающих за те или иные части банковского бэкенда, мы добавляли тестировщиков, и все вопросы решались оперативно. Даже о запуске проекта все члены команды узнали из чата :)

Что в итоге

Для нас в Redmadrobot самым важным было правильно выстроить работу с банком. Каким бы продвинутым он ни был — это все же массивная структура, и даже для обособленного диджитал-банка требуются многочисленные согласования и проверки. Серьезное достижение — то, что мы научились работать с такими заказчиками и одновременно научили их работать с тем, как мы делаем архитектуру, дизайн, пишем, проверяем и тестируем системы.

На сегодняшний день мы закрыли примерно 90% доступного в backend банка функционала, и мобильное приложение по возможностям уже обгоняет веб-кабинет банка. Пока мы писали статью, уже реализовали возможность открытия счетов, регистрации нерезидентов, графические отчеты по использованию средств на картах и управление карточными лимитами. Из планов на ближайшее будущее — перевод клиенту банка по номеру телефона, подключение опций – кешбеки, накопительные проценты и смс-информирование, конвертация, чат с операторами и многое другое.

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

Если вы все еще сомневаетесь в разработке приложения для мобильного банкинга, позвольте нам убедить вас в этом:

Доступ 24/7
Легкий просмотр истории транзакций
Высокий уровень безопасности
Оплата счетов в один клик
Легко переводить деньги
Выплата кредитов онлайн

Финансовые учреждения, в свою очередь, тоже получают огромную пользу, внедряя мобильные приложения:

Снижение операционных расходов
Повышение качества обслуживания клиентов
Хорошая окупаемость инвестиций (ROI)
Персонализированные услуги благодаря аналитике данных (на основе искусственного интеллекта)
Использование современных технологий

Тенденции развития мобильного банкинга демонстрируют безумные амбиции, которые приводит к росту и развитию. Статистика показывает, что к концу 2021 года количество пользователей мобильных устройств составит 7 миллиардов, из которых 3 миллиарда перейдут на мобильный банкинг.

К мировым лидерам, которые изменили правила игры в банковской сфере, относятся Citibank, Wells Fargo, USAA, Ally Bank и Capital One. PayPal -- наиболее часто используемое приложение для проведения мобильных платежей (73%), а Samsung Pay - наименее используемым (6%).

По данным одной из крупнейших в мире британской аудиторско-консалтинговая компания Ernst & Young», 50% потребителей переходят на цифровые технологии при подаче заявки на получение финансовых продуктов. На самом деле, по данным Statista, к концу 2021 года транзакции мобильных платежей достигнут отметки в 189,97 млрд долларов. И это неудивительно, так как из-за пандемии COVID-19 55% людей перейдут на бесконтактный способ оплаты.

Исследование одного мобильного банкинга, проведенное научным центром Insider Intelligence, показало, что 89% всех респондентов - и 97% представителей поколения миллениалов заявили, что использовали мобильный банкинг. Но не только молодое поколение доверяет технологиям веб-банкинга: 91% представителей поколения X и 79% бэби-бумеров отмечают преимущества цифрового банкинга.

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

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

Убедитесь, что клиенты могут обращаться к менеджерам службы поддержки 24/7 для решения своих проблем. Лучшее решение -- чат-бот на основе искусственного интеллекта.

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

Всегда хорошо держать свою финансовую ситуацию под контролем. Помогите людям придерживаться своего бюджета и тем самым, сэкономить больше денег.

Прогнозируется, что в 2022 мобильная электронная коммерция достигнет 3,5 триллиона долларов и составит 72,9% продаж всей электронной коммерции. А кэшбэк побудит пользователей банка совершать платежи в приложении, и станет частью вашей программы лояльности.

Функция разделения счетов позволяет разделить счета и определить их стоимость с точностью до цента.

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

Недавно мы закончили разработку приложения для мобильного интернет-банкинга под ОС «Аврора» — единственную российскую мобильную операционную систему. Всего за пару месяцев мы создали приложение, которое дает доступ ко всем основным услугам банка ВТБ. Через приложение можно оплачивать покупки и услуги, делать переводы на карты и счета, использовать шаблоны платежей и многое другое. В этом посте мы поделимся историей создания приложения и расскажем об особенностях разработки для отечественной мобильной операционной системы.

Что нужно знать о разработке под «Аврору»

Мы решили сделать мобильное приложение для банка на ОС Аврора, ничего не меняя в бэкенде и используя существующий протокол. Разработку вели в формате форсайт-проекта, а это накладывало жесткие ограничения и на сроки (не более 3–4 месяцев), и на бюджет.
Для разработки приложений создатели платформы предоставляют SDK (Software development kit). В этот набор входят:

Интегрированная среда на основе Qt Creator — кроссплатформенной свободной IDE для разработки на С, С++ и QML. В ней есть редактор кода, дизайнер и отладчик.
Build Engine — инструмент для сборки приложений, в том числе разработки проектов под архитектуры i486 и armv7hl. Является виртуальной машиной на базе Oracle VirtualBox.
Эмулятор Sailfish OS c полнофункциональной сборкой этой системы внутри — тоже виртуальная машина на базе Oracle VirtualBox.
Примеры, руководства и документация к API.

Модуль Qt QML определяет и реализует язык QML — декларативный язык программирования, основанный на JavaScript. В модуле есть механизм преобразования QML в классы Qt, что дает возможность описывать пользовательские интерфейсы. Для разработки под Sailfish OS можно использовать как C++, так и Python, что особенно удобно для приложений со скромными требованиями к ресурсам.

В составе Sailfish OS SDK есть Sailfish Silica — модуль, содержащий компоненты QML, специфичные для данной платформы: они выглядят и управляются по стандартам приложений для Sailfish OS. Использование этих компонентов затрудняет последующее портирование разработанных приложений на другие платформы. Например, при разработке Android-приложений на Qt используются компоненты QtQuick.Controls, которые не поддерживаются Sailfish. Компоненты Silica, в свою очередь, не поддерживаются на Android.

Информация о стандартных размерах, шрифтах, отступах, цветах и других составляющих стиля для приложений на платформе Sailfish содержится в компоненте Theme библиотеки Silica. Кроме того, в ОС есть список предустановленных «атмосфер», которые определяют внешний вид и поведение приложения: фоновую картинку, цветовую и звуковую схемы.

Большинство современных мобильных устройств оснащены датчиками: ориентации, освещения, вращения, угла наклона, близости, напряженности магнитного поля, акселерометром и прочими. В ОС Аврора для работы с ними предусмотрен Qt Sensors API. В качестве хранилища данных на устройстве выступает база SQLite. Доступ к данным из QML обеспечивает библиотека LocalStorage.

Доступ к геолокационной информации предоставляют стандартные классы фреймворка Qt. Для работы с локацией используются модули Qt Positioning и Qt Location. За отправку и обработку сетевых запросов отвечают библиотеки Qt Network и Qt WebSockets, которые содержат все необходимые для этого классы.

Типовая архитектура приложения

Использование шаблонов программирования MVC (Model-View-Controller) — один из наиболее распространенных и эффективных приемов проектирования приложений. Вариация данного подхода — шаблон Model-View — есть и в Qt.

Архитектура «модель/представление» все еще отделяет способ хранения данных от способа их представления пользователю, но обеспечивает простую структуру, основанную на тех же принципах, что и MVC.

Здесь модель отвечает за данные и доступ к ним. Поскольку в графическом интерфейсе за отображение элементов и получение ввода от пользователя нередко отвечают одни и те же элементы, идея объединить представление и контроллер выглядит логичной.

Именно так и работает Qt: представление не только отображает данные, но и выполняет функции контроля, а также отвечает за взаимодействие с пользователем. Чтобы при этом не потерять гибкость, ввели понятие делегата. Делегат позволяет определять, как эти данные будут отображаться и как пользователь может их изменять. Представление фактически превращается в контейнер для экземпляров делегата.

Для взаимодействия друг с другом модели, представления и делегаты используют сигналы и слоты:

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

Особенности дизайна: не потерять индивидуальность в «Авроре»

Разработку приложения «Мобильный банк ВТБ» для ОС «Аврора» начали с определения его внешнего вида. Уже на этом этапе особенности ОС заставили нас отойти от привычного подхода. Оказалось, что применить в приложении под «Аврору» корпоративный стиль ВТБ — фирменные цвета, шрифты, логотипы и другие элементы дизайна — проблематично.

Во-первых, в ОС «Аврора» все элементы экрана, как и сам экран (page) имеют полупрозрачный фон, который не всегда можно переопределить. К примеру, такой элемент, как Button, не имеет подобного свойства (правда, начиная с версии 3.1.* появился способ управления отрисовкой). С помощью Rectangle + MouseArea можно нарисовать собственные элементы, но это уже идет вразрез с концепцией стиля приложений для ОС Аврора.

Во-вторых, цвет шрифта, различных акцентов и фона, а также размеры элементов в приложении определяет так называемая «атмосфера» — тема экрана телефона в ОС «Аврора». Можно пользоваться одной из предустановленных в телефоне атмосфер или настроить собственную кастомную тему.

Данные особенности позволяют сэкономить время на разработку, при этом приложение выглядит хорошо на любом устройстве. Но как не потерять корпоративные цвета? Приложений для ОС «Аврора» не так много, тем более с мобильным банком, «подсмотреть» не у кого. В итоге решили оставить прозрачность и не отходить от стиля Авроры, а для придания индивидуальности разместить логотип ВТБ на каждом экране приложения.

В ОС «Аврора» имеется множество готовых UI-элементов, в том числе и новые для пользователя, например, вытягиваемые меню. Они отображаются на экране в виде подсвечиваемой полоски. Для вызова необходимо потянуть экран вниз (PullDownMenu) или вверх (PushUpMenu).

Тем не менее для навигации между не связанными друг с другом экранами нам не хватало элемента вроде Bottom Navigation Bar в Android или iOS. Придумывать другой тип навигации не хотелось, и мы сделали похожий компонент. Он переключает экраны «Главный», «Продукты», «Платежи», «Витрина» и «Прочее».

Реализация протокола взаимодействия с сервером

Для работы с этим протоколом в Qt мы не нашли готовой библиотеки, пришлось писать свой парсер объектов. В теле НТTP-запроса и респонса Burlap может использовать указатели (refs) на объекты, которые уже описаны внутри XML. Чтобы номер указателя считывался верно, нужно десериализовывать всю иерархию получаемых объектов. В противном случае счетчик ссылок слетает, по нему подтягивается не то, что нужно.

Отлаживали парсер долго: в процессе разработки возникали новые типы объектов, указатели на коллекции и т. д. Реализовав поддержку Burlap в Qt, мы приступили к реализации прикладного протокола.

Особенности прикладного протокола для выполнения операций

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

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

Чтобы обеспечить всю эту функциональность, мы разработали механизм динамического создания UI-элементов. Набор типов UI-элементов, возвращаемых сервером, был обширным. Для каждого типа или набора типов мы создали отдельный QML-класс со своим перечнем свойств. Получилось несколько десятков таких классов. Кроме того, для каждого этапа проведения операции вызывается скрипт создания этих самых элементов, формируя контент экрана.

Сочетание QML и JS оказалось удобным и гибким. В ОС «Аврора» многое реализовано проще, чем в Android или iOS.

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

Геолокация и карта

Для удобства пользователя мы хотели добавить в приложение экран с картой местности, на которой отмечены банкоматы. Привычных для Android и iOS разработчиков API для работы с картами, таких как Google Map или Яндекс.Карты, Sailfish OS не использует.

Источники данных карты и другой полезной информации — плагины, которые предоставляют создатели платформы и независимые разработчики. Для ОС Аврора доступны два плагина: OpenStreetMap и HERE WeGo. Мы использовали OpenStreetMap, поскольку HERE WeGo требовал получения API key.

Для геолокации фреймворк Qt предоставляет два модуля: Qt Positioning и Qt Location. Первая подсистема дает возможность получить информацию о текущем местоположении устройства, а вторая предоставляет средства для геокодирования и отображения этой информации на карте.
Эти плагины и библиотеки позволили нам отобразить экран с картой и всеми добавленными банкоматами. Но поначалу текущая геолокация определилась неправильно: мы находились в московском офисе у станции метро «Павелецкая», а на экране значилась Сенатская площадь – значение по умолчанию.

Выяснилось, что причиной ошибки было отсутствие в телефоне сим-карты. В таких случаях часто выполняется холодный старт датчиков GPS — процесс, который занимает приличное время. Вероятно, и сам датчик был не самым мощным: использовался аппарат INOI R7. Спустя 10–15 минут локация все же определилась, хотя и с погрешностью. Возможно, в «чистом поле» координаты определяются лучше.

Сборка проекта

Для работы с Qt Creator мы использовали рабочие станции Windows. Поначалу все шло гладко, но после обновления Sailfish SDK с версии 2.1.1. на 2.2.4 сборка приложения стала выполняться в разы дольше. Мы обратились к разработчикам ОМП и выяснили, что проблема связана с задержками выполнения команд сборки IDE на ВМ Build Engine и подключения к ней. В среднем только подключение по SSH к ВМ занимало около 50–60 секунд, при этом проверка соединения из IDE к ВМ проходила за доли секунды.

Проблему можно было решить, если делать сборку непосредственно на ВМ с Build Engine без использования IDE. Но нам нужно было не только собирать, но и отлаживать приложение, а без IDE это очень медленно и неудобно. Пришлось перейти на Linux, где проблема была не столь критичной.

Результаты

Мы получили рабочее приложение. Пока оно не идеально, и нам есть над чем работать:

Сделать удобный вход в приложение. Сейчас для этого используется СМС-код;
Сделать приложение полнофункциональным и ускорить его работу;
Использовать преимущества ОС «Аврора»: SSL на основе шифрования ГОСТ 28147-89 и усиленной электронной подписи.

Спасибо компании «Net1 Universal Technologies», которая помогла нам сделать это приложение, и сотрудникам компании «Открытая мобильная платформа» за постоянные консультации и помощь в решении проблем, возникавших в процессе разработки.

Автор статьи

Куприянов Денис Юрьевич

Юрист частного права

Страница автора

Читайте также: