Просто так 2 раздельные программы очень мало вероятно могут устроить друг другу блокировку, из-за особенностей работы ОС. Я не могу сейчас придумать кейс, в которой я бы написал ПО, которое взаимно блокировалось бы с каким то другим ПО на компьютере.
Описанные случаи, на мой взгляд, подходят в основном для ситуаций, когда разработчики намеренно делают работу задач в разных потоках с доступом к одним данным. В таком случае они должны понимать чем это грозит и как с этим бороться.
Соответственно чего мне не хватило в статье:
1) Описание как работает многопоточность в ОС. Несмотря на имеющиеся знания с удовольствием почитал бы, но здесь для вступления, исключительно на мой взгляд, написано слишком много, а для полноценного описания слишком мало. Все же данная темя тянет на самостоятельную статью.
2) Собственно мне не хватило информации о многопоточности в практическом программировании.
Я условно разделяю проблемы с доступом к одной области памяти разных потоков на те же категории что и при работе с одними и теми же данными в БД. Только при работе с БД я использую транзакции и проблему за меня решает СУБД в соответствии с уровнем транзакции.
А вот при написании приложения, подразумевающего совместное использование области памяти, решение проблем ложится в большей степени на мои плечи.
Поэтому здесь мне не хватило того что описаны не все проблемы.
И самое главное что не описаны какие либо паттерны их решения.
Позволяет сразу ознакомиться с списком возможно необходимых библиотек, по ссылкам почитать про них и сразу добавить их если нужно.
Ну и вставить свои я копеек на тему крутости данной технологии.
Занимаюсь мобильной разработкой 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 ну и написал мини приложение по ютубу с нужным мне кодом.
Если background у меня будет стоят в этой цепочке перед clip, то все, обрезки углов не будет. К сожалению я это не сразу просек. Сразу полез разбираться смотреть в исходниках и гуглить как работает Modifier вместо того что бы дальше писать код. А вот положение padding и fillMaxWidth на итог рисования не влияют.
И такие мелочи сбивать могут.
Ну или такой пример. Слева в общем виде как я написал сначала. Справа, то во что попробовал переписать сразу после этого. В итоге сидел читал почему так....
+ Некоторые методы помечены как экспериментальные и там надо доп декораторы указывать.
Вобщем весело.
3) И на последок то что меня крайне периодически раздражает в Compose. Это то что я не нашел явный аналог pep8 для него.
Как писать программу. В репозиториях, в примерах из репозитория самого ComposeMultiplatform для меня сейчас в плане структуры сплошной ад и Израиль.
На примере файла, в котором я определяю цвета, где то в файле просто лежат "val MESSAGE_COLOR = Color(0xFFE5FEFB)" а где то они обернуты в object ChatColors {}
Я как бы предполагаю, когда что использовать можно, но четкого гайда так и не нагуглил.
Что значат все эти файлики в корне проекта, в папках платформ и тд, как это все собирается.
Нет одного места где было бы описано, вот так выглядит шаблон проекта, с описанием какой файл за что отвечает, сижу обретаю эти знания по крупицам.
Все эти неудобства инструмента списываю на его молодость и свои знания. Просто написал, что все не так радужно, как часто пишут про данную реализацию мульти платформы. Но в целом пока мне все нравится.
Просто так 2 раздельные программы очень мало вероятно могут устроить друг другу блокировку, из-за особенностей работы ОС. Я не могу сейчас придумать кейс, в которой я бы написал ПО, которое взаимно блокировалось бы с каким то другим ПО на компьютере.
Описанные случаи, на мой взгляд, подходят в основном для ситуаций, когда разработчики намеренно делают работу задач в разных потоках с доступом к одним данным. В таком случае они должны понимать чем это грозит и как с этим бороться.
Соответственно чего мне не хватило в статье:
1) Описание как работает многопоточность в ОС. Несмотря на имеющиеся знания с удовольствием почитал бы, но здесь для вступления, исключительно на мой взгляд, написано слишком много, а для полноценного описания слишком мало. Все же данная темя тянет на самостоятельную статью.
2) Собственно мне не хватило информации о многопоточности в практическом программировании.
Я условно разделяю проблемы с доступом к одной области памяти разных потоков на те же категории что и при работе с одними и теми же данными в БД. Только при работе с БД я использую транзакции и проблему за меня решает СУБД в соответствии с уровнем транзакции.
А вот при написании приложения, подразумевающего совместное использование области памяти, решение проблем ложится в большей степени на мои плечи.
Поэтому здесь мне не хватило того что описаны не все проблемы.
И самое главное что не описаны какие либо паттерны их решения.
Подожду продолжения.
Добрый день. Хотелось бы добавить что для создания проекта можно использовать еще и такой инструмент:
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 {}
Я как бы предполагаю, когда что использовать можно, но четкого гайда так и не нагуглил.
Что значат все эти файлики в корне проекта, в папках платформ и тд, как это все собирается.
Нет одного места где было бы описано, вот так выглядит шаблон проекта, с описанием какой файл за что отвечает, сижу обретаю эти знания по крупицам.
Все эти неудобства инструмента списываю на его молодость и свои знания. Просто написал, что все не так радужно, как часто пишут про данную реализацию мульти платформы. Но в целом пока мне все нравится.