Комментарии 4
Если идти во все тяжкие и пытаться дожать оптимальную реализацию дальше, то:
Не очень понятна цель derivedState по всему коду, так как нету операций сокращения итогового множества значений. Это приводит к лишней нагрузке
Не стоит использовать State.value, как ключ к LaunchedEffect. Для треккинга можно snapshotFlow внутри LaunchedEffect слушать. Инвалидировать эффект по ключу на сам стейт (а не на . value). Сейчас может лишний раз рекомпозироваться элемент, даже если это ему не нужно в идеале. В конкретно этом случае не критично
В кастомных лейаутах стоит сперва проверять на ограниченность maxHeight/width через метод hasBounded*, если не хотите в будущем ловить непонятные краши в трудновоспроизводимых кейсах, когда туда придёт бесконечность
DrawWithCache не нужен по сути в том коде. Его для других кейсов используют. В целом можно заменить пустой Box с drawWithCache на Canvas
Это конечно ужас, что такая простая вещь так сложно делается, но это гугл, он в своём репертуара, сделать кучу глупых и сложных фреемворкрв, а потом думать почему андройд такой кривой и из костылей сделан. Я просто вспоминаю как под винлу рисовал кнопки, слайды с анимацией, градиентом и тп, и всё это на winforms, на winforms, Карл! И даже там это выглядело лучше и писалась проще на канвасе, почему мобильная разработка требует таких патуг для простого слайда не понятно
На канвасе проще потому что тогда и требования были другие. Сейчас миллион девайсов, сто разных dpi, всем подавай flex responsive mega puper ui. Если вы сейчас попробуете учесть все нюансы современного ui на winforms, то у вас выйдет compose или Maui со всеми сложностями.
Так и на андроиде можно сделать то же самое просто, в лоб и на канвасе. Просто автор статьи не ищет лёгких путей.
Как мы реализовали кнопку со свайпом на Jetpack Compose