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

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

Это могла бы быть история об очередном продукте в бэклоге, но мы не дали этому случится. Рассказываем, как помогли клиенту довести продукт до ума и сторов.

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

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

Но сегодня это не кажется сильным преимуществом. Можете вспомнить, когда вы последний раз платили за ЖКУ, открывая специальный сайт и вводя данные квитанции вручную? Нет? Это неудивительно: 77% россиян оплачивают коммуналку через мобильный банк и вы, скорее всего, входите в их число. Ведь достаточно просто отсканировать QR-код, куда зашиты все данные платежки, и не печатать самому.

У ВсеПлатежи не было мобильного приложения — со смартфона пользователи могли заходить только на сайт. Это не всегда удобно, а еще с веб-сайта нельзя было оплатить по QR-коду.

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

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

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

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

Мы должны были:

— Разработать кроссплатформенное приложение для iOS и Android.

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

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

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

Особенность проекта — работа с чужим бэкендом

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

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

Фронтенд отвечает за отображение пользовательского интерфейса и передачу запросов на сервер, а бэкенд — за обработку этих запросов, доступ к данным и отправку ответов. Бэкенд и фронтенд — это как инь и ян в мире разработки, одно без другого невозможно. Но «говорят» они на разных языках, поэтому им нужен переводчик — API. Он обеспечивает корректный обмен данными между фронтендом и бэкендом.

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

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

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

Выбрали стек, который экономит время и бюджет

Мы использовали наш стандартный стек: фреймворк React Native для разработки, библиотеку компонентов Redux Toolkit и библиотеку форм React Hook Form. 

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

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

Фичи приложения: как в вебе, только с QR-кодом

UI/UX был полностью со стороны клиента, поэтому мы отвечали только за разработку фич приложения на фронтенде.

Фичи приложения ВсеПлатежи:

• Авторизация по отпечатку пальца, паролю или Face ID

• Чат службы поддержки с использованием стороннего виджета партнёра «Verbox»

• Оплата по QR-коду

• Доступ к камере устройства, галерее и контактам пользователя

• Оплата через YandexPay, SberPay и СБП

• Оплата корзиной и оплата в один клик без добавления платежа в корзину

• Обновление приложения автоматически или через запрос пользователю

• Push-уведомления о начислениях, автоплатежах и новых сообщениях

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

Коварный QR-код

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

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

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

Возможность оплаты по QR-коду была очень важна для приложения ВсеПлатежи. Мы думали, что сделать эту функцию будет проще простого. Но все оказалось сложнее, чем мы предполагали. 

Для сканера QR-кодов мы использовали библиотеку готовых компонентов react-native-camera-kit. Она подходит для кроссплатформенных приложений, совместима с разными устройствами и у неё высокая производительность. Всё должно было работать, но мы столкнулись с проблемой: сканер не считывал QR-коды. 

Почему это произошло? QR-код платежной квитанции перегружен информацией. В нем зашито много символов, а сам он, как правило, мелкий. Потому сканер не может корректно обработать информацию.

Сейчас будет что-то на языке разработчиков, но вы поймете главное: мы неожиданно нашли решение! 

Один из наших разработчиков сделал обертку нативной библиотеки React Native для совсем другого проекта. Он создал что-то вроде переводчика между JavaScript и нативным кодом, чтобы JavaScript-части приложения могли общаться с нативными (написанными для конкретной операционной системы) функциями и возможностями. Потом можно использовать доступные в нативных библиотеках функции внутри React Native приложения. 

И мы использовали эту обертку для сканера и здесь она работала намного лучше! Сканер научился обрабатывать QR-код. Мы также доработали декодер: улучшили алгоритмы распознавания специальных символов и оптимизировали работу с изображениями.

С бэкендом тоже все было непросто

Помните, мы рассказывали, как в мобильном приложении работает бэкенд? Сейчас вам это пригодится :) 

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

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

Допустим, пользователь хочет оплатить коммуналку. Форма оплаты включает несколько шагов: 

• выбор типа услуги (оплата капремонта, газа)

• ввод реквизитов получателя

• суммы оплаты

• выбор способа оплаты (карта, платежная система) 

• подтверждение операции

Каждый шаг формы меняется в зависимости от предыдущих действий пользователя и условий платежа. Например, если пользователь выбрал оплату капремонта, форма запрашивает ИНН получателя, расчетный счет, БИК банка. Если пользователь укажет что-то неверно или вообще не укажет, форма должна подсказать ему правильный шаг: допустим, что ИНН содержит 10 или 12 символов, а не больше. 

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

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

А еще нужно было принимать с бэкенда определенные шаблоны (их называют регулярные выражения) — они помогают проверить, корректно ли пользователь ввел данные и обработать запрос. 

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

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

Приложение уже доступно в сторах. ВсеПлатежи в Google Play скачали 5+ тыс. пользователей, а его средняя оценка на момент написаний кейса — 4,6. В отзывах пользователи отмечают, что приложение удобное и экономит время. 

Вот что пишет один из пользователей: «Удобно. Для меня замена веб-версии. Плюс сканирование по QR-код появилось. Мне важно, что я могу из истории всегда посмотреть, когда и сколько платил и повторить платеж. А теперь удобно делать это с телефона».