Connect with us

Кроссплатформенная разработка

КММ на практике или выбор кроссплатформенного фреймворка для «Леруа Мерлен»

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

Фото аватара

Опубликовано

/

     
     

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

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

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

В процессе поиска рассматривали Flutter, React Native и Kotlin Multiplatform Mobile.

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

При изучении Flutter обнаружились две проблемы:

  • узкий круг специалистов, знакомых с языком Dart (снова невозможность масштабировать);
  • разрывы между регулярно выпускаемыми новыми версиями Android и iOS и реализацией во Flutter, с которыми можно смириться во внутренних приложениях, но никак не в клиентском.

Также исследования показали, что лучше не использовать одинаковый клиентский интерфейс между Android и iOS, так как интерфейсы этих платформ имеют разные принципы управления.

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

Плюсом было и то, что Kotlin является родным языком Android, т. е. не предполагает никаких проблем с поиском и обучением разработчиков. А из-за близости к JVM-языкам потенциально любой kotlin-разработчик может работать с Kotlin и KMM. Это было как раз то, что нужно.

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

KMM на практике

Сейчас мы не вынесли в KMM пользовательский интерфейс и функции Apple Pay и Google Pay.

Мы используем KMM:

  • внутри библиотеки — Ktor, Kotlin Serialization и Coroutines;
  • Rx для адаптации платформы (в будущем будут только Coroutines на Android);
  • в библиотеке SQLDelight для кэширования API, чтобы увеличить функциональность клиентской корзины без привязки к интернету.

Нюансы, которые обнаружились при использовании Kotlin Multiplatform Mobile:

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

Плюсы КММ:

  • единый код, который можно в любое время дописывать и изменять;
  • до KMM функция пользовательской корзины требовала примерно 40–60 часов работы для каждой платформы (80–120 часов для обеих), не считая тестирования, с KMM время сократилось для обеих платформ на 50%;
  • разделение бизнес-логики между iOS и Android с сохранением собственного кода для каждого клиентского интерфейса;
  • любые изменения и корректировки происходят одновременно на обеих платформах.

Еще одна проблема — это локальная сборка артефакта. Если стоит задача добавить зависимость от KMM модуля в качестве зависимости, то это можно сделать через CocoaPods для iOS и через Gradle для Android.

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

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

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement

Наши партнеры:

LEGALBET

Мобильные приложения для ставок на спорт
Telegram

Популярное

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: