Comments 42
После миграции на устройство с большей плотностью, используя dp, у меня все элементы поехали, а текст стал совершенно других размеров (на взгляд).
По идее наоборот должно быть. Используя dp, у вас на экранах с разной плотностью пикселей, все элементы будут выглядеть одинаково. А вот если указывать все размеры в пикселях, то на экранах с большей плотностью элементы интерфейса будут выглядеть физически меньше.
Supporting multiple screens
Custom components
Внимательно и полностью читайте доки перед тем как писать костыли и учить людей неправильным вещам.
Custom components
Внимательно и полностью читайте доки перед тем как писать костыли и учить людей неправильным вещам.
Прошу прощения, что именно я не правильно написал? Разумеется я знаю и не раз читал, то что там описано.
можно сказать, все статья посвящена тому, чтобы люди не использовали px. используйте dip, density independent pixel.
Если у вас поползла верстка и контролы, это проблема не андроида и производителей, а именно вашей верстки.
Старайтесь чаще использовать RelativeLayout, 9patch, wrap_content, веса, и если нет другого выбора, dip.
Если выносить dipы в разные values папки либо делать картинки под разные плотности экранов, проблем с версткой не будет.
Использовать px в разметке очень плохо.
Если у вас поползла верстка и контролы, это проблема не андроида и производителей, а именно вашей верстки.
Старайтесь чаще использовать RelativeLayout, 9patch, wrap_content, веса, и если нет другого выбора, dip.
Если выносить dipы в разные values папки либо делать картинки под разные плотности экранов, проблем с версткой не будет.
Использовать px в разметке очень плохо.
Верстка у андроида неблагодарная вещь. Я стараюсь вообще уйти от px и dp к процентным отображениям. По крайней мере на всех устройствах будет выглядеть одинаково без лишнего геморроя.
И как же у вас такое получается, если в Андроиде нет понятия процента для Вьюхи?
Или вы имеете ввиду задание атрибута layout_weight?
Или вы имеете ввиду задание атрибута layout_weight?
Не лучшая идея. Вместо того, что бы дать больше места для контента на устройстве с большим экраном — вы просто будете растягивать элементы управления. А учитывая, что только среди телефонов распространены эканы от 2.5 до 5+ инчей причем с разными пропорциями, ваше «выглядит одинаково без лишнего геморроя» — звучит наивно.
Весь абзац про Dimensions — в топку. Использование px оправдано только в одном случае — если вы рисуете на чем-то вроде SurfaceView и при масштабировании опираетесь на конкретное разрешение экрана. В остальных случаях у вас элемент, который занимает пол-экрана на 320*480, будет где-то в уголке на планшете.
Dp был сделан как независимый от устройства пиксель, и он работает, но с одной оговоркой — он хорошо масштабирует на тех наборах устройств, где разрешение и dpi возрастают примерно в равных пропорциях. Беда в том, что большинство производителей болт клали на рекомендации Гугла и в результате этого, текст который у меня выражен в dp и занимает 10% от высоты экрана на эмуляторе среднего телефона, на планшете реально занимает уже 4-5%. Соотношение размеров экрана и dpi нарушено, и все рухнуло. Решение — выносить все такие величины в стили, а файлы стилей также как и layout разносить по разным папкам с классификаторами, чтобы он подгружал тот стиль, который нужно. Муторная очень работа и, как правило, все косяки не исправишь, но самое гибкое и универсальное решение.
Dp был сделан как независимый от устройства пиксель, и он работает, но с одной оговоркой — он хорошо масштабирует на тех наборах устройств, где разрешение и dpi возрастают примерно в равных пропорциях. Беда в том, что большинство производителей болт клали на рекомендации Гугла и в результате этого, текст который у меня выражен в dp и занимает 10% от высоты экрана на эмуляторе среднего телефона, на планшете реально занимает уже 4-5%. Соотношение размеров экрана и dpi нарушено, и все рухнуло. Решение — выносить все такие величины в стили, а файлы стилей также как и layout разносить по разным папкам с классификаторами, чтобы он подгружал тот стиль, который нужно. Муторная очень работа и, как правило, все косяки не исправишь, но самое гибкое и универсальное решение.
Намучавшись с layout и дизайнами. Я пришел к выводу, что буду делать hdpi-standard = mdpi-large. То есть все ресурсы high-def использую для больших экранов. Layout для большего экрана тупо умножаю на 1.5. Получается выглядит по размеру практически одинаково для на стандартных экранах и больших.
Естественно это не везде подходит и high-def большие экраны в пролете (для них все равно надо рисовать ресурсы отдельно или будут масштабироваться). В большем случаев мне кажется это нормально, так как растягивать с телефона на планшет выглядит как-то не очень :) Особенно кнопки на весь экран.
Естественно это не везде подходит и high-def большие экраны в пролете (для них все равно надо рисовать ресурсы отдельно или будут масштабироваться). В большем случаев мне кажется это нормально, так как растягивать с телефона на планшет выглядит как-то не очень :) Особенно кнопки на весь экран.
Согласен. У меня не много другая ситуация, и говорю просто по опыту. Было 3 устройства с одинаковым разрешением, но разные версии андроида и производители. С DP все уехало в стороны, с PX все на месте. Так же молчу, что в 2.3 hdpi это mdpi в 4.0 (папки). Тоже проблема. Тут думаю больше подойдет к какой-то определенной задаче, определенное решение.
Что-то вы наверное неверно поняли про «что в 2.3 hdpi это mdpi в 4.0». Скорее всего у вас просто у девайсов были разные размеры экрана — от этого и плотность разная была. Вот тут все хорошо описано — developer.android.com/guide/practices/screens_support.html
Текст в dp? Текст должен быть в sp, потому наверное и ползет разметка.
От этого верстка точно не поползет, скорее наоборот — sp это тот же dp, только учитывающий размер шрифта, заданный пользователем в настройках системы.
ну тогда надо ставить
minHeight
gravity=center
и padding
тогда ни где ничего не будет наезжать друг на друга
minHeight
gravity=center
и padding
тогда ни где ничего не будет наезжать друг на друга
Ну или грамотно использовать RelativeLayout. А то самая частая ошибка что я встречал это когда выравнивают один элемент по левому краю родительского, второй — по правому, а третий — по центру, а надо бы правее первого и левее второго…
В таком случае проще и лучше использовать LinearLayout
Не всегда. Сам раньше лепил LinearLayout направо и налево. Все же RelativeLayout намного универсальнее. А вообще — каждому из Layout-ов находится свое место.
RelativeLayout выгоден в большинстве случаев если надо и вертикально и горизонтально элементы разместить, если же элементы расположены только горизонтально или только вертикально, то это 100% LinearLayout + веса.
В общем использовать в зависимоти от ситуации, в каждом случае тот лэйаут который подходит больше.
В общем использовать в зависимоти от ситуации, в каждом случае тот лэйаут который подходит больше.
Ну а вообще, лучший вариант — это, конечно, делать различный дизайн для различных размеров экранов. Потому что некоторые элементы интерфейса, которые уместны для большого экрана, вполне можно вынести, например, в меню для маленького — для лучшего восприятия основной информации. Потому что если дизайн сложный — трудно добиться одинакового восприятия на различных устройствах. Такой «универсализм» приводит к тому, что приложение и там и там смотрится не очень.
спасибо, неплохая статья. если позволите, от себя добавлю, так как я наступал на точно такие же грабли.
я отказался от папок layout без указания размера экрана. совсем отказался, так как вёрстка под телефон ужасно выглядит на планшете (либо сжимается в углу, либо уродливо растягивается на весь экран с кучей свободного места). вёрстка же для планшета на телефоне превращается в кучу закрывающих друг-друга контролов.
сейчас у меня в проектах вёрстки layout-small (мелкие телефончики), layout-normal (большая часть современных телефонов), layout-large (большая часть планшетов и Galaxy Note) и layout-xlarge (большие планшеты, типа Galaxy Tab). конечно, работы получается в 4 раза больше, но зато экран любого устройства используется полностью. и да, для каждой из 4-х указанных папок картинки в нескольких плотностях, например drawable-normal-mdpi, drawable-normal-hdpi, drawable-xlarge-mdpi и т.д. размеры экрана и плотности берутся на основе статистики
я отказался от папок layout без указания размера экрана. совсем отказался, так как вёрстка под телефон ужасно выглядит на планшете (либо сжимается в углу, либо уродливо растягивается на весь экран с кучей свободного места). вёрстка же для планшета на телефоне превращается в кучу закрывающих друг-друга контролов.
сейчас у меня в проектах вёрстки layout-small (мелкие телефончики), layout-normal (большая часть современных телефонов), layout-large (большая часть планшетов и Galaxy Note) и layout-xlarge (большие планшеты, типа Galaxy Tab). конечно, работы получается в 4 раза больше, но зато экран любого устройства используется полностью. и да, для каждой из 4-х указанных папок картинки в нескольких плотностях, например drawable-normal-mdpi, drawable-normal-hdpi, drawable-xlarge-mdpi и т.д. размеры экрана и плотности берутся на основе статистики
textSize в dp, не в sp, верно? ОООООООООООООООК.
> Как оказалось, используй я с самого начала px везде и игнорируй предупреждения Lint, я бы не тратил дополнительное время на переписывание dp на px.
Ну да, как же.
А теперь представим, что вы указали высоту панели в 80px, да это отлично будет смотрется на устройствах ~800х480, зато будет выглядеть как крошечная полоска на том же Galaxy nexus с его xhdpi (1280 x 720)
А теперь смотрим, если бы вы указали размер в dp, то ваши 80пикселов на mdpi, превратились бы в 80*320/160 = 160px, что на деле уже выглядит намного лучше, чем фиксированный размер в пикселах.
Cсобственно та же история с ldpi, hdpi и тд.
Ну да, как же.
А теперь представим, что вы указали высоту панели в 80px, да это отлично будет смотрется на устройствах ~800х480, зато будет выглядеть как крошечная полоска на том же Galaxy nexus с его xhdpi (1280 x 720)
А теперь смотрим, если бы вы указали размер в dp, то ваши 80пикселов на mdpi, превратились бы в 80*320/160 = 160px, что на деле уже выглядит намного лучше, чем фиксированный размер в пикселах.
Cсобственно та же история с ldpi, hdpi и тд.
Согласен. Но факт остается фактом. Я пытался уточнить в статье:
> Если сильно не углубляться в разнообразие устройств на рынке, что в моем случае так и вышло, есть платформа Android какой-то версии, знаем размер экрана целевого устройства. Допустим у вас такая же ситуация.
Уже столько комментариев про dp/xp, думаю я и остальные хабралюди сделали вывод. Заминусовали конечно, ну да ладно. Странно, что нет комментариев на счет Custom Views.
> Если сильно не углубляться в разнообразие устройств на рынке, что в моем случае так и вышло, есть платформа Android какой-то версии, знаем размер экрана целевого устройства. Допустим у вас такая же ситуация.
Уже столько комментариев про dp/xp, думаю я и остальные хабралюди сделали вывод. Заминусовали конечно, ну да ладно. Странно, что нет комментариев на счет Custom Views.
А что там комментировать? Ну создали пустой вью и какой то аттрибут, чего обсуждать то?
Если вас еще не хватает критики, то вот:
> По моим наблюдениям и тому, что приходилось использовать, есть такой список format (тип свойства):…
Какие еще наблюдения?
Откройте документацию, там все про все подробно расписано, это не что то секретное.
Если вас еще не хватает критики, то вот:
> По моим наблюдениям и тому, что приходилось использовать, есть такой список format (тип свойства):…
Какие еще наблюдения?
Откройте документацию, там все про все подробно расписано, это не что то секретное.
Я наверное плохо искал, но могли бы вы указать о какой документации вы говорите, где можно посмотреть весь список доступных format? Я только находил в исходных кодах Android.
А я все таки еще раз спрошу, поделитесь ссылкой где описаны все значения для format для declare-styleable. То что вы мне предложили не описывает declare-styleable. Раз вы так любите критиковать, то пожалуйста подкрепите вашу критику:
> Какие еще наблюдения?
Откройте документацию, там все про все подробно расписано, это не что то секретное.
> Какие еще наблюдения?
Откройте документацию, там все про все подробно расписано, это не что то секретное.
Да вы правы конкретно declare-styleable не описаны(косяк документации), но сами типы описаны.
А значения для атрибута format впринципе все можно найти в samples в android sdk:
format: color, dimensions, integer, string, reference, и уже описание самих типов, находится по ссылкам выше.
В примерах так же встречается enum, и раз уж вы начали писать про attrs и declare-styleable, тоже не плохо было бы enum упомянуть.
А значения для атрибута format впринципе все можно найти в samples в android sdk:
format: color, dimensions, integer, string, reference, и уже описание самих типов, находится по ссылкам выше.
В примерах так же встречается enum, и раз уж вы начали писать про attrs и declare-styleable, тоже не плохо было бы enum упомянуть.
О так вы много еще типов пропустили:
* color
* float
* boolean
* fraction (api 11)
* enum
* flag
И нет информации о том, что типы в format можно совмещать.
Например, если нам надо использовать цвет или drawable в качестве фона:
/>
или если только цвет:
/>
Так же нет информации о том, что если аттрибут существует, его можно переиспользовать, без указания format. Можно использовать как свои уже ранее описанные, так и все android:*
зы На вашем месте я бы переписал статью заново.
* color
* float
* boolean
* fraction (api 11)
* enum
* flag
И нет информации о том, что типы в format можно совмещать.
Например, если нам надо использовать цвет или drawable в качестве фона:
/>
или если только цвет:
/>
Так же нет информации о том, что если аттрибут существует, его можно переиспользовать, без указания format. Можно использовать как свои уже ранее описанные, так и все android:*
зы На вашем месте я бы переписал статью заново.
Особенно обратите внимание на dimensions, у вас даже половина из возможных значений не написана:
Dimension: dp, sp, pt, px, mm, in
Dimension: dp, sp, pt, px, mm, in
После первого запуска на устройстве определите размер экрана, вычислите положения всех контролов в пикселях и где-нибудь закешируйте раз и навсегда.
Шутка, но…
Шутка, но…
Sign up to leave a comment.
Android. Заметка на будущее