Мобильный софтфон с возможностью WhiteLabel-брендирования: как мы его делали

Недавно мы выступали на Астерконфе — крупнейшем Форуме по Asterisk’у и VoIP’у — где анонсировали долгожданный софтфон для Android и не менее долгожданный софтфон для iOS. А говорили мы вот что.

Кому нужен софтфон для мобилки

Windows и macOS — это офисная экосистема: в этих операционных системах работают секретари, бухгалтеры, юристы, операторы колл-центров, супервайзеры и их руководители. Поэтому в нашей линейке традиционно есть версии и для Win, и для macOS.

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

Поэтому нас часто спрашивают про мобильный софтфон и компании с менеджерами "в полях", и провайдеры связи. Интерес вторых тоже понятен: зарабатывать на первых, предлагая им не только десктопные продукты, но и решения для Android и iOS. В идеале — под своим названием и логотипом.

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

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

Формулируем задачи разработки

Основные вопросы, которые потребовалось решить, были такие: что лучше для бэкенда; какими будут язык и среда разработки; стоит ли делать приложение кросплатформенным; что делать с засыпанием.

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

Технологический стек: среда разработки, язык и опыт других

Разбираясь с технологическим стеком, выяснили несколько интересных моментов про Acrobits, Zoiper (у них также есть мобильные версии софтфонов), а также Telegram и WhatsApp, которые с некоторой натяжкой тоже можно отнести к софтфоном, потому что передается RTP-трафик.

Так, например, мы обнаружили, что все они под Win написаны на Java (язык) и Kotlin (среда разработки), а под macOS — на Swift и Objective-C соответственно. Что касается бэкенда, то путь у каждого свой: WebRTC, PJSIP, а то и вовсе самописные решения. Что нам дало это знание? В тот момент — только понимание, что легкая прогулка получится вряд ли :)

Выбор между нативным и кроссплатформенным

Поставили вопрос так: что, если сделать одну кодовую базу для iOS и Android? Будет ли это лучше? (Казалось, что да, потому что в два раза меньше работы.) И проще ли это? Затем мы перепробовали много разных вариантов — WebRTC и JSIP выступили в качестве основы для передачи данных, а уже упомянутые Swift и Kotlin — в роли нативных языков для нашего приложения. Также попробовали три кроссплатформенные среды разработки: Qt, React и Flutter. Результаты заставили задуматься.

Например, связка Flutter + PJSIP не заработала вообще. Потомство Flutter и WebRTC оказалось более жизнеспособным, но и только. Попробовали копнуть поглубже (а вдруг?), но быстро бросили это дело: однажны набрели на репозиторий с попыткой решения задачи, похожей на нашу — это решение на тот момент уже насчитывало 8 000 строк кода… и было похоже, что это только начало.

Наше удивление от количества строк кода в репозитории

Задумчивость и сомнения — вот что мы испытали в тот момент.

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

Затем попробовали скрестить PJSIP и WebRTC с другой кроссплатформенной средой разработки — React'ом. В обоих случаях получили работающий результат (уже плюс). Однако казалось, что смотрим трейлер проходного фильма: всё самое интересное и вкусное уже показали, а дальше будет всякий трэш. Не покидало ощущение, что обязательно вылезут разные минусы, с которыми придется долго и муторно разбираться (интуиция?). Волевым решением исключили React из числа претендентов.

Таким образом, остался один кандидат от кроссплатформенной партии (Qt) и по одному представителю от Андроида и Яблока. Именно им и предстояло схлестнуться в финале.

Гюльчатай, покажи личико

Решили, что первая (и, возможно, единственная) битва пройдет с представителем зелёных человечков. Регламент матча: собираем приложение на Qt и на Kotlin’е. В обоих случаях тратим одинаковые усилия, после чего сравниваем результат. Если Qt проигрывает, то это автоматически означает и победу Swift’а. А если Qt побеждает, то будет аналогичный бой с “яблочником”. Иными словами, кросплатформенная среда должна доказать превосходство во всех случаях, иначе теряется смысл ее использования.

А вот, кстати, и результат — угадайте, кто где.

Слева Qt, справа Kotlin.

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

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

Таким образом, кроссплатформенный Qt уступил нативным языкам. Это, в свою очередь, означало, что будет не одна, а две кодовые базы — то есть в два раза больше работы… если, конечно, мы хотим, чтобы было качественно. Но ведь качество — наше второе имя. Мы любим клиентов и заботимся о них!

Что сейчас

Сейчас у нас есть хороший, стабильно работающий мобильный софтфон, готовый продаваться под вашим логотипом! Версия для Android написана на Kotlin, версия iPhone — на Swift. В качестве будильника, который обеспечивает корректный выход из спящего режима и избавляет от пропущенных звонков, используется PUSH-сервер.