Уже нет смысла использовать имутабельные коллекции. Теперь можно указать Compose через настройку какие классы будут стабильными, про чем глобально для всего проекта. то есть указывать аннотацию @Stable для всех моделек уже можно не надо
В статье описана обычная Scara - та самая промышленная робо-рука, которую можно увидеть на всяких демострациях и выставках; и Morgan-scara. При этом в morgan объединили и morgan и 5bar (на скрине как раз она). А морган хоть и параллельная, но имеет одно отличие от 5 bar, у нее основания плеч имеют общую ось вращения (по сути улучшенная обычная scara). Почему решили мучиться с Marlin? На мой скромный взгляд худший выбор из-за ее архитектуры. Та же smoothieware куда приятнее в обращении и уже имеет ее поддержку (с нее я начал когда строил свой 3d-printer на scara), еще есть RepRapFirmware, в которой поддержка скары еще лучше, чем в смузи и марлине. Почему-то у вас Prusa имеет лучшую точность, повторяемость и скорость, чем кубик. Из-за подвижного стола (из-за этого его и зовут дрыгостолом) он имеет меньшую скорость в сравнении с кубиком.
А линейные дельты не такой уж и большой объем для печати предоставляют для печати в сравнении с размером. Они очень высокие, и область печати имеет цилиндрическую форму.
Скорее не лямбду для какой-то extension-функции, а обработку в едином for-цикле. Такой код явно не будет очень удобным для чтения и выглядить будет так себе, но интересно именно какой оверхед несут extension-функции для списков. Все же каждая такая функция создает новый список и более сложные преобразования. Таким вопросом давно задаюсь, но сам так и не проверил. Но даже не смотря на результаты переставать пользоваться этими удобными функциями не перестану, с ними код чище и более читаем.
Жаль что нет сравнения с ручным преобразованием списком, без удобных операторов котлина. Был бы значительный прирост в производительности, если не было лишних созданий списков?
На php не все так ужасно, как на том же python. После kotlin/java думал что на php будет совсем боль из-за типизации, но оказалось, что все не так уж и плохо, даже захотелось в kotlin возможность вернуть из функции два разных типа данных aka string|bool. А возможности phpstorm просто невероятно помогают разобраться в чужом и своем коде, после vscode, который ощущался просто текстовым редактором с подсветкой.
Спасибо за статью. Так как я и сам уже писал плагин для idea, мне интересно где вы черпали информацию? В оф. доках весьма мало информации, и в интернете найти что-то сложно.
Проверьте какая у вас версия студии. Поиск по тексту по double shift точно есть в последней Canary, но в предыдущих версиях я его не замечал (это вкладка Text). Без этой вкладки он ищет по названиям классов, названиям файлов, что понимается под Symbols не знаю, но туда попадают id ресурсов строк. Поиск по тексту не работает в этом поиске, поэтому найти что-то рандомное в нем не выйдет, как например содержимое ресурса. Вот здесь и нужен был Find In Place.
А почему поиск по double shift обозван как умный поиск в отличии от Find In Files?
Первый удобен для быстрого поиска классов и файлов по названию, а также actions, которые может выполнить в ide. Так же он работает как и поиск по тексту, но у эти результаты ниже всех других вариантов (этот пункт есть в последней Canary). Он не грузит сразу весь список результатов, и нельзя увидеть где именно в файле находится найденный результат.
Это скорее быстрый поиск по файлам/классам (так я его для себя позиционирую и использую). Два раза тапнул по shift, вбил то что ищешь, если вверху нет того что надо, то проще перейти в Find In Files. И вот как раз второй удобен тем, что есть сразу весь список результатов, с возможностью предосмотра файла. И находясь в нем легко перейти в режим Replace In Files и сразу произвести замену. Если очень надо.
Порекомендовал бы использовать для перехода не такие ссылки navController.navigate("$route/$json"),а navController.navigate("$route?itemName=$json").Второй способ хорош тем, что если в строке с данными присутствует "/" то приложение не упадет с ошибкой навигации. А что плохого в навигации через строки?
По моему это самый не удобный способ навигации, что попадался в интернете:
Во-первых, каждая feature предпологает быть обособленной и не знать ничего о других модулях, но при такой реализации, каждая фича должна явно указывать в какую фичу она хочет перейти в методе NavHostController.navigate("route"). Разве это не плохо?
Во-вторых, как это выглядит со вложенной навигацией?
Неужели так плохо когда навигация знает о всей навигации? Зачем ее размазывать по всем модулям?
Классический вариант с arguments мне известен. И он работает на 100%.
Фабрики, что добавил Google для Fragments, во факту такую задачу решить не могут, так как в большинстве случаев передаваемые аргументы не известны, в момент создания фрагмента (при условии, что вы используете Single Activity). Если у вас каждый Fragment имеет свою Activity и вы в Activity передаете эти самые аргументы, то такой способ подходит отлично.
Выглядит красиво и удобно. Но как быть с передачей аргументов во фрагменты, если они были получены после создания Activity (например, через интернет запроса)?
Не секрет. Realme 5 pro. Не новый, но и не слабый. В проекте где пытался его применить, уже используется MotionLayout на одном экране, тормозов при этом у себя я не наблюдаю, но работает немного странно
Сколько не смотрю туториалы по MotionLayout, все время восторгаюсь, как же все классно выглядит и легко настраивается. Но как только пытаешься сам, что-то сделать, то выясняется что в AndroidStudio (Canary) MotionEditor не работает, нельзя просмотреть анимацию. А если и смог сделать, то она жутко тормозит. Пока одни негативные впечатления.
Получить текущее состояние у Flow можно, надо вызвать first(). Но это suspend функция, что не всегда удобно, не могу не согласиться. Но значение по умолчанию, всегда надо передавать в StateFlow. Поэтому достаточно вызвать stateIn у любой Flow. За своей функцией это можно скрыть, но это дело привычки. Про derivedStateOf не поверю, ибо только на днях с ним экспериментировал.
Вы не написали про 3 способ как избежать проблем со стабильностью:
Прописать нужные типы в конфигурационом файле (ссылка).
Уже нет смысла использовать имутабельные коллекции. Теперь можно указать Compose через настройку какие классы будут стабильными, про чем глобально для всего проекта. то есть указывать аннотацию
@Stableдля всех моделек уже можно не надоВ статье описана обычная Scara - та самая промышленная робо-рука, которую можно увидеть на всяких демострациях и выставках; и Morgan-scara. При этом в morgan объединили и morgan и 5bar (на скрине как раз она). А морган хоть и параллельная, но имеет одно отличие от 5 bar, у нее основания плеч имеют общую ось вращения (по сути улучшенная обычная scara).
Почему решили мучиться с Marlin? На мой скромный взгляд худший выбор из-за ее архитектуры. Та же smoothieware куда приятнее в обращении и уже имеет ее поддержку (с нее я начал когда строил свой 3d-printer на scara), еще есть RepRapFirmware, в которой поддержка скары еще лучше, чем в смузи и марлине.
Почему-то у вас Prusa имеет лучшую точность, повторяемость и скорость, чем кубик. Из-за подвижного стола (из-за этого его и зовут дрыгостолом) он имеет меньшую скорость в сравнении с кубиком.
А линейные дельты не такой уж и большой объем для печати предоставляют для печати в сравнении с размером. Они очень высокие, и область печати имеет цилиндрическую форму.
Или напиши в несколько разных преобразований, а ide пишет тебе, мол что ты делаешь, можно сократить парочку extensions в один )
Скорее не лямбду для какой-то extension-функции, а обработку в едином for-цикле. Такой код явно не будет очень удобным для чтения и выглядить будет так себе, но интересно именно какой оверхед несут extension-функции для списков. Все же каждая такая функция создает новый список и более сложные преобразования. Таким вопросом давно задаюсь, но сам так и не проверил.
Но даже не смотря на результаты переставать пользоваться этими удобными функциями не перестану, с ними код чище и более читаем.
Классная статья! Очень познавательно.
Жаль что нет сравнения с ручным преобразованием списком, без удобных операторов котлина. Был бы значительный прирост в производительности, если не было лишних созданий списков?
На php не все так ужасно, как на том же python. После kotlin/java думал что на php будет совсем боль из-за типизации, но оказалось, что все не так уж и плохо, даже захотелось в kotlin возможность вернуть из функции два разных типа данных aka string|bool. А возможности phpstorm просто невероятно помогают разобраться в чужом и своем коде, после vscode, который ощущался просто текстовым редактором с подсветкой.
Спасибо за статью. Так как я и сам уже писал плагин для idea, мне интересно где вы черпали информацию? В оф. доках весьма мало информации, и в интернете найти что-то сложно.
Спасибо! Не думал, что все настолько банально.
Проверьте какая у вас версия студии. Поиск по тексту по double shift точно есть в последней Canary, но в предыдущих версиях я его не замечал (это вкладка Text).
Без этой вкладки он ищет по названиям классов, названиям файлов, что понимается под Symbols не знаю, но туда попадают id ресурсов строк. Поиск по тексту не работает в этом поиске, поэтому найти что-то рандомное в нем не выйдет, как например содержимое ресурса. Вот здесь и нужен был Find In Place.
А почему поиск по double shift обозван как умный поиск в отличии от Find In Files?
Первый удобен для быстрого поиска классов и файлов по названию, а также actions, которые может выполнить в ide. Так же он работает как и поиск по тексту, но у эти результаты ниже всех других вариантов (этот пункт есть в последней Canary). Он не грузит сразу весь список результатов, и нельзя увидеть где именно в файле находится найденный результат.
Это скорее быстрый поиск по файлам/классам (так я его для себя позиционирую и использую). Два раза тапнул по shift, вбил то что ищешь, если вверху нет того что надо, то проще перейти в Find In Files.
И вот как раз второй удобен тем, что есть сразу весь список результатов, с возможностью предосмотра файла. И находясь в нем легко перейти в режим Replace In Files и сразу произвести замену. Если очень надо.
Позволяют использовать State который возвращают данные функции, без вызовов value.
Например в таком выражении:
val number by remember { mutableStateOf(5) }при обращении к
numberбудете получать5,без делегата пришлось бы обращаться такnumber.valueПорекомендовал бы использовать для перехода не такие ссылки
navController.navigate("$route/$json"),аnavController.navigate("$route?itemName=$json").Второй способ хорош тем, что если в строке с данными присутствует "/" то приложение не упадет с ошибкой навигации.А что плохого в навигации через строки?
По моему это самый не удобный способ навигации, что попадался в интернете:
Во-первых, каждая feature предпологает быть обособленной и не знать ничего о других модулях, но при такой реализации, каждая фича должна явно указывать в какую фичу она хочет перейти в методе
NavHostController.navigate("route").Разве это не плохо?Во-вторых, как это выглядит со вложенной навигацией?
Неужели так плохо когда навигация знает о всей навигации? Зачем ее размазывать по всем модулям?
Классический вариант с arguments мне известен. И он работает на 100%.
Фабрики, что добавил Google для Fragments, во факту такую задачу решить не могут, так как в большинстве случаев передаваемые аргументы не известны, в момент создания фрагмента (при условии, что вы используете Single Activity). Если у вас каждый Fragment имеет свою Activity и вы в Activity передаете эти самые аргументы, то такой способ подходит отлично.
Выглядит красиво и удобно. Но как быть с передачей аргументов во фрагменты, если они были получены после создания Activity (например, через интернет запроса)?
Не секрет. Realme 5 pro. Не новый, но и не слабый. В проекте где пытался его применить, уже используется MotionLayout на одном экране, тормозов при этом у себя я не наблюдаю, но работает немного странно
Хорошо, когда так. Но у меня простая анимация по скрытию одного элемента, тормозила ужасно на устройстве
Сколько не смотрю туториалы по MotionLayout, все время восторгаюсь, как же все классно выглядит и легко настраивается.
Но как только пытаешься сам, что-то сделать, то выясняется что в AndroidStudio (Canary) MotionEditor не работает, нельзя просмотреть анимацию. А если и смог сделать, то она жутко тормозит. Пока одни негативные впечатления.
Получить текущее состояние у
Flowможно, надо вызватьfirst(). Но этоsuspendфункция, что не всегда удобно, не могу не согласиться. Но значение по умолчанию, всегда надо передавать вStateFlow. Поэтому достаточно вызватьstateInу любойFlow. За своей функцией это можно скрыть, но это дело привычки.Про
derivedStateOfне поверю, ибо только на днях с ним экспериментировал.