Pull to refresh

Comments 12

Замечательно и очень интересно. Спасибо.
Вообще я это уже все освоил давно. Но так гладко написано, — что обе статьи прочитал :)
Все хорошо, но немного добавлю.

1. Вдруг у меня в стилях нет AppTheme? Не пхохо бы написать, как и где этот стиль применяется. Что в AndroidManifest.xml, тег application и тд

2. Зачем же корневому элементу в разметке меняете цвет, хотите поиметь проблем с overdraw?
Цвет должен быть применен к окну, а не к элементу разметки, иначе, цвет будет отрисован 2 раза, первый раз, цвет окна, и второй раз цвет вашей активити. Или же надо убрать цвет у окна, но тогда точно удостоверится, что элемент с цветом покрывает весь экран.

3. >> Созданный нами стиль не наследуется от стиля кнопок, а это значит, что наш элемент управления потерял способность нажиматься.
Нет, это потому что атрибут android:clickable=false. Или потому что OnClickListener нет на кнопке.

Вообще, имхо, лучше не наследоваться от 2.х стилей, а если уж делаете свой стиль, делать его полностью. Так вы можете быть уверенными, что выглядеть будет на всех устройствах одинаково. Потому что производитель устройства, мог посчитать нужным поменять что то в стиле, а вы, например, забыли этот атрибут переопределить, в итоге, на этом устройстве, будет выглядеть не так как задумано.

4. >> Что такое android:buttonStyleToggle, что еще можно стилизовать, и где об этом почитать?
Это атрибут, что бы абстрагироваться от конкретного стиля. Почти у каждого View есть свой. Можно пробовать смотреть в документацию к R.attr и там их искать, или проще открыть исходник того же ToggleButton и там будет имя атрибута стиля, а так же все другие атрибуты специфичные конкретно для этого элемента.

5. >> Если бы не стили, мне пришлось бы копировать оформление окон по 40 раз, и если дизайнеры придумают что-то новое, мне пришлось бы 40 раз этот код менять.
Если оформление вообще одно и тоже, то можно проще. Делаете одну активити с базовым оформление, и все остальные наследуете от нее, и уже добавляете только разметку с содержимым. Но это при условии что вам нужно стилизовать именно базовую разметку, отступы для контента и тд.
Если это стилизация окна, которая может быть сделана через стили. То тогда, соответственно, ничего этого вообще не нужно, а нужен только отдельный стиль для активити, с цветом для фона, actionbar и тд.
Спасибо за Ваш комментарий, обязательно учту при доработке статьи
У меня одного в стилях лежат удобные заготовки под названием «fill_fill», «fill_wrap», «wrap_fill», «wrap_wrap»?
кажется да.
На мой взгляд это не совсем удобно и не гибко, если я Вас правильно понял.
На самом деле это очень удобно. Естественно файл со стилями не ограничивается только этими четырьмя, но именно эти используются чаще всего. К примеру для ващего случая:

Для стиля styleActivity был бы назначен parent=«fill_fill»

и разметка RelativeLayout сократилась бы до 1 строчки. И если бы надо было поменять к примеру android:layout_height=«match_parent» на android:layout_height=«wrap_content» — мы бы просто поменяли на «fill_wrap».

Безусловно, однако представьте большое приложение, где один стиль может быть применен на компоненты c ралзличными layout_width и layout_height.

Если попытаться применить Ваш подход, то появится дублирование кода. Если сделать исключение, то код будет не однородным. Все это может привести к путанице.

«где один стиль может быть применен на компоненты c ралзличными layout_width и layout_height.» — тогда этот стиль не должен определять layout_width и layout_height. (соответсвенно не надо наследовать от указаных стилей). Но таких случаев единицы.

Если применять мой подход, то как раз мы уйдем от разростания кода, тк каждый View должен определять layout_width и layout_height в обязательном порядке. И добиваемся сокращения:

Было:

android:layout_width=«match_parent»
android:layout_height=«wrap_content»

Стало:

style="@ style/wrap_wrap"

Если вы до сих пор не увидели профит — я не знаю, чем вам больше помочь.

Чувак, долго ты добирался до статьи… :)
Sign up to leave a comment.

Articles