Разработка мобильного банка для РайффайзенБанка

    Несколько месяцев назад в App Store и Google Play вышло большое обновление мобильного банка R-Mobile для клиентов РайффайзенБанка.

    Этим проектом команда e-Legion занимается уже более двух лет, и в данном посте мы хотим рассказать о технических особенностях разработки. Наш опыт будет полезен тем, кто хочет писать большие, сложные, долгоживущие и успешно развивающиеся мобильные проекты для реального мира.

    image

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

    Ну а за техническими подробностями просим под кат.

    Веб-сервисы


    Отличительной особенностью данного проекта является то, что взаимодействие с веб-сервисами осуществляется с помощью SOAP. Это было жёсткое ограничение со стороны технической команды заказчика, которое не обсуждалось и с которым надо было как-то жить. Несмотря на ряд недостатков («фе, распухший XML-based протокол в 2014 году»), использование этого протокола в умелых руках способно существенно ускорить реализацию доменной модели, слоя работы с API, а также создание mock-сервисов (о них чуть ниже). А всё дело в том, что для описания SOAP-сервисов существует устоявшийся и общепринятый язык: WSDL.

    В теории, наличие готовых WSDL-файлов (они имелись в наличии и в нашем случае) для веб-сервисов позволяет одной командой (или нажатием кнопки, кому что больше нравится) сгенерировать всё вышеперечисленное и выкинуть из головы заботу о довольно большом куске архитектуры приложения. На практике это тоже возможно, но, в нашем случае, всё далеко не так безоблачно.

    Дело в том, что SOAP — довольно старый протокол, который интенсивно использовался в начала 2000-х, а позже, к моменту, когда распространение получили современные мобильные платформы, он был почти целиком вытеснен более простым и гибким RESTful-подходом. В результате, инструментарий для работы с SOAP и WSDL на сегодня практически весь выглядит довольно устаревшим, а клиентских библиотек и генераторов кода, например, для Cocoa, очень мало. И те, что есть, выдают код довольно сомнительного качества.

    В самом начале мы использовали сервис Sudz-C. На момент старта проекта он был бесплатным и позволил очень быстро получить работающий прототип. Сетевой код, который идёт с ним в комплекте (работает поверх обычного NSURLConnection, без AFNetworking и прочих штучек), пришлось серьёзно переработать, но результат пока всё равно далёк от идеала.

    Позже, при обновлении приложения и добавлении новых классов сервисов и модели, мы напрямую использовали XSLT-шаблоны из исходников Sudz-C, которые мы слегка доработали под себя.

    Для тех, кто сегодня начинает разработку приложения, работающего с SOAP, я бы советовал посмотреть в сторону MWSC/pico. Этот проект использует AFNetworking, и вообще, на первый взгляд, сделан более качественно.

    Доступ к тестовой среде


    Ещё одна особенность проекта — закрытая тестовая среда: служба безопасности заказчика категорически против того, чтобы открывать доступ к сервисам снаружи до того, как они пройдут penetration-тестирование, которое проводится ближе к релизу новой версии. Поскольку головной офис заказчика и тестовая среда находятся в Москве, а наша команда — в Петербурге, то первый год разработки мы работали практически «вслепую». Настоящим спасением стали наличие WSDL и инструмент под названием SoapUI.
    Он позволил нам быстро взвести mock-версию сервисов, отдающую тестовые данные, и разрабатывать, а в дальнейшем и тестировать приложение с помощью него. Такое решение, хоть и далеко от идеального, позволяет отловить в приложении большую часть ошибок, связанных с веб-сервисами.

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

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

    Формы операций


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

    Поскольку «Оплата услуг» была одним из первых видов активных операций в приложении, то с самого начала мы разработали некий внутренний фреймворк для работы с формами, позволяющий строить экранное представление формы из набора объектов, описывающих информацию о полях. Это дало хороший задел для дальнейшей разработки более сложных, но уже статичных (т.е. имеющих заранее известную структуру) форм.

    HTML


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

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

    Безопасность


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

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

    • M2: Insecure Data Storage, выражающийся обычно в кешировании того, чего не надо, и логировании лишней информации, в частности, сетевого трафика (решается применением библиотеки логинга с настройкой уровней логирования; в нашем случае это CocoaLumberjack).
    • M3: Insufficient Transport Layer Protection, выражающийся, например, в том, что выключенную на стейжинге проверку соответствия сертификата домену забыли включить для релизной сборки.
    • M9: Improper Session Handling, для защиты от которого хорошо бы инвалидировать сессию после смены IP разумного периода неактивности либо просто по истечении какого-то времени.

    Остальные риски к нам либо оказались слабо применимы, либо касались серверной стороны.

    Заключение


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

    Мы будем благодарны за ваш пользовательский фидбэк, который вы можете оставить в виде комментариев ниже либо на странице описания проекта.
    e-Legion
    Делаем приложения, которыми пользуются миллионы

    Similar posts

    Comments 30

      0
      Я правильно понял, что это веб приложение для мобильных платформ?
        +2
        В разделе HTML описывается что калькуляторы остались в виде страниц с сайта банка, т.е. всё таки делалось нативное приложение с встроенным браузером для некоторых разделов.
        +1
        Мне всегда было интересно, почему райфф прячет свой бесплатный номер 8-800, а предлагает звонить на 495. Уж не жлобятся ли они. Вот и в вашем приложении…
          0
          Только что проверил — при нажатии кнопки «звонок в банк» высветилось уведомление о том, что мое устройство не умеет звонить (айпод) но номер в заголовке уведомления был +7-800-700-9-100
            0
            В андроиде 495
              0
              Зависит от города, вероятно?
          +8
          Банкоматы ищет только свои, родные. На сколько я знаю у райфа можно без комиссии снимать нал в некоторых других банкоматах партнеров. Вот было бы здорово, если бы приложение показывало в т.ч. и их на карте.
            +1
            Партнерские банкоматы появятся в ближайшем обновлении приложения. Ждать осталось недолго.
            0
            Какова причина того, что через приложение нельзя делать валютный перевод за границу? Для меня это единственный юзкейс для мобильного банка райффайзена, поэтому приходится использовать ПК версию, а не установленную на айподе.
              0
              Мы не могли сразу реализовать весь функционал интернет-банка в мобильном приложении, иначе разработка растянулась бы на многие месяцы и даже годы. Наша конечная цель — полная идентичность набора функционалов интернет-банка и мобильного приложения, поэтому валютные переводы обязательно появятся в последнем.
              +1
              Вопрос из ВК: Какой смысл в привязке мобильного телефона к приложению по смс-коду?
                +2
                Почему дизайн такой шестерочный? Градиенты на нав баре, кнопках, объем, и т.д.
                  –2
                  на куче стоковых иконках в iOS7 тоже присутствуют градиенты.
                  +1
                  Вписываешь в поиске App Store «Райффайзен банк» и получаешь только одно приложение, какое-то не то и старое. Скажите там кому-нибудь, чтоб keywords пофиксили.
                    0
                    Спасибо, глянем.
                    +2
                    С какой целью сделан принудительный разворот в вертикальный режим?
                    Например, у меня планшет в машине всегда закреплен горизонтально. Получается, чтобы воспользоваться приложением, мне надо его будет выстаскивать и брать на руки. Это неудобно.

                    Вывод: приложение хоть и запустилось (предыдущее не запускалось даже), проще и дальше пользоваться сайтом.
                      0
                      А для Windows Phone планируется версия?
                        0
                        Не можем ответить на этот вопрос, но пожелания собираем :-)
                          +1
                          На данный момент версия для Windows Phone находится в стадии оценки.
                          +1
                          Сделать короткий пароль — заказчик не позволяет?
                            0
                            Это вопрос обеспечения достаточного уровня безопасности для подобного вида авторизации клиента. Как только мы его (уровень безопасности) обеспечим — короткий пароль будет внедрен. Работы в этом направлении уже ведутся и внедрение не за горами.
                            +1
                            Тот самый R, который делал Id-east и теперь делает e-Legion, по некоторым причинам…
                              +1
                              Зачем вы каждый раз подгружаете карту банкоматов по новой. Может быть стоит хотя бы частично кешировать или проверять when changed?
                                +1
                                У вас для кредитных карт неверно указывается льготный период.
                                Открываю веб-версию: 07.06.2014 — 06.07.2014 (верно)
                                Открываю приложение: 07.07.2014 — 06.08.2014 (не верно)
                                  0
                                  спасибо, глянем.
                                    0
                                    Два месяца прошло, воз и ныне там.
                                  0
                                  Отличное приложение, я очень им доволен. Спасибо!

                                  Поймал, правда, какое-то время назад багу, но так и не зарепортил. Но раз уж такое дело, то:

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

                                  +7 (___) ___-__-__

                                  При сохранении на сервер, цифра «7» в начале номера не сохранялась, и смс не доходили.


                                  Забавно, но в веб-интерфейсе это исправить нельзя, в приложении тоже, и только банкомат спас меня от похода в отделение банка.
                                    0
                                    Спасибо! Проверим.
                                    +1
                                    Скажите, а зачем нужно каждый раз вводить логин? Нельзя ли его как-то сохранить? Я понимаю этот кейс для десктопа, но для мобилы…
                                      –1
                                      Наверно пост надо назвать «Известные нюансы взаимодействия с SOAP свервсами из Obj-С (ps: и у нас динамические формы)»
                                      О чём пост, о том что есть приложение?

                                      Only users with full accounts can post comments. Log in, please.