как адаптировать приложение под экран

Поддержка разных размеров экрана при разработке android приложений

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

В этом уроке описаны следующие аспекты обеспечения совместимости интерфейса с разными экранами:

Использование параметров wrap_content и match_parent

Если указать параметры «wrap_content» и «match_parent» вместо строго заданных размеров, в представлениях будет использоваться минимально необходимое место или они будут растягиваться на всю доступную длину и ширину соответственно. Например:

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

Рисунок 1. Приложение News Reader при вертикальной (слева) и горизонтальной (справа) ориентации.

Использование объекта RelativeLayout

На рис. 2 показано, как этот макет выглядит на экране QVGA.

Рисунок 2. Скриншот экрана QVGA (маленького размера).

На рис. 3 показано, как он выглядит на экране с большей диагональю.

Рисунок 3. Скриншот экрана WSVGA (большего размера).

Использование квалификаторов размера

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

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

Использование квалификатора Smallest-width

Одной из проблем, с которой сталкивались разработчики приложений для устройств Android версий до 3.2, было слишком общее определение «большого» экрана. Это касалось устройств Dell Streak, первой модели Galaxy Tab и планшетных ПК с экраном размером 7 дюймов. Многие приложения требовалось по-разному отображать на разных устройствах (например, с 5- и 7-дюймовыми экранами), хотя они и относились к одной категории «больших» экранов. В Android версии 3.2 и более поздних доступен квалификатор Smallest-width.

Это означает, что на устройствах, минимальная ширина экрана которых не меньше 600 dp, будет выбран layout-sw600dp/main.xml (двухпанельный макет), а на экранах меньшего размера – layout/main.xml (однопанельный макет).

Использование псевдонимов макетов

Квалификатор Smallest-width работает только на устройствах Android 3.2 или более поздних версий. Для совместимости с более ранними устройствами по-прежнему следует использовать абстрактные размеры (small, normal, large и xlarge). Например, чтобы интерфейс открывался в однопанельном режиме на телефонах и в многопанельном на планшетных ПК с 7-дюймовым экраном, телевизорах и других крупных устройствах, подготовьте следующие файлы:

Последние два файла идентичны: один из них предназначен для устройств Android 3.2 и новее, а второй для более старых планшетных ПК и телевизоров на платформе Android.

Чтобы не создавать дубликаты файлов и упростить процесс поддержки приложения, используйте псевдонимы. Например, можно определить следующие макеты:

Затем добавьте следующие два файла:

Использование квалификаторов ориентации

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

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

Использование растровых изображений nine-patch

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

Если использовать для компонентов, размеры которых меняются, обычные изображения, то они будут равномерно сжиматься и растягиваться, и результат будет далек от идеального. Решением являются растровые изображения формата nine-patch – специальные PNG-файлы, содержащие информацию о том, какие области можно растягивать, а какие нет.

Создавая растровые изображения для масштабируемых компонентов, обязательно используйте формат nine-patch. На рис. 4 показано обычное растровое изображение (увеличенное в 4 раза для наглядности), которое мы переведем в формат nine-patch.

Рисунок 4. button.png

Рисунок 5. button.9.png

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

При применении этого фона к компоненту (с помощью android:background=»@drawable/button» ) изображение будет растянуто по размеру кнопки, как показано на рис. 6.

Рисунок 6. Кнопки разных размеров с файлом фона button.9.png в формате nine-patch.

Источник

Разработка игрового интерфейса для различных пропорций экранов

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

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

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

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

В настоящее время, наверное, самым распространенным является формат дисплея 16:9, но он не единственный. На рынке немало моделей, в которых применяются экраны с соотношением сторон 18:9, новинки Apple оснащены дисплеями пропорцией 19,5:9. Но это не предел, в начале года компания Sony представила смартфон с экраном 21:9. И буквально недавно китайская компания Xaiomi анонсировала новинку с экраном 22,5:9. В тоже время нельзя скидывать со счетов наличия большого числа моделей планшетов с экранами 4:3. Если последний формат представить как 12:9, то несложно заметить интересную особенность, в ландшафтной ориентации высота экранов разных пропорций кратна 9, а по горизонтали их кратность может отличаться чуть ли не в два раза.

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

Такой подход вполне разумен, но лишь при небольшой разнице в пропорциях экранов. Например, если игра была создана под экран 16:9, то для дисплея 18:9 это сработает. Но уже в случаев, скажем, 22,5:9 и 4:3 вряд ли.

