Comments 21
Привет тебе Тихон из РФ! А ты в какой стране живешь?
Меня зовут Устинов Тихон и я работаю в Ростелеком
10 и 11 марта 2022 года основанные российскими разработчиками компания JetBrains (Kotlin) и стартап Miro заявили об уходе из России. Это означает полное прекращение продаж, закрытие офисов, отказ в техподдержке и блокировку аккаунтов существующих клиентов
JetBrains не блокируют аккаунты, по крайней мере у меня ничего не блокировали
Лицензией IDE можно пользоваться, не будет работать только обновление на новые версии после окончания лицензии, старая версия продолжит работать по их заявлению
Сам Kotlin вместе с Kotlin Multiplatfrom open source
Так что проблем с использованием возникнуть не должно, а открывать холовар о политике не вижу смысла
Информация взята из статьи на хабре https://habr.com/ru/news/t/655249/
Напишите плиз публикацию на хабре со более подробным сравнением чем выше. Сравнение может быть весьма полезно.
Экспертиза разработчиков. Хоть разработчики и будут
писать на одном языке, но вероятно иногда придется разбираться с
задачами на стыке нескольких платформ. Соответственно, для хорошей
команды необходимо знать помимо Kotlin средства разработки платформ, под
которые они компилируют;
У вас гладко прошло, или такая экспертиза понадобилась? Речь идёт только о средствах разработки или же и о необходимости знания JS, Java, Swift?
Зная только Kotlin и используя Kotlin Multiplatform можно полностью написать приложение и собрать его под Android и iOS?
Все прошло достаточно гладко, но экспертиза понадобилась. Речь идет и о том, и о том, так как иногда приходится решать вопросы на стыке всех языков, под которые мы компилируем. Например, обычный тип Array на JS это нативный массив, а на Swift это экземпляр класса KotlinArray. Или если у вас есть асинхронность то, чтобы сделать доступный ваш метод на всех целевых платформах, нужно хотя бы малейшее понимание асинхронности на платформах, где вы хотите вызвать этот асинхронный метод. Например, в Kotlin это условный suspend метод, а в JS это нужно превратить в Promise а в Java в Future. Это все решаемо и есть официальные чаты в телеграмм которые могут помочь разобраться с возникшими проблемами, но понятно что если будут знания целевых платформ то разработка будет на много легче.
По поводу написания приложения, на сколько я понимаю, чтобы написать приложение только на Kotlin тебе нужно так же интерфейс писать с помощью Kotlin, и такой инструмент есть называется Compose Multiplatform, и ты можешь с его помощью создать интерфейс на Kotlin и запустить это на Android, но это не работает с iOS, под iOS тебе все равно придется делать интерфейс средствами разработки под iOS и как то заставить их работать вместе, что-то подобное было описано тут Как использовать Kotlin Multiplatform ViewModel в SwiftUI и Jetpack Compose. Если односложный ответ, то нет, нельзя.
К недостаткам kotlin multiplatform стоит отнести ещё и то, что компилятор работает на наборе бэкендов, которые никак с друг другом не согласованы. Компилятор же при этом использует наивные для платформы реализации по максимуму.
В итоге в какой-то момент можно обнаружить себя в ситуации, в которой на одной платформе все работает, а на другой тоже самое приложение падает из-за того, что базовые структуры данных написаны иначе.
У меня был такой опыт. Я реализовывал алгоритм Эрли, который подразумевает использование множеств, в которые нужно добавлять элементы в процессе итерации по этим самым множествам. И для native это не проблема. Итератор работает так, что новые элементы попадают в конец и все классно. Зато jvm считает иначе и при запуске этой версии код падает, потому что в мире жабы добавление элемента в процессе итерации по коллекции - это ConcurrentModificationException.
Совершенно непонятно за что борьба. Супер сложная система сборки а переиспользуется в итоге две с половиной строки кода. В конкретных реализациях на Swift и JavaScript гораздо гораздо больше кода, и он действительно делает что-то полезное.
К чему такой сложный и трудно поддерживаемый огород, надо просто эти две с половиной строчки скопировать в Swift и JavaScript
Какой есть общий недостаток у мобильной, front-end и back-end разработки и иногда распила микросервисов?... Очень часто логику работы приложения нужно поддержать и там
Мне кажется это проблема архитектуры, а не технологий. Моб приложение с северной логикой это тонкий/толстый клиент, который рисует только экраны, графику и работает с сетью, зачем мне там логика бекенда? или зачем на бекенде логика клиента, там же принципиально разные концепции,и всё равно придётся заботиться о синхронизации.
Мне кажется kotlin multiplatform узко специализированная технология , которая очевидно пока не нашла свою нишу.
В вашей статье всё можно сделать на flutter + любой бекенд, и это будет быстрее и понятнее, и легко поддерживаться, будет компилироваться на 2+ платформы без сюрпризов и без необходимости знаний в kotlin swiftui, javascript.
К тому же во flutter войти быстрее чем в jvm с котлином.
В вашей статье всё можно сделать на flutter + любой бекенд
Зачем мне бекенд когда он не нужен?
Моб приложение с северной логикой это тонкий/толстый клиент, который рисует только экраны
Не всегда, иногда удобнее сделать какой-нибудь конструктор чего-нибудь на клиенте, как минимум для вариантов с offline режимом
или зачем на бекенде логика клиента, там же принципиально разные концепции,и всё равно придётся заботиться о синхронизации
Как я и написал эту статью чтобы показать что иногда логики могут пересекаться, и что с помощью данной технологии проблему синхронизации можно избежать
Я вас процитирую на всякий случай =)
Какой есть общий недостаток у мобильной, front-end и back-end разработки и иногда распила микросервисов? Дублирование логики
Зачем мне бекенд когда он не нужен?
Затем вы в пример приводите приложение без бекенда =)
Далее я постараюсь продемонстрировать, как на практике можно применить эту технологию. Для этого я написал ядро игры крестики-нолики и реализовал отображение на трех языках JS (Browser), Swift (iOS), Java (Android).
Я поясняю что в вашем примере всё можно сделать на flutter и как вы верно заметили без бекенда =), но можно и с бекендом =) Т.к вы указали backend-разработку и дублирование логики.
Как я и написал эту статью чтобы показать что иногда логики могут пересекаться, и что с помощью данной технологии проблему синхронизации можно избежать
У Вас статья начинается с "дублирования логики frontend-а и backend-а". А в примере вы уже обращайтесь к проблеме единой кодовой базы (кросс-платформенной разработки). Если вы о кросс-платформе, то как раз таки kotlin multiplatofrm не для этого, т.к интерфейс в том же iOS вы будете рисовать в xcode и собирать всё будете там, т.к в km нет единых инструментов сборки под разные платформы, в отличии от flutter.
Нужно понимать разницу в cross platform vs multiplatform.
Затем вы в пример приводите приложение без бекенда =)
Ничего мне не мешает добавить полученную логику и на какой нибудь back-end, обернуть это работой с клиентами и будет back-endрешение.
Нужно понимать разницу в cross platform vs multiplatform.
Я рассказывал о kotlin multiplatfrom с точки зрения разработки библиотеки которую можно переиспользовать на множестве платформ. View в данном случае только лишь для наглядности.
в вашем примере всё можно сделать на flutter
Сделать можно было на чем угодно, но это была бы уже другая тема статьи.
Если быть конкретно в своей работе наша команда пишет ядро логики на kotlin multplatfrom и отдает SDK как продукт, и этот SDK наши пользователи могут добавить себе в приложение любой технологии которая может обработать такими языками как js, java, swift. Имея при это большой набор существующих для kotlin библиотеки и инструментов. Flutter для этого вообще не подходит, более менее можно писать на Dart и компилировать под разные платформы. Но имея команду Java разработчиков выбор был сделан в пользу Kotlin.
И поэтому в статье Kotlin, а не Dart / Flutter.
B ещё в вашем примере с крестиками-ноликами Game framework можно заменить на спецификацию или протокол и написать в каждом приложении код на нужном языке. А при использовании KMM, если кто-то будет сопровождать Game framework из примера, то ему придётся производить тестирование на N-платформ(языков). Именно поэтому KMM обречён только на очень узкие задачки, т.к если мы можем написать SDK на одном языке, то переписать его на swift / java / js - задача аналогичная компетенциям KMM, а вот вопрос надёжности кода и влияния на обновления при KMM вызывает больше опасений, в том числе по стоимости поддержки. К тому же усложняется раскатка обновлений или например частичных обновлений. В том числе изолированной работе над частями проекта. В общем очень много минусов.
то переписать его на swift / java / js - задача аналогичная компетенциям KMM
А если нужно внести правки? Нужно будет 3 разработчика которые на 3-х проектах будут вносить правки, и не факт что они сделают их одинаково, покрыть тестами нужно так же на 3-х проектах.
в том числе по стоимости поддержки
Чтобы было понятно у нас команда из 3-х человек на SDK, при этом SDK использует 7 проектов. Если предположить что чтобы это все сделать нужно по 3 человека на каждый проект то получается без SDK нужно было бы 21 разработчик.
А при использовании KMM, если кто-то будет сопровождать Game framework из примера, то ему придётся производить тестирование на N-платформ(языков)
При нахождении бага на одном из проекта, баг правится на командой SDK и там же покрывается тестами под платформы. Выкатывается новая версия и остальные проекты по своему жизненному циклу переходят на нее (с оговорками, по версиям так же есть семантическое разделение версий и все оттуда вытекающее). И получается 1 разработчик может исправить проблему на 7 проектах на разных языках.
Так же формат данных между этими проектами тоже единый, введение новых фич одинаково для всех.
Так что на счет минусов не уверен, и мое мнение что плюсы значительно их превышают.
Если проект "крестики-нолики" то конечно нет смысла тянуть мультиплатформу, но если у вас крупный enterprise проект со сложной логикой - то это просто must have.
А если нужно внести правки? Нужно будет 3 разработчика которые на 3-х проектах будут вносить правки
Ответ на этот вопрос зависит от преследуемых вами целей. В статье не подходящий пример. И KMM не вышедший до сих пор из беты доказывает его спорное положение. Дело как раз таки в том что у вас могут быть разные API версии, SDK платформ и окружений. В простейшем случае, как в вашей статье, всё очень просто и действительно можно заменить на 3-х проектах всё одним разработчиком при условии что он будет знать ГДЕ вставлять ваш SDK и какие структуры формировать для вашего SDK. Вам придётся в любом случае сформировать протокол/документацию. Отсюда вытекает следствие что разрабатывая такое SDK вы освоили swift/js/kotlin на том уровне, на котором KMM уже теряет смысл.
Чтобы было понятно у нас команда из 3-х человек на SDK, при этом SDK использует 7 проектов. Если предположить что чтобы это все сделать нужно по 3 человека на каждый проект то получается без SDK нужно было бы 21 разработчик.
Можно взять протокол/алгоритм SDK и сделать на 3 языка (swift/js/kotlin) и у вас будут независимые версии для платформ. 3 разрабочика их будут поддерживать. Каждому по одному ЯП. Стоит заметить что зная kotlin, выучить swift или js - это дело 1-2 дней. И в обратную сторону тоже самое. Особенно с современными IDE.
Так же формат данных между этими проектами тоже единый, введение новых фич одинаково для всех.
Не согласен. Ведь входные данные будут приходить из разных платформ. В любом случае надо будет изучить как эти данные прокинуть в SDK. В общем это похоже на всё то что уже было сделано до KMM. Та же концепция биндингов, только ещё более усложняющая поддержку (конвертацию кода в платформы)
Если проект "крестики-нолики" то конечно нет смысла тянуть мультиплатформу, но если у вас крупный enterprise проект со сложной логикой - то это просто must have.
Это субъективно, сложная логика она для всех разная =) Тем более я бы не стал доверять сложную логику автоматическому транслятору kotlin->swift , kotlin->js. Как раз таки тут лучше всё контролировать, раз это сложный и кровавый enterprise =)
Но оговорюсь это лишь моё личное мнение, возможно вам так удобнее, вы так решили и вас никто не остановил, потому что кроме вас знающих kotlin никого не было рядом, поэтому выбор был сделан верно или неверно. Но в статье всё переплетено в кучу. Вы в том числе упомянули react native и webview. И в общем, что вы это рассматривали, это наводит на мысль о том что вы хотели сделать cross, но увидели kmm, и побежали в него =)
Так что на счет минусов не уверен, и мое мнение что плюсы значительно их превышают.
После прочтения статьи у меня такого впечатления не создалось.
Но спасибо вам за разбор и ответы.
Выходим за пределы JVM. Объясняем на крестиках-ноликах чем хорош Kotlin Multiplatform