как обрабатывать фрагменты экрана Android?

Question

Я хочу написать макет и код только один раз, чтобы он выглядел хорошо на всех устройствах.Я пробовал много способов (да, включая то, что предлагает Google, использовать DP, а также добавить несколько файлов макетов), но ни один из них не решает проблему необходимости сталкиваться с новой ситуацией каждый раз, когда появляется новое устройство со случайным разрешениеми плотность.использование DP - это всего лишь прием XML, который позволяет размерам оставаться одинаковыми на всех экранах, например, линейке (например, 1 см остается на 1 см на всех экранах), так что это действительно не решение.

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

Я слышал, что Google работает над решением для этого вопроса, а также версийфрагменты для новой версии сэндвича с мороженым, но я не слышал / не читал ничего нового по этому вопросу.не только это, но и график множественных плотностей и разрешений, которые должен поддерживать android, становится все больше и больше: http://developer.android.com/guide/practices/screens_support.html

обидно, что многие другие технологии уже нашли решение этой проблемы: у Apple есть это (автоматически масштабирует приложения с iphone 3g на iphone 4), у Adobe это есть (flash) и даже у Microsoft (с помощью viewbox, на silverlight, wpf и WP).даже телевизоры должны справиться с этой проблемой, и они делают это просто отлично.

Я не прошу магии, просто для того, чтобы масштабировать все.если вид был размером W%, H% экрана и находился в положении X%, Y% экрана, он должен оставаться таким же на всех экранах, а также позволять нам сохранять пропорции, если это важнонам достаточно.почему мы должны беспокоиться о разрешениях и плотности?это просто сбивает с толку, и нас, и графические команды.

Итак, в заключение, я думаю и надеюсь, что многие думают, как я, и, возможно, кто-то сделал хороший SDK, который решает все это?

---

@ chubbard: DP не работает должным образом, так как он позволяет вещам оставаться одинаковыми для всех экранов, как линейка.если что-то было на 3/4 экрана, на другом экране это было бы не так (это могло бы быть даже за пределами экрана или происходить другие странные вещи, в зависимости от того, какой макет вы выбрали).DP - это фиксированное значение, которое переводится только в пиксели на каждом устройстве только на основе плотности.поэтому для разницы между wvga800 (hdpi-480x800) и wvga854 (hdpi-480x854) DP ничего не изменит, и вы получите 54 пикселя, которые вы не знаете, что с ними делать.если вы хотите поместить что-то для wvga854, это не будет показано для wvga800.что еще хуже, между этими двумя экранами нет разницы, когда речь идет о макетах Android - они оба находятся под одной и той же категорией normal-hdpi.

также, если вы используете DP, на одном экране изображение / кнопка выглядитхорошо, но на других экранах они выглядят такими крошечными по сравнению с остальной частью экрана, так что это действительно не может быть хорошим решением.я также не понимаю, почему у нас есть несколько папок для рисования, которые обычно устанавливаются в зависимости от плотности.это только делает больше работы для графических команд и заставляет приложение иметь гораздо больший размер, чем оно есть, и из-за этого рынок может не принять его (из-за слишком большого размера) или даже хуже - устройства не будутбыть в состоянии загрузить приложение (например, старые версии ОС в galaxy S не могут загружать и устанавливать приложения размером более 30 МБ).

@ adamp: я ничего не говорил о absoluteLayout.он имеет точно плохое поведение, которое я хочу преодолеть, как и остальные макеты.единственный макет, который каким-то образом допускает масштабирование - это linearLayout (с использованием весов), но для выполнения простой задачи требуется много тегов и записей.о том, что я хочу, я уже написал: я хочу, чтобы все масштабировалось.В интернете есть множество примеров, где вы можете видеть, что он отлично работает, даже на флэш-памяти.просто откройте полное окно flash / silverlight content и измените размер окна.если программист все установил правильно, все в нем будет масштабироваться в соответствии с новым размером по сравнению с исходным размером.Кстати, спасибо за примечание gridlayout.я не знал об этом.однако, похоже, что он тоже ничего не может масштабировать.

@ andreasg: теперь это интересно.как вы обрабатывали изображения?не могли бы вы попробовать следующую «загадку»?Предположим, у вас есть изображение человеческого лица (или андроида :)), которое должно соответствовать экрану (и сохранить его соотношение сторон), и у вас есть другое изображение его глаз, окрашенное в другой цвет, как бы вы их накрасилиповерх другого (возможно, с использованием framelayout), чтобы он выглядел одинаково (в масштабе) на всех устройствах, независимо от того, находитесь ли вы в альбомном или портретном режимах?

Answer 1

Вы должны использовать абсолютно разные макеты только для больших изменений в поведении своего приложения, а не для незначительных отклонений в размере экрана в пределах одного класса устройств, таких как телефоны. Вы можете предоставить вариант -land ваших макетов, оптимизированных для ландшафтного режима, или вы можете предоставить вариант -sw600dp, чтобы представить другую информационную архитектуру для планшетов размером около 7 "или более. Вам не следует использовать это для предоставления других макеты для WVGA и дисплея телефона QHD. Это создаст для вас много дополнительной работы.

dp - инструмент для работы с разными плотностями, он не поможет при отклонениях в размерах и соотношении сторон. Решение для работы с отклонениями в размере экрана и соотношении сторон заключается в использовании менеджеров компоновки, предусмотренных в платформе, для адаптации к текущему устройству. Вы можете довольно легко написать свой собственный, расширив ViewGroup и переопределив методы onMeasure и onLayout, если вы окажетесь в ситуации, когда вы действительно нужно нестандартное поведение. API 14 добавил GridLayout, что также предоставляет дополнительные возможности.

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

Думая в процентах, это хорошее начало, и именно такие результаты вы получите, используя функцию веса LinearLayout. Но если вы хотите указать, что определенное представление должно поддерживать определенное соотношение сторон, вам нужно подумать о том, как это должно быть ограничено, что заполнит лишнее пространство, и будут ли эти решения полезными для пользователя для вашего приложения. , (Например, ни один пользователь не хочет использовать приложение, которое само создает почтовые ящики и отображает реальный контент только в поле с фиксированным соотношением сторон в середине.)

Нет волшебного решения, поскольку только вы знаете, как эти вещи должны вести себя в вашем приложении. Android поможет вам, но вы должны сказать ему, что вы хотите.

Возможно, вы могли бы опубликовать вопрос о конкретном дизайне, с которым у вас возникли проблемы, и кто-то здесь, на stackoverflow, может предложить некоторые предложения.

Answer 2

Мой способ рисования пользовательских видов с правильным масштабом для каждого размера экрана состоит в том, чтобы получить фактическую плотность экрана:

float density = context.getResources().getDisplayMetrics().density;

и, например, установить размер шрифта для пользовательского представления с 16 независимыми пикселями плотности

paint.setTextSize(density * 16);

Вот и вся магия.Я надеюсь, что это решит вашу проблему.