Еще встречался с предложением использовать «резиновую» верстку, при которой размеры игровых элементов адаптируются к размерам дисплеев. Но это тоже не выход, во многих случаях форма таких элементов станет искаженной.

Мой подход к верстке

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

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

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

В качестве базового размера игрового экрана при разработке был выбран широко распространенный формат 16:9 с разрешением 1920х1080. Большинство игровых элементов располагаются от центра экрана в относительных отступах со знаками плюс и минус.

На рисунке схематично изображен принцип такого размещения на примере двух кнопок управления игровым процессом и надписи с фиксированной позицией.

Но предложенный способ это только принцип, на практике такой подход не всегда оправдан. Как вариант можно унифицировать подбор коэффициентов относительных отступов через задание заранее определенных констант. Скажем, мы хотим, чтобы края кнопок не доходили до границ экрана на расстояние 5% от ширины и высоты. Если для левой половины экрана формула останется без изменений, то для правой потребуется учитывать размеры самой кнопки.

Такой подход позволил корректно располагать игровые элементы на экранах с разными пропорциями. Для примера скриншоты моей игры на разных дисплеях. Для наглядности, скриншот экрана 4:3 был сделан с эмулятора древней модели с дисплеем 320х240.

На первом скриншоте 4:3 специально оставлен артефакт в правой части экрана. Верхняя и нижняя правые кнопки размещались на основе коэффициентов относительного смещения от центра экрана. Как видно, верхняя кнопка «провалилась». Это связано с пересчетом размеров исходного изображения кнопки с учетом разрешения экрана. Если не вводить этот коэффициент, то правый край кнопок в этой части экрана вылезет за его пределы. Но так как размеры кнопки уменьшились, а начало координат ее вывода остались неизменными, поэтому она визуально оказалась «проваленной».

На этом скриншоте проблема решена за счет использования коэффициентов относительного отступа от границ экрана.

Теперь несколько скринов для экранов разных пропорций

Отношение 16:9, экран 1920х1080

Отношение 18:9, экран 2880х1440

Отношение 19,5:9 экран 2688х1242

Смещение начала точки вывода большинства игровых элементов на представленных скриншотах осуществлялось как рассмотрено выше, через относительные отступы от центра экрана. А вот для пяти кнопок управления пришлось поступить несколько иначе, чтобы они всегда были на своих позициях. Для них был задан относительный отступ Kpadding по осям Х и Y от границ экрана. Так как игра создавалась под базовое разрешение 1920х1080, то для корректного отображения на дисплеях с другим разрешением рассчитывался специальный коэффициент масштабирования на основе реальных размеров экрана и базового разрешения. Этот коэффициент учитывался при подсчете абсолютных смещений игровых элементов и их отображаемых размеров.

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

Источник

Адаптация под различные экраны приложений Windows Store

Заметил, что у разработчиков возникает множество вопросов по поводу адаптации приложения под экраны различного размера. Для того чтобы была возможность предоставить ссылку, по которой есть необходимая информация, я и решил написать этот небольшой материал. Рассматривать буду не только приложения под Windows 8.1, будет затронута и разработка приложений Windows 10 UWP.

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

Коэффициент масштабирования — это соотношение реальных пикселей устройства и отображаемых. При расчете этого коэффициента учитывается также стандартная дистанция, с которой пользователи смотрят на экран устройства.
В приложениях под Windows 8.1 поддерживается три коэффициента масштабирования: 100%, 140% и 180%. У Windows Phone 8.1 приложений различных коэффициентов масштабирования больше.
В эмуляторе Windows Store приложений, при изменении разрешения экрана вы можете увидеть и само разрешение, и значение коэффициента масштабирования рядом.

Процесс адаптации изображений похож на локализацию изображений. Для того, чтобы для различных разрешений брался верный вариант картинки необходимо внутри папки images создать 3 папки с именами: scale-100, scale-140, scale-180. Внутрь этих папок уже и добавляем изображения с одинаковыми названиями.

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

