KMM - последний ребенок в мире, когда дело доходит до создания мобильных устройств. В Octopus Energy мы экспериментировали с KMM в течение последних ~ 9 месяцев и создали приложение с нуля, используя эту технологию. Так о чем все это? И стоит ли ему попробовать?
Этот пост задуман как концептуальный обзор KMM, и в следующих нескольких постах я подробно расскажу о том, как мы обнаружили, что это работает на практике.
Хотите работать с KMM, Jetpack Compose, SwiftUI; И повлиять на изменение климата?
Octopus Energy всегда нанимает талантливых и увлеченных мобильных разработчиков, поэтому, если вам нравится то, что вы видите здесь, свяжитесь с нами! Или подайте заявку прямо по адресу: https://jobs.lever.co/octoenergy
Разработка мобильных приложений
Когда дело доходит до создания мобильных устройств, у вас всегда был выбор вариантов, которые можно было разделить на две основные категории. Кросс-платформенный интерфейс или собственный.
Какие варианты лучше - это своего рода минное поле, поскольку разработчики обычно специализируются только на одном из вариантов, поэтому их работа часто полагается на борьбу за свой угол ... что приводит к некоторым сильным взглядам в любом случае.
На высоком уровне обычно можно считать, что кроссплатформенный пользовательский интерфейс является королем, когда пользовательский интерфейс имеет низкий приоритет, а время / стоимость имеют высокий приоритет, а нативный - король, наоборот. Но почему? И где тут КММ?
Кросс-платформенный интерфейс - невыполнимая работа
Кросс-платформенный пользовательский интерфейс построен на концепции создания единой платформы, которая выводит приложения для нескольких платформ с помощью одной команды, работающей над единой базой кода - пишите один раз, запускайте где угодно.
Напишите один раз, бегите куда угодно - это выигрышная стратегия, верно? Но написать общую структуру для двух операционных систем невероятно сложно.
Для систем Android или iOS мы создаем приложения с часами на основе более 10 миллионов строк кода, написанных более чем за десять лет. И они еще не закончены, ежегодно обе операционные системы получают множество обновлений своих основных пакетов, не говоря уже об огромной экосистеме окружающих их библиотек (например, androidx).
И эти системы построены двумя крупнейшими компаниями в мире при поддержке сопутствующих ресурсов, имеющихся в их распоряжении.
Кросс-платформенные UI-фреймворки неизбежно изо всех сил стараются не отставать, имеют проблемы с производительностью, из-за них появляются ошибки, а по мере усложнения ситуации им требуются собственные разработчики для создания функциональности, не поддерживаемой фреймворком.
Через несколько лет выходит новый фреймворк - без устаревших проблем - и разработчики уходят.
Ни один кроссплатформенный фреймворк пользовательского интерфейса никогда по-настоящему не выбрался из корыта разочарования.
Падение разочарования
Интерес угасает, поскольку эксперименты и реализации не приносят результатов. Производители технологии вытряхнут или потерпят неудачу. Инвестиции продолжаются только в том случае, если выжившие поставщики улучшают свои продукты к удовлетворению первых пользователей.
Кросс-платформенный интерфейс может с трудом стать универсальным и долгосрочным вариантом разработки для большинства проектов, но он выполняет свою задачу. Если вы хотите быстро создать приложение для нескольких платформ и вам не хватает ресурсов, кроссплатформенный пользовательский интерфейс - это то, что вам нужно. Соседние стартапы, хобби-проекты, агентства, прототипы - все это области, в которых проявляется кроссплатформенный интерфейс.
Родной - дорогое дублирование
Нативная разработка позволяет вам иметь полную свободу использовать платформу в полном объеме и дает вам доступ ко всей экосистеме, что дает вам возможность максимально улучшить взаимодействие с пользователем.
Но это требует денег и времени.
Команды в собственном проекте принципиально разделены и состоят из людей с совершенно разными навыками и опытом. Они работают с разными кодовыми базами, написанными на разных языках, чтобы разделить стандарты для всего, от качества кода до архитектуры.
Требования должны быть спланированы и доведены до сведения каждой команды, которая обычно работает с разной скоростью. Проблемы решаются дважды для очень похожих проблем - часто одна и та же проблема. И после того, как он был построен, все нужно протестировать дважды, часто выкидывая два набора ошибок ... и цикл повторяется.
Содержание двух отдельных команд всегда дороже, чем содержание одной команды, и обычно медленнее.
Родной язык может быть не идеальным, но это беспроигрышный вариант. Всегда найдутся люди, которых можно нанять, и технология будет существовать, пока существует базовая платформа.
Это отлично подходит для долгоживущих проектов, таких как проекты на предприятиях или масштабные стартапы. Дополнительный контроль платформы также делает нативный маршрут предпочтительным для всего, что использует специализированный пользовательский интерфейс, проекты, которые зависят от производительности, или приложения, которые активно используют возможности устройства.
Где подходит KMM
Ни кроссплатформенный интерфейс, ни нативный - не идеальные решения. Собственная разработка всегда ведет к отдельным командам на разных базах кода, кроссплатформенный пользовательский интерфейс всегда будет бороться за создание надежной и долговечной общей структуры - они оба основаны на концепциях, которые не оставляют места для серьезных улучшений.
KMM использует новый подход.
Концептуально KMM основан на совместном использовании кода и языковом взаимодействии - идеях, которые оказались довольно успешными при разработке программного обеспечения. Совместное использование кода существует с тех пор, как существуют компьютеры, и составляет основу всех современных технологий; в Android и iOS мы также довольно привыкли к концепции взаимодействия, поскольку большую часть четырех лет мы были хорошо знакомы с наличием Java / Kotlin или ObjC / Swift в наших кодовых базах.
В KMM выбор, чем поделиться, остается за командой. Это подход «делитесь тем, что вы хотите», при котором вы можете делиться чем угодно, от небольших логических фрагментов до целых слоев вашего приложения. Важно отметить, что основа проекта - в частности, пользовательский интерфейс и возможности устройства - остаются полностью нативными.
Но какие проекты принесут пользу компании KMM и когда ее выбрать? Что касается цикла ажиотажа в сфере технологий, KMM, вероятно, находится где-то вскоре после запуска технологии - это все еще ранняя стадия, поэтому трудно сказать, где именно он окажется наиболее выгодным.
Технологический триггер
Возможный технологический прорыв - это начало. Ранние экспериментальные истории и интерес средств массовой информации вызывают значительную огласку. Часто продуктов, пригодных для использования, не существует, а коммерческая жизнеспособность не доказана.
Поскольку KMM предлагает сравнимый пользовательский опыт с нативными проектами - пользовательский интерфейс в конце концов будет полностью нативным - наряду с возможностью работать в одной команде со всеми связанными с этим преимуществами по стоимости и скорости, есть все возможности, что KMM в конечном итоге окажется невероятно популярным выбором. .
Почему КММ может добиться успеха
Эта статья становится намного длиннее, чем я планировал, поэтому я остановлюсь на некоторых тонкостях KMM, которые дадут хорошие признаки его распространения.
- Может приниматься постепенно . Большинство проектов являются устаревшими и не могут позволить себе переписать всю кодовую базу. KMM можно внедрять по частям, перемещая небольшие фрагменты общего кода в общий модуль.
- Как решение языка и компилятора, у него гораздо больше вероятность долговечности по сравнению с кроссплатформенным пользовательским интерфейсом.
- Никаких специальных знаний не требуется. Если вы знаете Kotlin и Gradle, вы можете создавать приложения KMM. Сделать найм намного проще.
- Мобильная связь - это только начало. Вы уже можете делиться кодом с широким спектром других платформ, включая настольные компьютеры и Интернет.
- Ограниченный риск при усыновлении. Если все не удается, приложение для Android уже написано - просто переместите общий код в модуль Android - и вы можете написать свой собственный парсер для преобразования файлов Kotlin в файлы Swift - довольно быстро, имея резервное копирование и запуск приложения iOS.
Стоит ли попробовать?
Отличие KMM заключается в том, что он не пытается присоединиться к безумной погоне за записью, когда-то запущенной где-нибудь. Любой, кто занимается разработкой пользовательского интерфейса в течение нескольких лет, видел свою долю Flutters & React Native, которые обещают многое, недоставку и выгорание перед следующим решением "написать один раз где угодно", обещающим, что на этот раз все будет по-другому.
KMM основывается на концепции, с которой современные разработки программного обеспечения достигли огромных успехов, - совместно используемом коде. KMM - это просто разделяемая библиотека для конкретного приложения.
Для нас, разработчиков, которые его используют, его простота - это сила. Если вы знаете Kotlin и Gradle, вы готовы поделиться большой частью своей кодовой базы между Android и iOS.
Простота показана в нашем собственном проекте. Наше приложение KMM было создано с использованием множества новых технологий - SwiftUI, Compose и GraphQL. Как и ожидалось, при использовании новых технологий - в частности, новых фреймворков пользовательского интерфейса, таких как SwiftUI и Compose - возникло множество проблем. Удивительно то, что KMM почти не вырвало.
Общий пользовательский интерфейс - это история боли и неудач. Общая логика - это история компьютеров.
-Кевин Галлиган
Если у вас есть определенные области KMM, о которых вы хотели бы узнать больше, напишите о них в комментариях, и я постараюсь описать их в следующих сообщениях.
