Привет, Хабр! Меня зовут Александр Сорокин, я разработчик из команды Okdesk. 11 лет мы трудимся над платформой для управления заявками, выездным обслуживанием и ТОиР – загадочной аббревиатурой, которая легко разгадывается как техническое обслуживание и ремонт.
В статье хочу рассказать, как наша команда мобильных разработчиков в Okdesk развивает два мобильных приложения одновременно. Спойлер: главный герой этой истории – кроссплатформенная технология. Именно она позволяет нам выпускать приложения и под iOS, и под Android, не раздувая команду и не переписывая один и тот же код дважды.
Мы постарались рассказывать простым языком, без сложных терминов. Если вы только присматриваетесь к кроссплатформенной разработке и хотите на нашем примере посмотреть, за счёт чего она бережет ресурсы, то текст для вас.
Из чего сделана система Okdesk: юзер-флоу и техническая изнанка
Пара слов о пользовательском сценарии работы с Okdesk
Okdesk – это платформа для управления сервисными процессами: заявками, выездным обслуживанием, плановыми работами и ТОиР. В ней сервисные компании выстраивают полный цикл работы с клиентами и оборудованием – от регистрации обращения и назначения исполнителя до выезда специалиста, фиксации выполненных работ, контроля сроков и истории обслуживания.
Давайте на примере. Представьте сервисную компанию, которая обслуживает оборудование у своих заказчиков. Она покупает подписку на Okdesk и заводит аккаунт – отдельное рабочее пространство. Внутри него компания регистрирует своих сотрудников, мы называем их исполнителями, или агентами. Администратор аккаунта настраивает флоу, или процесс работы над заявками, под нужды компании.
Клиентам компании предоставляется доступ в систему. Они становятся заявителями, или контактами, и начинают через разные каналы создавать заявки: «сломался кондиционер», «не работает касса», «нужно провести плановое обслуживание».
Дальше эстафета возвращается к исполнителям: они проводят заявку по статусам, пишут комментарии, прикладывают фотографии, отмечают выполненную работу. Самое важное – все участники процесса в реальном времени видят, как заявка движется по этапам флоу.
Точки контакта системы и пользователей
Чтобы плавно перевести наш разговор в техническое русло, опишем составляющие системы Okdesk – они же точки взаимодействия исполнителей и заявителей с системой.
Веб-приложение
Именно здесь живёт основная логика. Для мобильных приложений у него есть API – причём для каждого приложения свой набор методов.Мобильное приложение для исполнителей
Между собой мы называем его “МК” (мобильный клиент). Им пользуются сотрудники сервисных компаний, когда выполняют заявки «в полях».Мобильное приложение для заявителей
По-нашему – “МКК” (мобильный клиент для клиентов). Оно проще: с его помощью клиенты сервисных компаний сообщают о поломках, инцидентах и следят за своими заявками.
Важная деталь: мы поддерживаем только две платформы – iOS и Android. Отдельных десктоп- или веб-версий мобильных приложений у нас нет. Полноценный веб-интерфейс имеет наш основной сервис и живёт он отдельной кодовой базой внутри того самого монолита.
Стек: на чём всё строится
Оба мобильных приложения (и “МК”, и “МКК”) мы пишем на общем наборе технологий:
Angular – веб-фреймворк, на котором написан весь интерфейс. Это полностью кроссплатформенный код: один и тот же, без деления на версию под iOS и под Android.
Ionic Framework – набор готовых UI-компонентов и инструментов специально для мобильных приложений на веб-технологиях.
Ionic даёт кнопки, списки, модальные окна, переходы между экранами и прочие элементы, которые выглядят и ведут себя «по-мобильному», близко к нативным. Благодаря ему интерфейс ощущается как настоящее мобильное приложение, а не как сайт, открытый в браузере.Capacitor — мост между нашим веб-кодом и нативными возможностями смартфона. Про него мы подробнее расскажем ниже.
Такая связка и даёт нам главное: возможность писать единый код сразу под обе платформы.
Магия кроссплатформенности: технологические преимущества и бизнес-эффекты
Почему кроссплатформенность выигрывает у нативной разработки
Если бы мы пошли по нативному пути, пришлось бы держать две отдельные кодовые базы: одну на Swift для iOS, другую на Kotlin для Android. Каждую фичу пришлось бы реализовывать дважды – по разу на каждой платформе.
С кроссплатформенностью картина другая. Мы тратим заметно меньше времени на разработку фич, потому что основной объём наших задач – это бизнес-логика. А она прекрасно логически описывается одним общим кодом.
Цифры говорят сами за себя: примерно 5-10% задач так или иначе касаются нативной части системы. Всё остальное мы делаем вообще не трогая нативный код, а нередко даже не прибегая к возможностям Capacitor. Кстати, в первые годы разработки доля «нативных» задач была выше: со временем основная инфраструктура устаканилась, и теперь почти вся работа – привычный Angular-код.
Однако мобильная специфика не исчезает совсем. Она была и будет всегда: сборки под разные платформы, особенности тестирования, поведение на конкретных устройствах. Поэтому, если кто-то из «немобильных» разработчиков команды захочет подключиться к нашим приложениям, ему всё равно придётся разобраться с кроссплатформенностью и её нюансами. Но это в разы проще, чем полностью менять стек, переходить на Swift/Kotlin и осваивать всю нативную разработку с нуля. Человек, который уже знает Angular, входит в наши проекты быстро.
Приятный бонус: мини-приложения для Telegram и Max
Использование веб-фреймворка в роли фронтенда дало нам ещё один подарок, на который мы почти не потратили сил – приложения Mini App для мессенджеров Telegram и Max.
Мы фактически «скопировали» наше приложение для заявителей (МКК), собрали его в виде набора статических файлов (ассетов) и отдаём в мессенджеры. Там оно работает как полноценное мини-приложение. Тот же код, что крутится в мобильном приложении, мы переиспользовали ещё в двух местах.
Одним вебвью-приложением – двух зайцев
Вспомним сервисную компанию из начала статьи. Когда пользователь-заявитель, хочет создать заявку, например на обслуживание промышленного станка, и нажимает на иконку нашего приложения, у него открывается вебвью. По сути страница в браузере, в которой нет ничего лишнего: вкладок, адресной строки, элементов интерфейса браузера вообще. Просто веб-страница на весь экран. Эта веб-страница и есть наше приложение – SPA (Single Page Application) на Angular.
Что это даёт? Поскольку мы пишем на JavaScript, HTML и CSS, нам не нужно реализовывать каждую кнопку отдельно под каждую платформу. Мы один раз описываем кнопку «для браузера», а вебвью гарантирует (с некоторыми оговорками), что она будет одинаково выглядеть и на iOS, и на Android, и в мини-приложении мессенджера. Один код – везде одинаковый результат.
Нативные возможности – легко с Capacitor
Конечно, одним вебвью сыт не будешь: приложению всё равно нужно работать с «железом» и системными возможностями телефона – камерой, файлами, геолокацией. Вот тут на сцену и выходит Capacitor. Он работает как мост между веб-кодом и нативным кодом.
Разберём на примере. Исполнителю нужно сфотографировать результат своей работы:
1. Он нажимает в приложении “Сделать фото”.
2. Под капотом JavaScript обращается к Capacitor.
3. Capacitor через специальный плагин открывает нативную камеру телефона. Внутри плагина для iOS и для Android написан свой код взаимодействия с камерой — но нам, разработчикам, в него лезть не нужно.
4. Пользователь делает фото в привычной нативной камере.
5. Capacitor возвращает это фото обратно в наше JavaScript-приложение.
6. Приложение само обрабатывает фотографию и отправляет её на сервер.
Самое приятное: у Capacitor есть огромное количество готовых плагинов – и официальных, и от сообщества. Они покрывают большую часть нативной функциональности. Поэтому нашим разработчикам почти не приходится разбираться в нативной «внутрянке»: нужно поработать с камерой – подключаем плагин камеры; нужны файлы – берем плагин файлов. А сами пишем привычный Angular-код.
В итоге мы получаем много возможностей нативной разработки, оставаясь в знакомом и удобном стеке веб-технологий.
Веб-технологии на страже переиспользования разработки
Веб-технологии в мобильном приложении могут упростить переиспользование наработок между мобильной и веб-версиями.
Например, уже сейчас бывают случаи, когда мобильная команда делает фичу на Angular, а потом её наработки адаптируют для веб-версии на React. При одинаковом стеке такой перенос был бы проще: часть кода, компонентов и логики можно было бы использовать повторно, вместо того чтобы делать всё заново.
Одна библиотека компонентов на три приложения
Ещё одно следствие выбора веб-технологий – у нас получилось сделать единую библиотеку UI-компонентов. Мы используем её сразу в трёх разработках: в приложении для исполнителей (МК), приложении для заявителей (МКК) и мини-приложениях для мессенджеров.
Работает это так: мы пишем компонент один раз – например, компонент выбора элемента из списка (select), и затем переиспользуем его во всех трёх приложениях. Везде он выглядит и ведёт себя одинаково. Не нужно поддерживать три разных селекта, исправлять баг в трёх приложениях и следить, чтобы они не разъехались по дизайну.
Вместо заключения
Кроссплатформенная разработка для нас – основа всей мобильной разработки Okdesk. Она позволяет небольшой выделенной команде поддерживать сразу несколько приложений, переиспользовать код и компоненты и при этом сохранять доступ к нативным возможностям iOS и Android.
Итак, за счёт связки Angular + Ionic + Capacitor мы:
пишем единый код сразу под iOS и Android;
держим оба мобильных приложения под контролем;
тратим время в основном на бизнес-логику, а не на дублирование одной и той же фичи под две платформы (нативного кода у нас лишь 5-10%);
получили мини-приложения для Telegram и Max;
переиспользуем одну библиотеку компонентов на три приложения.