Соответственно, вам нужно будет создать 3 версии изображения. Если ваше стандартное изображение имеет 200 пикселей в ширину, то для масштабирования 140% нужно будет умножить ширину на 1,4. То есть вам нужно будет создать такое же изображение 280 пикселей в ширину. Ну и для масштабирования 180% нужно будет иметь такое же изображение шириной 200*1,8=360 пикселей.
Во время выполнения приложения оптимальное изображение выбирается автоматически, в зависимости от того, какое разрешение экрана у пользователя.
Если вы задаете файл изображения из кода, то вывести картинку верного разрешения вам может помочь следующий официальный сниппет, который исходя из значения DisplayInformation.GetForCurrentView().ResolutionScale определяет текущий коэффициент масштабирования экрана:

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

Адаптация макета приложения под размер экрана
Если содержимое вашего приложения размещено в элементе-контейнере Viewbox, то при изменении размера экрана ваше содержимое будет автоматически растянуто и масштабировано с целью заполнить все доступное пространство. Для того, чтобы растровые изображения при таком увеличении выглядели прилично, необходимо добавить несколько вариантов различного размера, как мы это только что рассматривали.
Размещение приложения внутри Viewbox – это один из предлагаемых вариантов адаптации приложения под различные экраны. Другим вариантом может быть скрытие элементов приложения или изменение их размеров. Рассмотрим работу с различными размерами приложения на примере режима snap.
Стандартно приложение Windows 8.1 может быть минимум 500 пикселей в ширину. В случае, если ваше приложение хорошо будет выглядеть и при более узком виде, либо его вполне можно использовать с другими приложениями, а также если желательно оставлять его как можно дольше в рабочем положении – вы можете установить ему минимальной шириной 320 пикселей. Сделать это можно, указав в редакторе манифеста минимальную ширину 320 или добавив в код манифеста атрибут MinWidth со значением width320 (кстати, в Windows 8 приложениях режим snap был как раз 320 пикселей)

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

Но так делать можно в небольших приложениях, в которых вам не будет трудно перебрать все существующие контролы в коде C#. Для нормальных приложений лучше всего изменения внешнего вида хранить в XAML VisualState состояниях. Таким образом, можно предоставить дизайнеру возможность комфортного изменения макета в Blend. Следующий пример содержит те же изменения, что и предыдущий код:

Теперь в событии изменения размера окна мы можем перейти к нужному состоянию (в зависимости от текущего размера экрана):

Здесь для получения размера экрана в ширину и высоту мы опять использовали параметр SizeChangedEventArgs e.
В любой другой момент выполнения программы, ширину и высоту видимого окна приложения (так называемые эффективные пиксели, которые не зависят от размера экрана устройства) можно получить так:
Кроме эффективных пикселей есть еще и raw пиксели (англ. raw — сырой, необработанный) – реальное количество точек на экране или физические пиксели. Например, если экран устройства 1080 пикселей в ширину, то и количество raw пикселей будет 1080 по горизонтали.

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

Что по поводу приложений универсальной платформы Windows?

Универсальные приложения Windows 8.1 уже предоставляли нам возможность сделать свою отдельную XAML раскладку для WP и для Store. На следующем скриншоте два MainPage.xaml файла:

В приложениях UWP нам будет доступна возможность создать множество XAML файлов с представлениями внешнего вида приложения и выбрать нужный из них, в зависимости от различных факторов (размер экрана, разрешение и т.п.). Давайте попробуем.
Создадим в проекте директорию DeviceFamily-Mobile.
Кликнем на ней правой кнопкой мыши и выберем пункт Add new item
Из вариантов нам нужно выбрать XAML View и назвать наше представление так же, как и называется то представление, которое мы хотим заменить. В простом случае это может быть MainPage.xaml.
Теперь тот XAML код, который мы внесем в файл MainPage.xaml, расположенный в папке DeviceFamily-Mobile будет отображен на мобильных устройствах. На десктопах же и иных устройствах будет отображен дизайн приложения из основного MainPage.

RelativePanel
Теперь нам стал доступен новый контрол RelativePanel, который позволяет создавать взаимосвязи положений между своими дочерними элементами.
Например, следующий код:
задает оранжевой кнопке положение под светло синей:

Пример взят отсюда.

AdaptiveTrigger
Windows 10 приложения не только поддерживают VisualState состояния, но и расширяют их новым функционалом. Во первых, теперь стало можно использовать триггеры для UI. А во-вторых, VisualStateManager теперь поддерживает Setters. Теперь отпала необходимость создавать 0-секундную анимацию (даже более того – устарела). Благодаря этому код становится более читаемым. Сравните следующий пример с примером, который мы рассматривали ранее:

