Pull to refresh

Comments 8

Насчет

>При попытке внедрить в существующий проект при компиляции начали вылезать фантомные ошибки Backend Internal error: Exception during IR lowering в классах, которые вообще каким образом не относятся к Compose экранам (довольно досадно, в теории с интероперабельностью все должно быть хорошо).

Это проявляется в multiplatform проектах. Чтобы все завелось нужно прокинуть вручную jar compose компилятора, тут описано как это сделать.

https://github.com/avdim/compose_mpp_workaround

Правда, на последних версиях, и при использовании gradle.kts файлов, мне пришлось добавлять зависимость в compileOnly конфигурацию, а также сделать configurations.compileOnly.get().setCanBeResolved(true).

Как альтернативный вариант, можно сделать

dependencies {

kotlinCompilerPluginClasspath("androidx.compose.compiler:compiler:1.2.0-beta02")

}

Благодарю, исправил)

Супер. Давно ищу более-менее понятный пример с StateFlow and SharedFlow на jetpack compose .

Наткнулся на эту статью по вопросу Что такое Compose? Поистине, все новое - хорошо забытое старое! Это же swing на Котлине:)

Никак не похоже на Java Swing. Compose - он как бы декларативный подход. А Swing - это классический императивный

Не понимаю, почему пошла мода интерфейс в коде описывать. Удобно же было, разметка отдельно, стили отдельно. Сейчас какой-то кучерявый код

Скорее всего, ранее исходили из удобства дизайнеров - HTML -> XML. А потом решили исходить из удобства программистов (пытаясь не сильно сократить удобство дизайнеров - но это вряд ли хорошо удалось) - REACT -> Flutter -> SwiftUI -> Compose.

Просто ранее (ещё лет 20 назад) - дизайн был достаточно сильно отвязан от кода - анимация была простая (в те время рулил Flash или анимированные картинки) - хорошо работали всякие шаблоны MVC, MVVM. Но с развитием HTML5 произошла смена акцентов - во-первых средства дизайна на разных платформах стали унифицироваться (по подходу), и если, ранее, простые формочки для приложений верстали программисты в визуальных средах, то теперь им уже нужно был верстать более профессионально на языке разметки - что им было не удобно; с другой стороны и дизайнерам стало не сладко - дизайн стал слишком кодозависимым и нужно стало осваивать азы программирования, а ещё этот код зачастую становился очень физически отделённым от макетов дизайна, но, при этом, очень сильно с ним связанный. Да и сами языки разметки в лице HTML и XML сильно устарели в плане удобства использования. Вот и начали искать другие пути решения. От Flutter до Compose - единый код, понятный и программистам и дизайнерам, который легко делегировать друг-другу в зависимости от компетенции и требований написать ту или иную визуализацию или UX логику - всё-таки бизнес-логику по-прежнему рекомендуется отделять от UX.

Но пока ещё нет строго доминирования REACT, Flutter, SwiftUI, Compose над более классическими HTML, XML - так что в разных проектах команды ещё могут выбирать более подходящий подход

Sign up to leave a comment.