Comments 7
Ответы на вопросы:
Если команда из пяти разработчиков, то это -1 (точно не мало).
Если долгострой, то да.
Важен для всех (как для бизнеса так и для команды).
Пара встречных вопросов:
Какой порог сложности проекта, после которого КМП начинает окупаться быстрее, чем натив?
Что из логики ты сознательно не стал выносить в КМП и почему?
На вопросы ответа не будет, потому что многое зависит от функционала. Ваш пример по сути простой "Hello world" и на таком рафинированном примере достичь цифры 21% достаточно легко. Можно и больше, используя CMP для одинакового UI.
Проблемы начинаются тогда, когда нужно работать с датчиками, камерой, bluetooth, файлами и пр. Если, скажем для сетевых запросов есть готовая библиотека Ktor, то для платформо-специфических вещей универсального решения нет. Да и не факт, что оно вообще появится когда-нибудь.
Еще есть проблема перехода команды. Далеко не факт, что разработчики под одну платформу хотя бы читали документацию по другой платформе. Т.е. процесс перехода на CMP/KMP может быть не такой быстрый и безоблачный, каким представляется на подобных примерах. Единственное, но не настолько значимое, преимущество у Android разработчиков - они хотя бы синтаксис и стиль Kotlin знают. Но опять же, это особого профита не даст.
Суммируя:
если приложение просто тонкий CRUD клиент - то однозначно имеет смысл работать с CMP/KMP
если приложение работает с hardware смартфона - то черт знает... думайте сами :)
На iOS там хотя бы 90% апи кодогенерацией через Kotlin Native подтягивается, и в принципе поискать примеры на Swift, и адаптировать их под KN порой вполне возможно)
А вот с Desktop таргетами на JVM тяжко, получить доступ к какому-то платформенному функционалу ещё те танцы с бубнами. Но нативные Desktop клиенты пока не в приоритете у Jetbrains :(
Ответы:
Так то 21% это почти 1/5, так что, скорее много
С учетом потраченного времени на изучение КМП, следует улучшение и стабильность самого приложения в будущем, что говорит о положительном векторе развития
Мне кажется, синхронный выпуск версий одного приложения положительно скажется как на пользователях, так и на самой команде, которая делает данное приложение
Вопросы:
Насколько долгий порог входа в кмп и должен ли я буду изучить языки, на которых пишет андроид?
А почему тогда не взять React Native или Flutter ? Изучение займет немного времени. Библиотеки все есть. Интерфейс хочешь системный, хочешь кастомный. React Native и так превращает код в нативные элементы и прекрасно общается с нативными библиотеками если прям приспичит.
Такое приложение приложение пишется руками за час с интерфейсом, работой с апи и т.д.
В React Native как раз не нативный UI. Там некоторые обёртки и, судя по статьям, можно создать свои обёртки над теми компонентами UI, которые не обернули создатели React Native.
Но это совершенно не тот подход, что описан в статье. В статье используется полностью нативное приложение, по правилам и канонам этого нативного приложения, т.е. работаешь напрямую в Android Studio и Xcode, используешь всевозможные советы по нативным API и UI/UX со StackOverflow. Лишь логику свою пишешь на КМП. Т.е. КМП даёт возможность НЕ заменять то, как Apple и Google хотят, чтобы конкретный разработчик работал. НЕ заменять отладчик и прочие инструменты от Apple и Google.
Судя по ответам ИИ, Flutter исповедует подход, аналогичный с React Native: обернуть нативное во что-то иное и написать собственную обёртку, если не хватает. Т.е. это опять свои правила игры на все платформы. Опять же, статья про то, что правила игры свои лишь для логики, а UI, отладка, распространение строго так, как хотят Apple и Google.
Что нам стоит на КМП построить?