Обратите внимание на строку Здесь задается значение минимальной ширины окна приложения, при котором сработает триггер. Далее с помощью Setters задается цвет для состояния. Весь этот код означает, что при изменении ширины приложения, в случае если ширина становится шире чем 600 пикселей цветом Layout становится зеленый.

Замечательная статья (англоязычная), из которой я взял это пример находится здесь.

Device preview toolbar
В Windows 10 ожидается расширение возможностей масштабирования приложений. Уже сейчас вы можете протестировать отображение внешнего вида вашего XAML кода на различных устройствах, используя device preview toolbar:

Обратите внимание на скриншот. Вы можете заметить, что Windows 10 приложения поддерживают гораздо больше коэффициентов масштабирования, чем приложения Windows 8.1. Вот табличка с презентации BUILD 2015, сравнивающая возможности масштабирования различных платформ:

Как вы можете заметить Windows 10 приложения на высоте – они самые «скалистые».

Что-то еще? Узнаем совсем скоро, ведь совсем не за горами 20-ое июля — дата релиза Visual Studio 2015, а там до 29-ого июля и выхода Windows 10 уже рукой подать.

Источник

Полный список

— учитываем ориентацию и размер экрана в работе приложения

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

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

Соответственно урок состоит из трех частей.

1. Приложение, отображающее слева заголовки, а справа – содержимое

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

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

Долго думал, как назвать проект. Решил – MultipleScreen.

Project name: P1151_MultipleScreen
Build Target: Android 2.2
Application name: MultipleScreen
Package name: ru.startandroid.develop.p1151multiplescreen
Create Activity: MainActivity

Добавим строки в strings.xml:

Два массива – заголовки и содержимое.

Не забывайте, что мы используем библиотеку v4, чтобы наше приложение с фрагментами работало на старых версиях.

Создаем фрагмент, который будет отображать список заголовков

Класс наследует ListFragment для удобства работы со списком.

onItemClickListener – интерфейс, который будет наследовать Activity. Подробно эту схему мы разбирали в Уроке 106. Интерфейс имеет метод itemClick, который фрагмент будет вызывать при выборе элемента списка.

В onCreate создаем адаптер с заголовками и передаем его списку.

В onAttach записываем Activity (к которому присоединен фрагмент) в listener. Разумеется, это Activity должно реализовывать интерфейс onItemClickListener.

В onListItemClick, мы через listener посылаем в Activity данные о выбранном элементе.

Т.е. этот фрагмент покажет нам заголовки и уведомит Activity о том, какой из них был выбран.

Создаем второй фрагмент, для отображения содержимого.

TextView, который будет отображать содержимое.

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

Метод getPosition достает из аргументов позицию.

onCreateView создает View, находим в нем TextView, и помещает в этот TextView содержимое, соответствующее позиции.

Для нас тут новыми являются аргументы фрагмента. Они могут быть заданы строго до того, как фрагмент будет присоединен к какому либо Activity, т.е., обычно, сразу после создания фрагмента. Они хранятся в фрагменте даже после того, как он был пересоздан в результате, например, смены ориентации экрана. Метод setArguments позволяет записать аргументы, а getArguments – считать.

Этот фрагмент при создании читает содержимое по переданной ему позиции и выводит в TextView.

Настраиваем Activity. layout-файл main.xml:

Слева будет TitlesFragment с заголовками, а в правой части будем помещать DetailsFragment в контейнер FrameLayout.

Activity наследует интерфейс onItemClickListener, чтобы получать оповещения о выбранных элементах от фрагмента со списком заголовков. Поле position будет хранить последний выбранный элемент. Это поле сохраняем (onSaveInstanceState) и читаем (savedInstanceState в onCreate) при пересоздании Activity.

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

Метод showDetails получает на вход позицию, ищет DetailsFragment. Если не находит или находит но, отображающий данные по другой позиции, то создает фрагмент заново, передает ему нужную позицию и размещает в контейнер.

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

Все сохраняем, запускаем приложение.

Выберем какой-либо пункт

все работает, как и должно.

Теперь добавим учет ориентации экрана. В вертикальной ориентации MainActivity будет отображать только заголовки. Фрагмент с содержимым вынесем в отдельное DetailsActivity

