Comments 16
Проект уже разбит на модули: androidApp, iosApp, desktopApp и shared
Лезть в код не хочется, но хочется понять, почему при декларируемой мультиплатформенности надо иметь модули под каждую платформу. На том же Swing, к примеру, не надо писать разный код под Windows и Linux.
Перейдем к одной из самых интересных частей — iOS-таргету. Если до сих
пор все точки входа в приложение были написаны на Kotlin/JVM, то в
модулеiosAppнет ни строчки на котлине, а есть проект на Swift, который ссылается на модульshared, а точнее, его сорссетiosMain
А как при этом код на Swift собирается? Можно ли обойтись без кода написаннного на Swift и всё приложение под iOS написать на Kotlin mutliplatform?
Можете ещё разъяснить зачем введены expect и actual, почему не хватает понятий абстрактного класса, интерфейса и реализации, в чём их особенность?
Мне кажется, в данном случае речь идёт о другой кроссплатформенности. В Compose Multiplatform тоже не нужны отдельные модули под Windows и Linux, а под мобильные ОС они есть, но только для создания разных точек входа в программу. Мобильные и десктопные платформы имеют немало различий: например, на десктопе ваше приложение будет многооконным, а на Android вы вместо окна запустите асинхронный Activity, на iOS ещё что-то. Для этого и нужны сорссеты.
Можно попробовать и запустить приложение на iOS совсем без Swift, например https://github.com/AlexGladkov/TeslaApp-Compose-Mpp, Но команда Jb дропнула поддержку такого подхода, видимо у них были на это веские причины.
А expect/actual - просто удобный инструмент. Можно решить ту же задачу наследованием, но разработчики фреймворка избавляют нас от лишних телодвижений.
А expect/actual - просто удобный инструмент
Как он работает-то? Открыл текст на сайте котлина и ничего не понял.
но только для создания разных точек входа в программу.
это что значит?
Можно попробовать и запустить приложение на iOS совсем без Swift, например https://github.com/AlexGladkov/TeslaApp-Compose-Mpp, Но команда Jb дропнула поддержку такого подхода, видимо у них были на это веские причины.
Можно и без Swift. В подходе выше проект XCode генерируется на лету. Подход оказался мало-жизнеспособным, потому что у проекта XCode очень много настроек, которые очень сложно поддержать на уровне градл плагина. Проще держать проект xcode внутри compose проекта, чтобы ничем не ограничивать разработчика в конфигурации xcode проекта (а также в выборе инструментов -- нативные отладчики, профилировщики). Держать Swift код в этом случае кажется логичным. Никто его не заставляет править/писать, но это может потребоваться в будущем, если к примеру захочется обернуть композное приложение нативной iOS навигацией. Если в будущем мы увидем, что в большинстве случаев разработчики не трогают xcode обертку вообще (или трогают как-то одинаково) и 100% кода пишут в common коде, конечно мы для них предоставим соответствующий тулинг, скрывающий конкретные платформы по максимуму. Но на данный момент кажется что до этих 100% еще очень далеко
Честно говоря, это не выглядит проще, чем сделать тоже самое на flutter...
а для вышеописанной системы есть что-то вроде зеро-кодинг или лоу-кодинг или построитель (конструктор) форм или GUI?
Как обстоят дела с интеропом C++ кода? Лично меня пока его отсутствие останавливает от изучения Flutter. И я продолжаю долбить Qt/Qml (который в версии 6.5 очень даже ничего).
В Kotlin Multiplatform есть специальный инструмент, cinterop. Самому не приходилось пользоваться, но наверное штука стоящая: https://kotlinlang.org/docs/native-c-interop.html#object-pinning
Из более традиционного, конечно, есть jni еще
В зависимости от задач, можете еще посмотреть о свежих фичах интеропа haxe
и достаточно зрелом (но не единственном) UI фреймворке.
Пока еще сыровато и проигрывает flutter. Готовых компонентов и либ очень мало, iOS в состоянии alpha, web - experimental. Даже порог входа с учетом gradle и т.п. для новичков выше чем во flutter. Для серьезной кроссплатформенной разработки пока сыровато, но когда зарелизится, профит будет в том что многочисленные android разработчики смогут без особых проблем переключаться на кроссплатформу.
Добрый день. Хотелось бы добавить что для создания проекта можно использовать еще и такой инструмент:
https://terrakok.github.io/Compose-Multiplatform-Wizard/
Позволяет сразу ознакомиться с списком возможно необходимых библиотек, по ссылкам почитать про них и сразу добавить их если нужно.
Ну и вставить свои я копеек на тему крутости данной технологии.
Занимаюсь мобильной разработкой 3 недели, до этого несколько лет был бэкэнд на python, и в целом сам выбрал Kotlin + Compose multiplatform и мне они в целом нравятся, поэтому поговорю о плохом.
Документация... её нет.
Если надо просто написать приложение любой ценой, это достаточно легко сделать.
Но пытаться разобраться как это работает уже сложнее, да и попасть можно на что то непонятное.
Мне кажется без, в том числе и не верных, подсказок Чат ЖПТ, я бы дольше разбирался.
Собственно на паре примеров:
1) Иконки, из-за которых я и наткнулся на эту статью. Вы прямо пишите "добавить зависимость implementation(compose.materialIconsExtended)".
Но, как я к этому пришел:
Попробовал стандартные иконки из Icons.Default. Подходящих нет.
Нашел нужные иконки в справочнике гугла, для примера signal_cellular_4_bar и signal_cellular_3_bar
В документации по иконкам в самом конце увидел сноску, что нужно добавить зависимость "androidx.compose.material:material-icons-extended ", добавил, сборка развалилась.
Нашел Ишью, в котором иконки починили и написали как правильно добавлять зависимость.
Иконка signal_cellular_4_bar есть а иконки signal_cellular_3_bar нет. Она есть только в виде XML. Пошел гуглить/рисовать самому. Посмотрел в репозитории иконок что творится, ну и собственно наткнулся на этот пост.
Я бы не сказал что это было просто, потому что видимо я хреново гуглю, но почти все мои вопросы по compose multiplatform ведут на документацию обычного compose, а между ними есть различия.
По итогу сейчас думаю что делать с иконками, они все же есть, или не их нарисовать самому, или сгенерировать из XML.
Ну и надо разобраться с R8 / ProGuard , который в документации рекомендуют использовать если имплементируется расширенная библиотека иконок.
2) Влияние порядка написания кода.
Возможно у меня такая проблема потому что я посмотрел несколько вводных занятий от гугла по kotlin и Compose ну и написал мини приложение по ютубу с нужным мне кодом.
На примере:
Box(modifier = Modifier.padding(8.dp).fillMaxWidth().clip(RoundedCornerShape(5.dp)) .background(MESSAGE_COLOR))
Если background у меня будет стоят в этой цепочке перед clip, то все, обрезки углов не будет. К сожалению я это не сразу просек. Сразу полез разбираться смотреть в исходниках и гуглить как работает Modifier вместо того что бы дальше писать код. А вот положение padding и fillMaxWidth на итог рисования не влияют.
И такие мелочи сбивать могут.
Ну или такой пример. Слева в общем виде как я написал сначала. Справа, то во что попробовал переписать сразу после этого. В итоге сидел читал почему так....
+ Некоторые методы помечены как экспериментальные и там надо доп декораторы указывать.
Вобщем весело.
3) И на последок то что меня крайне периодически раздражает в Compose. Это то что я не нашел явный аналог pep8 для него.
Как писать программу. В репозиториях, в примерах из репозитория самого ComposeMultiplatform для меня сейчас в плане структуры сплошной ад и Израиль.
На примере файла, в котором я определяю цвета, где то в файле просто лежат "val MESSAGE_COLOR = Color(0xFFE5FEFB)" а где то они обернуты в object ChatColors {}
Я как бы предполагаю, когда что использовать можно, но четкого гайда так и не нагуглил.
Что значат все эти файлики в корне проекта, в папках платформ и тд, как это все собирается.
Нет одного места где было бы описано, вот так выглядит шаблон проекта, с описанием какой файл за что отвечает, сижу обретаю эти знания по крупицам.
Все эти неудобства инструмента списываю на его молодость и свои знания. Просто написал, что все не так радужно, как часто пишут про данную реализацию мульти платформы. Но в целом пока мне все нравится.
Постараюсь кратко, по сути, ответить, хотя сразу оговорюсь, что к команде Compose Multiplatform в Jb не имею никакого отношения и мои ответы могут не быть solid truth.
1) В compose.MaterialIconsExtended есть самые разные иконки практически на любой вкус. Используйте не только Default, но и Filled/Outlined (я для работы особенно часто пользуюсь Outlined). Кроме того, вы можете подгрузить изображение из ресурсов, с новым API ресурсов в версии 1.4.0 они наконец-то выкатили нормальную поддержку общих ресурсов. Можно грузить XML, PNG, JPG/JPEG, понятное дело, с SVG проблемы.
2) Влияние порядка вызова методов и расширений интерфейса Modifier действительно влияет на отображение, но это поведение не отличается от Android Jetpack Compose, поэтому смело читайте их документацию. Самый разительный пример - в отличие от CSS, в котором margin и padding разные вещи, для Modifier есть только padding. Но если padding применить до background, он будет работать как внешний отступ, а если после - как внутренний. Почему ребята в гугле решили так сделать - мне лично не понятно. Наверное, чтобы можно было наслаивать много padding и background в одном Modifier... Да, и так тоже можно.
То, что на скриншоте: weight - это функция-расширение интерфейса Modifier, которая реализована внутри интерфейса RowScope и ColumnScope. Вне этих интерфейсов она не существует для компилятора. Поэтому weight нужно объявлять в скоупе Row или Column. Как вариант - вы можете сделать Composable-функцию расширением к ColumnScope или RowScope, например
@Composable
fun ColumnScope.DrawView2(viewName: String) {
Box(Modifier.weight(1f)) { // будет работать
...
}
}3) Что касается форматирования кода - в Intellij Idea и Android Studio не нужно возиться с установкой Black Formatter (обожаю его для питона, просто лучший имхо) или чем-то таким. После внесения любых изменений в файл нажмите Ctrl+L и он автоматически отформатируется в соответствии с лушчими практиками. В IDE есть еще настройки форматирования, которые можно кастомизировать. Например, в нашей компании принято включать trailing comma. Не вспомню, где настройки конкретно сейчас, но гуглится легко.
Четыре платформы — один код. Что такое Compose Multiplatform?