Комментарии 47
Никогда не уделял гайдлайнам достаточно внимания, считая их скучными и неинтереснымиУвы, автор не одинок.
НЛО прилетело и опубликовало эту надпись здесь
Тут все просто, если по таблице, то почти для всех dpi смотреть экраны normal (кроме ldpi). Таким образом получаем:
только xhdpi выбивается из «пропорционального» масштабирования, так как разрешение 640 я не припомню, а 720 является самым распрастраненым.
- ldpi — 240х320
- mdpi — 320х480
- hdpi — 480х800
- xhdpi — 640х960 (но тут лучше все же 720x1280)
только xhdpi выбивается из «пропорционального» масштабирования, так как разрешение 640 я не припомню, а 720 является самым распрастраненым.
Я тоже озадачивалась таким вопросом. В итоге написала заметку
С тем что в статье, вроде всё понятно. А вот такой вопрос: а если игра(в которой много графики), допустим TD, нарисовал я башню для xhdpi, далее её нужно пересохранить 2 раза дня hdpi и mdpi, и получится для 1 башни — 3 изображения, или всё такие просто рисуется для xhdpi и больше ничего делать не надо?
Все верно, для каждого dpi необходима графика в соответствующих размерах. В итоге получится куча графики для одного элемента.
Получается сделал башню в 720x1280 и пересохранил её в 540×960, 360×640?
И ещё с анимацией тоже самое? это же… вообще куча графики будет.
И ещё с анимацией тоже самое? это же… вообще куча графики будет.
При декодировании ресурсов изображения можно сжимать. Плюс — не большой размер apk, минус — графика при сжимании теряет качество. Во втором случаи рисуем графику для каждого разрешения. Плюс — графика будет везде красивая, минус — толстая apk. Анимация — это такие же текстуры. Просто рисуются тайлы для каждого кадра.
Хм.
Сделать в относительных координатах и центрировать, а потом уже в зависимости от экрана края заполнять фоновыми элементами. Вместо 3 пикч будет одна. Не вариант?
Сделать в относительных координатах и центрировать, а потом уже в зависимости от экрана края заполнять фоновыми элементами. Вместо 3 пикч будет одна. Не вариант?
Если отсутствует какой-либо ресурс в необходимом dpi, то android сам пережмет доступный в необходимое разрешение
developer.android.com/guide/practices/screens_support.html
developer.android.com/guide/practices/screens_support.html
The Android system helps your application achieve density independence in two ways:
The system scales dp units as appropriate for the current screen density
The system scales drawable resources to the appropriate size, based on the current screen density, if necessary
…
However, bitmap scaling can result in blurry or pixelated bitmaps, which you might notice in the above screenshots. To avoid these artifacts, you should provide alternative bitmap resources for different densities. For example, you should provide higher-resolution bitmaps for high-density screens and the system will use those instead of resizing the bitmap designed for medium-density screens. The following section describes more about how to supply alternative resources for different screen configurations.
еще есть удобные утилиты, которые сами сгенерируют hdpi, ldpi, mdpi ресурсы из xhdpi источника
code.google.com/p/9patch-resizer/
code.google.com/p/9patch-resizer/
Там во время этих «пережатий» размер меняется интересным образом, помню как-то недоумевал по этому поводу, когда поместил все ресурсы в drawable)
Не совсем понял, что Вы имеете в виду. Размер меняется в строгом соотношении
developer.android.com/training/basics/supporting-devices/screens.html#create-bitmaps
developer.android.com/training/basics/supporting-devices/screens.html#create-bitmaps
To generate these images, you should start with your raw resource in vector format and generate the images for each density using the following size scale:
xhdpi: 2.0
hdpi: 1.5
mdpi: 1.0 (baseline)
ldpi: 0.75
Вот интересное приложение — play.google.com/store/apps/details?id=com.groidify.uipatterns — это сборник ui шаблонов, которые можно скачать с гитхаба
Как должно быть:
— Дизайнер рисует макеты
— Макеты утверждаются и отдаются разработчикам
— Дизайнер изучает полностью гайдлайны developer.android.com/design/index.html
— Берет Fireworks, качает набор стенсилов и на основе макетов делает дизайн для телефонов и планшетов, с страницами и состояниями
— Готовый fw.png файл отдается разработчикам и они берут оттуда нужные графические элементы, меняя по мере надобности размеры, сохраняя для mdip-xhdpi, делая 9-патчи где нужно.
— Готово
Как есть на самом деле:
— Заказчик отдает ТЗ (если повезет) разработчикам и дизайнеру. Они начинают параллельно работать.
— Дизайнер открывает редактор фотографий от Adobe, находит в интернете рамочку и ложит в файл размером «как там делали для айфона»
— Вдохновляясь TouchWiz дизайнер вставляет кучу разноцветных кнопочек, и так чтобы влезало четко по размеру экрана. И ставит красивую картинку на фон.
— Готовый набор psd-файлов с кучей слоев и групп отдается разработчикам.
— Разработчки забивают на попытки сделать правильно и просто нарезают слайсами то что есть в папу drawable-hdpi, ибо на маленьких экранах все равно все не помещается, а для планшетов дизайна и не присылали…
— Заказчик доволен, дизайнер доволен, аналитики жалуются на плохое качество приложений.
— Дизайнер рисует макеты
— Макеты утверждаются и отдаются разработчикам
— Дизайнер изучает полностью гайдлайны developer.android.com/design/index.html
— Берет Fireworks, качает набор стенсилов и на основе макетов делает дизайн для телефонов и планшетов, с страницами и состояниями
— Готовый fw.png файл отдается разработчикам и они берут оттуда нужные графические элементы, меняя по мере надобности размеры, сохраняя для mdip-xhdpi, делая 9-патчи где нужно.
— Готово
Как есть на самом деле:
— Заказчик отдает ТЗ (если повезет) разработчикам и дизайнеру. Они начинают параллельно работать.
— Дизайнер открывает редактор фотографий от Adobe, находит в интернете рамочку и ложит в файл размером «как там делали для айфона»
— Вдохновляясь TouchWiz дизайнер вставляет кучу разноцветных кнопочек, и так чтобы влезало четко по размеру экрана. И ставит красивую картинку на фон.
— Готовый набор psd-файлов с кучей слоев и групп отдается разработчикам.
— Разработчки забивают на попытки сделать правильно и просто нарезают слайсами то что есть в папу drawable-hdpi, ибо на маленьких экранах все равно все не помещается, а для планшетов дизайна и не присылали…
— Заказчик доволен, дизайнер доволен, аналитики жалуются на плохое качество приложений.
Если уж писать как должно быть, то вот тут вот не правильно:
… отдается разработчикам и они… сохраняя для mdip-xhdpi,…
Это тоже должен делать дизайнер, для того то бы картинка для каждого разрешения выглядела правильно. Не была размытой при масштабировании вверх, когда нарисована например для mdpi, или же вниз, когда картинка нарисована для xhdpi.
… отдается разработчикам и они… сохраняя для mdip-xhdpi,…
Это тоже должен делать дизайнер, для того то бы картинка для каждого разрешения выглядела правильно. Не была размытой при масштабировании вверх, когда нарисована например для mdpi, или же вниз, когда картинка нарисована для xhdpi.
Да, но большинство графики при нормальном дизайне сверстается в xml-e, то, что не поддастся — в найн-патчах, дизайнеру останутся только иконки и растровые картинки, если такие будут. Их быстрее сделать самому, чем объяснять какие картинки нужны, в каких состояниях, и надеяться что он сложит все по подпапочкам, без пробелов и больших буков. А если еще работа через менеджера…
> Да, но большинство графики при нормальном дизайне сверстается в xml-e
это хорошо если ваш дизайнер любит метро стиль :), а если нет?
> что не поддастся — в найн-патчах
оставлять блюренный или не правильно от масшабированный найн патч это тоже самое.
> Их быстрее сделать самому
с такими то дизайнерами, только это и остается делать. Порой сам перерисовываю для 3х разрешений в inkscape, если что то не сильно сложное, что бы хотя бы линии все были четкие.
это хорошо если ваш дизайнер любит метро стиль :), а если нет?
> что не поддастся — в найн-патчах
оставлять блюренный или не правильно от масшабированный найн патч это тоже самое.
> Их быстрее сделать самому
с такими то дизайнерами, только это и остается делать. Порой сам перерисовываю для 3х разрешений в inkscape, если что то не сильно сложное, что бы хотя бы линии все были четкие.
28px для текста, 96px для меню и заголовка
М-да… Размер шрифта в пикселях. Сразу видно — статью писал профессионал в дизайне приложений для Андроида.
М-да… Размер шрифта в пикселях. Сразу видно — статью писал профессионал в дизайне приложений для Андроида.
Статья больше похожа на вредные советы. Многие вещи расписаны неправильно или не расписаны полностью.
1. Не нужно как-то ориентироваться на размер экрана, и полностью привязываться к нему. Андроид устройств очень много, все они разные. В первую очередь нужно отталкиваться от плотности экрана, и дизайн делать с расчетом на резину. Например, mdpi устройства могут быть как и 320 пикселей в ширину, как и 360, да и вообще какими угодно. В конце концов, устройство можно поворачивать.
2. Action Bar — крайне важная вещь, и если вы действительно хотите сделать качественное приложение, то нужно на берегу разобраться как он работает. Там гораздо больше сложностей, чем просто «то, что не влезло, прячем за тремя точечками». Опять же action bar выглядит по разному на телефонах и планшетах, он может объединяться с navigation bar при повороте. На устройствах с аппаратной кнопкой «Меню» эти три точки вообще не должны показываться.
3. Дизайн инстаграма, фейсбука и твиттера для андроида можно с уверенностью не упоминать в подобных текстах. Они сделаны с крайне оттдаленными представлениями об экосистеме современного андроида.
4. PSD файлы со всеми элементами выкладывает (в отличие от эппл) сам гугл, прямо на своем сайте. Качай не хочу: developer.android.com/downloads/design/Android_Design_Holo_Widgets_20120814.zip
5. Минимальный рекомендуемый размер тапабельного элемента в андроиде — 48dp (то есть, 48 пикселей при плотности mdpi)
6. «Никогда не уделял гайдлайнам достаточно внимания». Чувак, до версии 4.0 гайдлайнов для андроида просто не существовало ;). И это объясняет, почему в гугл плее так много крайне некачественных приложений.
Чтобы начать рисовать под андроид, достаточно немного терпения, устройства с андроидом >4.0 на руках (лучше что-то типа нексуса) и вот этой ссылки: developer.android.com/design/index.html
1. Не нужно как-то ориентироваться на размер экрана, и полностью привязываться к нему. Андроид устройств очень много, все они разные. В первую очередь нужно отталкиваться от плотности экрана, и дизайн делать с расчетом на резину. Например, mdpi устройства могут быть как и 320 пикселей в ширину, как и 360, да и вообще какими угодно. В конце концов, устройство можно поворачивать.
2. Action Bar — крайне важная вещь, и если вы действительно хотите сделать качественное приложение, то нужно на берегу разобраться как он работает. Там гораздо больше сложностей, чем просто «то, что не влезло, прячем за тремя точечками». Опять же action bar выглядит по разному на телефонах и планшетах, он может объединяться с navigation bar при повороте. На устройствах с аппаратной кнопкой «Меню» эти три точки вообще не должны показываться.
3. Дизайн инстаграма, фейсбука и твиттера для андроида можно с уверенностью не упоминать в подобных текстах. Они сделаны с крайне оттдаленными представлениями об экосистеме современного андроида.
4. PSD файлы со всеми элементами выкладывает (в отличие от эппл) сам гугл, прямо на своем сайте. Качай не хочу: developer.android.com/downloads/design/Android_Design_Holo_Widgets_20120814.zip
5. Минимальный рекомендуемый размер тапабельного элемента в андроиде — 48dp (то есть, 48 пикселей при плотности mdpi)
6. «Никогда не уделял гайдлайнам достаточно внимания». Чувак, до версии 4.0 гайдлайнов для андроида просто не существовало ;). И это объясняет, почему в гугл плее так много крайне некачественных приложений.
Чтобы начать рисовать под андроид, достаточно немного терпения, устройства с андроидом >4.0 на руках (лучше что-то типа нексуса) и вот этой ссылки: developer.android.com/design/index.html
НЛО прилетело и опубликовало эту надпись здесь
Я просто забил на < 4.0
Роман Нурик из Google рекомендует делать для устройств с <4.0 аналогичный дизайн как и для >=4.0, используя соответсвующие библиотеки для обратной совместимости
Да, ActionBarSherlock и HoloEverywhere (спасибо Prototik) творят волшебство
Рисовать все по гайдам четверки. Существуют неплохие средства реализовать почти все нарисованное и в версиях ниже 4.0.
Вы видно до 4.0 просто гайдлайнами не интересовались. Гайдлайны появились еще для 1.5 r1
web.archive.org/web/20090301000000*/http://developer.android.com/guide/practices/ui_guidelines/index.html
web.archive.org/web/20090301000000*/http://developer.android.com/guide/practices/ui_guidelines/index.html
НЛО прилетело и опубликовало эту надпись здесь
потянуть, чтоб обновить как на iPhone, очень редко используются в Android
Во-первых, крайне сомнительное утверждение. Во-вторых, еще и вредное.
Во-первых, крайне сомнительное утверждение. Во-вторых, еще и вредное.
Для вводной статьи вполне сойдёт, спасибо.
Но лично мне бы больше хотелось видеть статьи именно по дизайну… как напрограммировать — пруд пруди, а как сделать ListView отличный от дефолтного — уже перелопатить пол-инета надо. А не дай Бог добавить тень, изменить границу и т.п. — это уже вообще.
Но лично мне бы больше хотелось видеть статьи именно по дизайну… как напрограммировать — пруд пруди, а как сделать ListView отличный от дефолтного — уже перелопатить пол-инета надо. А не дай Бог добавить тень, изменить границу и т.п. — это уже вообще.
Кроме 9-slice Scaling недавно прочитал про другой способ создания сложных фоновых изображений. С помощью Drawable ресурсов — http://developer.android.com/guide/topics/resources/drawable-resource.html. В некоторых случаях этот способ может оказаться полезным не только для создания фонов кнопок, но и сложных фоновых изображений.
Что-то невезёт кнопке Up — если даже среди людей делающий приложения не все понимают как она должна работать, то с пользователями совсем беда.
На самом же деле кнопка Up делает переход по иерархии экранов (то есть, если вы на экране описания приложения в маркете, то по нажатию на кнопку Up вы попадаете в список приложений маркета, даже если на экран описания приложения пришли совсем из другого места).
Вот тут про это замечательно написано, только нужно не поленится прочитать всё от начала до конца, а не ограничится просмотром картинок.
Боковое меню это вообще UI шаблон, которого в гайдлайнах нет вовсе, это заимствавание из iOS. Потому, чтоб не путать пользователся, лучше не вешать его открытие на логотип, или, по крайней мере, скрывать стрелочку (которая и показывает, что логотип работает как Up).
. Нажатие на логотип обычно вызывает боковое меню или возвращает вас “назад”, к предыдущему экрану.
На самом же деле кнопка Up делает переход по иерархии экранов (то есть, если вы на экране описания приложения в маркете, то по нажатию на кнопку Up вы попадаете в список приложений маркета, даже если на экран описания приложения пришли совсем из другого места).
Вот тут про это замечательно написано, только нужно не поленится прочитать всё от начала до конца, а не ограничится просмотром картинок.
Боковое меню это вообще UI шаблон, которого в гайдлайнах нет вовсе, это заимствавание из iOS. Потому, чтоб не путать пользователся, лучше не вешать его открытие на логотип, или, по крайней мере, скрывать стрелочку (которая и показывает, что логотип работает как Up).
Бокового меню и в iOS гайдах нет, его «популяризировали» полулярные iOS приложения. Ну и часто очень удобная штука.
Есть боковое меню в гайдлайнах и зовется Navigation drawer, для него даже специальную иконку придумали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Полезные советы новичкам в дизайне под Android