Представим ситуацию. Мы поворачиваем планшет вертикально, у нас отобразятся только заголовки. Мы нажимаем на какой-либо заголовок и переходим на DetailsActivity, которое покажет нам содержимое (средствами DetailsFragment, разумеется). Т.е. мы имеем вертикальную ориентацию и видим содержимое. Теперь поворачиваем планшет горизонтально. Что будет? DetailsActivity отобразится во весь горизонтальный экран и покажет содержимое. Но наша концепция гласит, что в горизонтальной ориентации приложение должно показывать и содержимое и заголовки, ширина экрана ведь позволяет это сделать. А, значит, нам надо вернуться в MainActivity.

Смотрим первый фрагмент кода. Приложение определяет, что ориентация горизонтальная и в этом случае просто закрывает Activity. И т.к. это DetailsActivity у нас будет вызвано из MainActivity, то после finish мы попадаем в MainActivity и видим то, что нужно – и заголовки, и содержимое. Причем MainActivity хранит номер выбранного заголовка (независимо от ориентации) и содержимое отобразится то же самое, что было в DetailsActivity.

Смотрим второй фрагмент. Мы проверяем, что savedInstanceState == null – это означает, что Activity создается первый раз, а не пересоздается после смены ориентации экрана. Далее мы создаем фрагмент DetailsFragment, используя позицию из интента, и помещаем его в Activity.

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

Не забудьте прописать Activity в манифесте.

А res/layout/main.xml поменяем следующим образом:

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

Изменений немного. Добавляется поле withDetails, которое будет сообщать нам: показывает Activity заголовки с содержимым или без. В нашем случае это будет совпадать соответственно с горизонтальной и вертикальной ориентацией.

В onCreate мы задаем значение withDetails с помощью проверки наличия контейнера для фрагмента с содержимым. Если у нас должно отображаться содержимое, то вызываем метод showDetails и передаем ему позицию. Если содержимое не должно отображаться, то ничего не делаем, показываем только заголовки.

В методе showDetails мы смотрим withDetails. Если содержимое должно быть показано здесь же, то работает старый алгоритм, мы создаем фрагмент. Если же содержимое должно быть показано в отдельном Activity, то вызываем DetailsActivity и передаем ему позицию.

Все сохраняем, запускаем приложение.

видим только заголовки

видим содержимое в новом Activity

видим содержимое и заголовки

Осталось подстроить работу приложения под маленькие экраны. Напомню, что на мелких экранах мы при любой ориентации будем разделять заголовки и содержимое по разным Activity. Размер экрана можно определять по-разному. Я буду считать большими экраны large и xlarge. Для этих экранов логика остается текущая, для остальных немного изменим.

Ориентация экрана бывает горизонтальная (land) и вертикальная (port). Экраны мы будем различать: мелкие, large и xlarge. Итого у нас получается 6 комбинаций экранов.

И у нас уже есть два варианта файла main.xml – «заголовки с содержимым» и «только заголовки«.

Надо сопоставить комбинации и варианты.

Вариант «заголовки с содержимым» будем использовать в комбинациях 5,6 (большие экраны в горизонтальной ориентации)

Вариант «только заголовки» подходит к комбинациям 1,2,3,4 (мелкие экраны в любой ориентации и большие экраны в вертикальной ориентации).

Создаем layout-папки под эти комбинации, и помещаем в них варианты экранов.

Папка res/layout-large-land. Это комбинация 5. Сюда помещаем вариант main.xml, который «заголовки с содержимым».

Папка res/layout-xlarge-land. Это комбинация 6. Сюда помещаем вариант main.xml, который «заголовки с содержимым».

Папка res/layout. Это все остальные комбинации (1,2,3,4). Сюда помещаем вариант main.xml, который «только заголовки».

Т.е. в итоге получается, что мы в папки layout-large-land и layout-xlarge-land копируем файл из layout-land, и удаляем папку layout-land. Папку layout не трогаем, там все ок.

Осталось немного изменить DetailsActivity.java:

Метод isLarge определяет, большой экран или нет. Если раньше мы в горизонтальной ориентации сразу закрывали это Activity, то теперь будем делать это только для больших экранов. А на остальных содержимое будет отображаться в горизонтальной ориентации.

Все сохраняем и запускаем приложение.

Скрины с планшета приводить не буду. Они полностью повторят предыдущие.

А на смартфоне с маленьким экраном будет так:

Жмем назад и попадаем к заголовкам

Немаленький такой материал получился. Но, вроде, все рассказал, чего хотел.

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

Если остались непонятные моменты – велкам на форум, будем решать.

На следующем уроке:

— меняем поведение Activity в Task

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме

Источник