Pull to refresh

Comments 23

<оффтопик>
возвращение geocities, android edition
</оффтопик>
Если взяться с пространство между ">" и "<" и потащить… Да дотащить до места, где фон не белый, то можно увидеть, что там лежит.
Извините за неудобства. Выделил иконку, как мог, чтобы ее можно было сохранить на свой компьютер и импортировать в проект. Если щелкнуть на пространстве между ">" и "<" правой кнопкой, то можно сохранить изображение.
Для этого вполне бы подошло изображение на тёмном фоне для наглядности и ссылки для скачивания.
Спасибо, отдельная картинка к статье и отдельная для скачивания действительно лучше смотрится. Доработал статью.
Извиняюсь за манеру, в которой вам это преподнёс. Бесъ попутал.
Спасибо! Отличная статья! В полной мере раскрывает работу с селекторами. Не знал про свойства в Button drawableLeft и drawableRight)
Большое спасибо за статью.
Читается очень легко.
В статье по строковым ресурсам вы затронете локализацию приложения? Интересует такой момент, как язык по умолчанию. Если я пишу приложение только на русском языке я могу размещать строки прям в values или я должен разместить всё в values-ru?
Да, расскажу про локализацию и постараюсь подобрать наиболее полезные ссылки на официальную документацию
Если открыть изображения, которые вы используете для фона, в программе draw9patch и выбрать show bad patches, можно увидеть что они (bad patches) присутствуют. Чтобы от них избавится, достаточно слева и сверху указать всего по одному пикселю, вместо полоски на всю ширину/высоту. Вот у меня вопрос, на сколько плохо когда в используемых 9 patch изображениях есть эти bad patches и влияет ли это на скорость отрисовки?
Да по барабану. Все nine-patch на этапе сборки компилируются aapt в свой png, где в метаданных хранятся данные об отсупах. Эти `bad patches` туда просто не попадут, т.к. они не обозначают ничего.
На скорость вроде как не влияет, но в перспективе может возникнуть другая проблема. Когда переносишь проект на Gradle, он не пропускает неправильно сформированные nine-patch изображения и ругается. У меня была такая ситуация, после 7-8 месяцев разработки решил перенести проект на Gradle. Оказалось, что половина графики неправильная, и пришлось править ручками, а это больно)
Давайте посмотрим на доку:
Show bad patches: Adds a red border around patch areas that may produce artifacts in the graphic when stretched. Visual coherence of your stretched image will be maintained if you eliminate all bad patches.
Тут сказано, что «bad patch» может породить артефакт при растягивании. А может и не породить. Этот инструмент не может сказать вам этого точно, он только предупреждает. Когда могут быть артефакты? Например, у нас рамка с градиентом, как в этой статье в button_focused.9.png. Допустим, мы делаем тянущимися 10 пикселей градиента, а содержимое растягивает наш элемент на 100 пикселей. Что мы увидим в результате? Вместо плавного градиента будет 10 полосок шириной по 10 одинаковых пикселей каждая. И наоборот, если градиент будет свернут в 1 пиксель, мы вместо него увидим резкий переход цвета. Это не значит, что «bad patch» в приложении ни в коем случае не должно быть. Просто нужно понимать, что может случиться, и тестировать внешний вид в разных вариантах. Кстати, среди ресурсов в самом Android таких «bad patch» полно.
Доку то я читал, но вот что понимается под словом артефакт мне до сих пор не понятно
Под артефактом тут подразумевают визуальный брак картинки. Сбоев/вылетов/замедления приложения не будет, но часть пикселей из области «bad patch» может пропасть при сжатии. Если все пиксели в тянущейся области одинаковы, как на нашей серой или белой рамках, артефактов не будет никогда. Они возможны, только если тянущаяся область содержит неоднородный рисунок.
А вот на что оно точно повлияет, так это на потребление памяти, так как картинки грузятся целиком. Поэтому да, без необходимости оставлять «bad patches» не стоит.
Мне кажется, более наглядно было было менять цвет самой иконки телефона. Допускаю, что дополнительные иконки были введены исключительно с целью обучения.
Полностью с Вами согласен. Да, статья не про дизайн, и я старался сделать побольше «фишек» для демонстрации имеющихся возможностей.
Добавим в селектор картинки для состояния state_focused и state_pressed:
<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android" >
    <item android:drawable="@drawable/button_focused" android:state_focused="true" />
    <item android:drawable="@drawable/button_pressed" android:state_pressed="true" />
    <item android:drawable="@drawable/button_normal" />
</selector>


Первая ошибка: вначале должно быть pressed, а затем focused, потому что кнопка может одновременно находиться в состоянии pressed и focused. Соответственно если у вас будет кнопка в состоянии focused, то состояние pressed не применится.
Действительно. Исправил, спасибо
Спасибо большое за статью.
Очень интересный и полезный материал как для начинающих программистов, так и для дизайнеров интерфейсов.
Sign up to leave a comment.

Articles