Где вы храните text size in sp в Dimens or

Typography ?

Typography как-раз для этого и сделана.

Я имел ввиду если мне нужно кастомный размер текста засетить Где мне это все хранить в dimens как юзали в xml или в Typography создавать кастомный класс и туда уже передавать default Typography, где все h1,h2 etc. стили и свой кастомный object, где будут уже храниться мои кастомные рахмеры

я заюзал xml, было бы тоже интересно узнать есть ли другой способ

style = … .copy(fontSize = *…*.sp)

Зачем кастомный класс?

Есть много разных возможных вариантов если просто подстраивать под разные экраны размеры, то нужно 2 val чтоб были - val smallTextDimens and val sw360TextDimens ну или что-то в этом роде по аналогии примера с обычными dimens https://proandroiddev.com/supporting-different-screen-sizes-on-android-with-jetpack-compose-f215c13081bd А просто прописывать кастомный размер в самом тексте я не хотел, но если так подумать, то называть размер в Dimens - val textSize13 тоже печалька У меня в проекте одном, где еще xml юзался были custom размеры и имена были - <dimen name="size_45dp">45dp</dimen> Что по сути не имеет смысле Поэтому здесь мне даже интересно как вы прописываете такое в проекте ? И да. кто-то мне когда-то говорил, что стандартных размеров typography хватает на весь проект. У меня точно не хватит по причине сильной кастомизации дизайна

если вам не хватает стандартных типов в Typography, можно расширить этот класс своими собственными типами, как описано здесь https://developer.android.com/jetpack/compose/themes/custom#extending-material

вот именно, нахрена эти димены

Затем, что, вероятно, в его кейсе не хватает тех типов, которые описываются в материале.

да я уже понял, но думаю нужно сначала посмотреть на дизайн, может будет достаточно другого

Если нужны различные значния, под разные типы — то ресурсы (dimens) будут попроще. Дальше либо использовать их напрямую, либо создавать тему на основе данных из ресурсов. size45dp, конечно, звучит как глупость. Суть ресурсов в осмысленности значений. В целом, я бы советовал тогда расширять нужные классы под свои нужды (выше уже дважды давали ссылку на то, как это сделать) и заполнять их значениями из ресурсов. Нейминг в целом будет одинаковый, что в ресурсах, что в своей теме. Но точно не слушайте тех, кто говорит вам «хардкорьте и всё». Вероятно, они не работали с серьезными дизайн-системами.

Насколько я понял вы если создавать кастомный размер без здравого названия нет смысла - тоже хардколите ? Имею ввиду если размер текста/или тот же padding на 3 разных экранах в приложении будет разный - то тут можно и за хардкодить Правильно я понял ?

Да. Впадать в крайности не нужно. Если нет единой системы — то и выносить всё подряд не обязательно. Считаю, что нужно выдерживать баланс в систематизации и удобстве. Но обычно, если на похожих элементах\экранах не соответствуют значения — это ошибка\неопытность дизайнера.

Спасибо большое

Ну это конечно странно выглядит ._. Смысл вообще от таких переменных?

Писать больше букавок)