Fitssystemwindows android что это
WindowInsets и fitsSystemWindows
Любая активность может получить доступ к окну Window через метод Activity#getWindow().
Аналогично класс Dialog имеет своё окно Dialog#getWindow().
В свою очередь окно содержит всю необходимую информацию о размерах системных элементов и подстраивает все дочерние элементы (вашу активность), чтобы не было нигде зазоров или наложений друг на друга. Реализуется взаимное расположение при помощи специальных отступов Inset.
Поведение Window в разных версиях Android менялась. До KitKat была упрощённая версия не учитывала системные элементы управления. Доступ к ним осуществлялся через метод setSystemUiVisibility(). Также было множество флагов настроек: SYSTEM_UI_FLAG_VISIBLE, SYSTEM_UI_FLAG_FULLSCREEN и другие.
Начиная с KitKat, Android стала поддерживать полупрозрачные системные панели. Появились атрибуты androd:windowTranslucentStatus, android:windowsTranslucentNavigation.
В Lollipop происходит дальнейшая интеграция, системные элементы входят в состав Window и появилась возможность управлять фоном через android:windowDrawsSystemBarBackgrounds.
Мы можем узнать цвета системных элементов.
android:fitsSystemWindows=»true»
Данный флаг использовался для этой же цели. Сейчас в документации указано, что флаг считается устаревшим с версии API 20.
Данный флаг не будет иметь значения для многих видов макетов типа LinearLayout, FrameLayout. Но есть несколько видов макетов, к которым флаг применить можно. К таким макетам относятся DrawerLayout, CoordinatorLayout, AppBarLayout, CollapsingToolbarLayout, NavigationView.
Лучше вызывать метод onApplyWindowInsets().
Для решения проблемы используйте методы getSystemWindowInsetLeft(), getSystemWindowInsetTop(), getSystemWindowInsetRight(), getSystemWindowInsetBottom() класса WindowInsets/WindowInsetsCompat.
При разработке собственного компонента можете использовать код:
Как уже упоминалось выше, отступы не работают с некоторыми видами макетов. Вы можете переопределить поведение макета, наследуясь от основного макета и переопределяя метод.
BottomNavigationView
Как работать с нижней частью экрана рассказано в статье WindowInsets — Listeners to layouts (12 Apr 2019).
Что именно делает fitsSystemWindows?
Я пытаюсь понять концепцию fitsSystemWindows поскольку в зависимости от вида он делает разные вещи. Согласно официальной документации, это
Теперь, проверяя класс View.java я вижу, что при установке значения true вставки окна (строка состояния, панель навигации …) применяются к окнам просмотра, которые работают в соответствии с приведенной выше документацией. Это важная часть кода:
Документация в ViewCompat.java для setFitsSystemWindows гласит:
Однако, если вы хотите, чтобы FrameLayout рисовал себя за строкой состояния, установка fitsSystemWindows в true не делает этого трюка, поскольку реализация по умолчанию делает то, что документировано изначально. Вы должны переопределить его и добавить те же флаги, что и другие упомянутые классы. Я что-то упускаю?
Он не затягивается за системный план, он как бы растягивается за панелью, чтобы подкрасить его теми же цветами, что и у него, но просмотренные в нем представления заполняются в строке состояния, если это имеет смысл
Системные окна – это части экрана, на которых система рисует либо неинтерактивную (в случае строки состояния), либо интерактивную (в случае панели навигации).
В большинстве случаев ваше приложение не нужно будет рисовать под панелью состояния или панель навигации, но если вы это сделаете: вам нужно убедиться, что интерактивные элементы (например, кнопки) не скрыты под ними. Именно это дает поведение по умолчанию для атрибута android: fitsSystemWindows = «true»: оно устанавливает заполнение представления, чтобы содержимое не перекрывало системные окна.
Why would I want to fitsSystemWindows?
System windows are the parts of the screen where the system is drawing either non-interactive (in the case of the status bar) or interactive (in the case of the navigation bar) content.
Most of the time, your app won’t need to draw under the status bar or the navigation bar, but if you do: you need to make sure interactive elements (like buttons) aren’t hidden underneath them. That’s what the default behavior of the android:fitsSystemWindows =»true» attribute gives you: it sets the padding of the View to ensure the contents don’t overlay the system windows.
A few things to keep in mind:
And, in many cases, such as a full screen video playback, that’s enough. You’d have your full bleed view with no attribute and another full screen ViewGroup with android:fitsSystemWindows=»true» for your controls that you want inset.
Customizing fitsSystemWindows
But this default behavior is just that: a default. On KitKat and below, your custom View could override fitSystemWindows() and provide any functionality you wanted — just return true if you’ve consumed the insets or false if you’d like to give other Views a chance.
Examples of customizing fitsSystemWindows
One example is the navigation drawer which needs to span the whole screen and appear under a transparent status bar.
Here, DrawerLayout uses fitsSystemWindows as a sign that it needs to inset its children (such as the main content view — just like the default behavior), but still draw the status bar background (which defaults to your theme’s colorPrimaryDark ) in that space as per the material design specs.
CoordinatorLayout also takes advantage of overriding how it handles window insets, allowing the Behavior set on child Views to intercept and change how Views react to window insets, before calling dispatchApplyWindowInsets() on each child themselves. It also uses the fitsSystemWindows flag to know if it needs to paint the status bar background.
Similarly, CollapsingToolbarLayout looks for fitsSystemWindows to determine when and where to draw the content scrim — a full-bleed scrim which overlays the status bar area when the CollapsingToolbarLayout is scrolled sufficiently off the screen.
If you’re interested in seeing some of the common cases that accompany the Design Library, check out the cheesesquare sample app.
Use the system, don’t fight it
Just rest assured that the insets you do get from fitsSystemWindows will be correct on all platform versions to ensure your content does not overlap with system provided UI components — make sure to avoid any assumptions on their availability or size if you customize the behavior.
Русские Блоги
android: использование атрибута fitsSystemWindows
Краткое описание использования атрибута fitsSystemWindows в Android
Описание недвижимости
Атрибут fitsSystemWindows позволяет представлению настраивать свою компоновку в соответствии с системным окном, иными словами, учитывается ли компоновка системного окна при настройке компоновки приложения, здесь системное окно включает в себя строку состояния системы, панель навигации, метод ввода и т. Д., Включая некоторые полосы системы мобильного телефона. Внизу есть виртуальные кнопки.
Примечание: fitsSystemWindows работает только на системах Android 4.4 и выше, поскольку система StatusBar ниже 4.4 не имеет прозрачного статуса.
Сценарий приложения
Под разные версии Android, адаптация строки состояния приложения и строки состояния самой системы в разных версиях;
Совместимо с системами мобильных телефонов с виртуальными кнопками внизу.
Использование атрибута
1. Эффект по умолчанию
Сначала опубликуйте изображение макета теста, когда строка состояния системы и панель навигации не установлены прозрачно:
2. Эффект после системного окна прозрачен
Когда прозрачная строка состояния (StatusBar) и прозрачная панель навигации (NavigationBar) установлены, изображение эффекта:
Настройки прозрачного состояния штрих-кода:
Настройка кода прозрачной панели навигации:
Если есть один из двух вышеупомянутых случаев, наша строка состояния (StatusBar) или панель навигации (NavigationBar) станут прозрачными, а раскладка развернется до положения StatusBar или NavigationBar.
Примечание. Возникает вопрос о прозрачном стиле строки состояния и панели навигации. Это определяется версией Android. Эффект прозрачности ниже 4.4 отсутствует, полностью прозрачный 4.4
5.0, а прозрачный 5.0 и выше. Для тестирования я использовал симулятор версии 5.0 или выше, поэтому он прозрачный.
3. После настройки свойств fitsSystemWindows
Теперь пришло время появления нашего ключевого атрибута fitsSystemWindows. Просто добавьте android: fitsSystemWindows = «true» в корневой макет, как показано ниже:
После установки атрибута android: fitsSystemWindows = ”true” прозрачная верхняя панель автоматически добавит paddingTop со значением, равным высоте строки состояния, а прозрачная системная панель навигации автоматически добавит paddingBottom со значением, равным высоте панели навигации.
Вставьте код макета:
Следовать за
Прикрепите код Java, чтобы получить строку состояния StatusBar и высоту панели навигации NavigationBar:
Material Design в Android: продолжаем изучать модную тему
Содержание статьи
Android-роботы версий 5 и 6 продолжают гордо шагать по смартфонам и планшетам радостных пользователей, сверкая красотами Material Design. При этом, надо отдать должное Google, старые девайсы никто не забывал, они тоже примерили шкурки материального дизайна, пусть и не в полном объеме. О том, как все это работает на устройствах с Android версий со второй по четвертую, мы сегодня и поговорим. Если же ты разрабатываешь приложения исключительно для Android 6, то информация, приведенная ниже, тоже будет тебе полезна.
Модный приговор
Material Design — дизайн программного обеспечения и приложений операционной системы Android от компании Google, впервые представленный на конференции Google I/O в 2014 году. Идея дизайна заключается в создании приложений, которые открываются и сворачиваются как физические (то есть материальные) карточки. Как и все физические объекты, они должны отбрасывать тень и иметь некоторую инерционность. По идее дизайнеров Google, у приложений не должно быть острых углов, карточки должны переключаться между собой плавно и практически незаметно (рис. 1).
Xakep #205. Взлом Single Sign-On
Вообще, эффект тени позволяет визуально расположить все элементы на разной высоте, то есть получается некоторая совокупность слоев (рис. 2).
Не менее значима концепция плавающей кнопки (Floating Action Button), отражающей главное действие во фрагменте или активности. Например, в Gmail данный виджет позволяет создать новое письмо. Плавающей эта кнопка названа потому, что ее положение не фиксировано (да, не только правый нижний угол) и может меняться. Причем это изменение должно быть плавно и осмысленно анимировано, то есть, например, при скроллинге компонента ListView или переключении фрагмента FAB кнопка может «уезжать» за экран или «растворяться».
Формат журнальной статьи не позволяет описать все нюансы Material Design (в пересчете на бумажный формат ты нафигачил целых полторы статьи :). — Прим. ред.), тем более что не все из них можно реализовать библиотеками совместимости в преLollipop версиях Андроида. Наиболее тяжело в этом плане дела обстоят с анимацией. Например, у нас не получится увидеть Ripple-эффект (расходящиеся круги при нажатии на кнопку), так как данная анимация реализуется аппаратно и недоступна для старых устройств. Разумеется, это решается сторонними библиотеками, но об этом мы поговорим в следующий раз.
Ознакомиться с гайдами по Material Design можно (даже нужно!) на официальном сайте Google, а по адресу доступен перевод на русский язык.
Android AppCompat vs. Design Support Library
После выхода в свет Android 5 в SDK от Google произошло существенное обновление библиотеки AppCompat (в девичестве ActionBarCompat), получившее седьмую версию aka v7. Самой вкусной в этой версии стала возможность использования элементов Material Design в ранних версиях Андроида — начиная с 2.1 (API Level 7). Один из таких элементов — виджет Toolbar, пришедший на замену скучному ActionBar — панели, расположенной в верхней части активности (той самой, где висит «гамбургер», открывающий боковое меню). Кроме того, новое Material-оформление коснулось и других стандартных элементов: EditText, Spinner, CheckBox, RadioButton, Switch, CheckedTextView.
Помимо этого, были добавлены новые библиотеки — RecyclerView (крутейшая замена ListView), CardView (карточка) и Palette (динамическая палитра). К слову, в декабрьском Хакере эти элементы уже были рассмотрены — срочно ищи и изучай, повторяться не будем.
Казалось бы, мы у цели, вот оно — счастье, но, взглянув, например, на почтовый клиент Gmail в том же Android 4, потихоньку начинаешь понимать, что с одной лишь AppCompat такое приложение не накодишь. Ведь по какой-то космической причине в библиотеке AppCompat нет даже плавающей кнопки — едва ли не главного элемента Material Design.
К счастью, в Google рассуждали точно так же, но, правда, почему-то не стали дополнять AppCompat, а представили совершенно новую библиотеку совместимости — Design Support Library. Здесь уже все по-взрослому: удобное боковое меню (Navigation View), плавающая кнопка (Floating Action Button), всплывающее сообщение (Snackbar), анимационный Toolbar и многое другое. Далее мы зарядим все библиотеки в обойму знаний и познакомимся поближе с этими прекрасными нововведениями.
Хочу только заметить, что библиотеки и виджеты можно использовать как по отдельности, так и все вместе.
Итак, обновляем SDK, запускаем Android Studio и начинаем кодить.
Импорт библиотек
Так как мы используем Android Studio, импорт модулей необходимо выполнять в секции dependencies файла build.gradle проекта:
На момент выхода журнала уже будет доступна версия библиотек под номером 23.1.1, но для нас это не принципиально. Кстати, IDE любезно подскажет номер последней версии, а также автоматически скачает ее из репозитория, если она отсутствует.
CoordinatorLayout, Toolbar и все-все-все
Начнем с весьма эффектного компонента — CoordinatorLayout, позволяющего связывать (координировать) виджеты, помещенные в него (по сути, CoordinatorLayout является продвинутым FrameLayout). Чтобы было понятно, на рис. 3 приведено исходное состояние фрагмента приложения. Стоит только начать перелистывать список, как размер заголовка плавно вернется к традиционному размеру (уменьшится), освобождая место для полезной информации (рис. 4). И это все, что называется, прямо из коробки, без всяких костылей.
 Рис. 3. Было |  Рис. 4. Стало |
Разметка фрагмента приведена ниже (несмотря на размер, код достаточно тривиален):
Идеологически AppBarLayout в чем-то напоминает вертикальный LinearLayout, элементы которого могут вести себя по-разному (в зависимости от флагов) при прокручивании содержимого. В приведенном примере используется виджет CollapsingToolbarLayout, являющийся удобной оберткой для компонента Toolbar. Собственно, CollapsingToolbarLayout специально спроектирован для использования внутри AppBarLayout. Размер самого AppBarLayout в развернутом виде определяется параметром layout_height, и в листинге он равен 192dp.
Наконец, виджеты, непосредственно определяющие внешний вид фрагмента (активности), — Toolbar («гамбургер», заголовок, кнопки меню) и ImageView (фон) завернуты в CollapsingToolbarLayout. Флаг layout_collapseMode=»parallax» у ImageView обеспечивает плавное затенение фонового изображения при сворачивании Toolbar’a. По опыту использования могу сказать, что «параллакс» работает не на всех устройствах.
Все вышесказанное может показаться сложным и неочевидным, но огромный плюс данного подхода в том, что вся логика совместной работы виджетов определена в файле разметки, а не в коде. Кстати, о последнем:
Вот, собственно, и весь код! SetSupportActionBar переключает ActionBar на Toolbar с сохранением почти всех свойств и методов первого. В частности, устанавливается заголовок с помощью setTitle. Полное описание виджета Toolbar доступно на официальном сайте Android Developers.
Далее находим ImageView фона и с помощью сторонней библиотеки Picasso устанавливаем соответствующее изображение. Обычно я не склонен к критике Google, но тут не могу удержаться. Неужели за столько времени существования Android нельзя было написать нормальную стандартную библиотеку для загрузки изображений? Чтобы метод setImageResource не вызывал Out of Memory для изображений в нормальном разрешении? Гайдлайны призывают делать яркие и стильные приложения со множеством графики, а такая вещь, как загрузка картинки, реализована спустя рукава. Нет, конечно, можно использовать BitmapFactory, придумывать кеширование, но это решение так и просится в отдельную библиотеку, что, собственно, сделано и в Picasso, и в UniversalImageLoader. Одним словом, непонятно.
Snackbar
Snackbar представляет собой небольшое информационное окно, расположенное в нижней части активности (рис. 5). Помимо информационного сообщения, имеется небольшая плоская кнопка (так называемый Action), позволяющая взаимодействовать с пользователем (например, отменить удаление сообщения). После тайм-аута Snackbar автоматически закрывается (как и традиционный компонент Toast).
Рис. 5. Snackbar собственной персоной
Вызывается виджет совсем несложно:
Кстати, если в разметке не использовать рассмотренный выше CoordinatorLayout, то при вызове Snackbar может получиться наложение виджетов (рис. 6). Так происходит потому, что FAB ничего не знает ни о каком Snackbar и момент появления на экране последнего не отслеживает. Если же применить иерархию CoordinatorLayout, то все отображается корректно (рис. 7).
Рис. 6. CoordinatorLayout отдыхает 
Рис. 7. CoordinatorLayout работает
EditText Floating Labels
В Material Design появилась новая «обертка» вокруг стандартного элемента ввода текста EditText (рис. 8), расширяющая его функциональность. Текст подсказки (Hint) теперь не пропадает, а плавно перемещается вверх. Так, если нажать на поле «Комментарий» (см. рис. 8), текст уменьшится и займет свое положение аналогично верхнему полю. Код разметки данного элемента (паттерн «Декоратор» во всей красе):
Nested Toolbar
Помимо рассмотренных в декабрьском Хакере карточек (CardView), существует также Card Toolbar (или Nested Toolbar), то есть карточка, перекрывающая часть Toolbar’а. На рис. 8 приведена именно такая карточка. По ссылке доступен пример использования.
Кроме того, имеется возможность показать сообщение об ошибке в правой части виджета. Реализуется это в коде следующим образом:
Сообщение об ошибке также можно показать непосредственно под строкой ввода (рис. 9):
Рис. 9. Вывод ошибки с помощью TextInputLayout
Navigation Drawer
Navigation Drawer — панель с элементами меню приложения, которая выдвигается при нажатии на «гамбургер» или по свайпу влево (рис. 10). Панель состоит из двух элементов: заголовка, где обычно располагается фоновое изображение, текущий аккаунт с аватаром и тому подобное, и собственно самого меню.
Рис. 10. Пример Navigation Drawer
Разметка активности, содержащей Navigation Drawer, должна удовлетворять шаблону
DrawerLayout должен быть корневым элементом в иерархии разметки и включать в себя, помимо элементов GUI (Toolbar, фрагменты и так далее), виджет NavigationView. У последнего имеются два важных свойства: headerLayout и menu. Первый, необязательный, определяет файл разметки заголовка (в папке layout), второй, очевидно, — самого меню (в папке menu).
Заголовок может быть каким угодно (в рамках здравого смысла и гайдов Google, разумеется). Например, для простого текста на фоне с цветом colorPrimaryDark (ты же читал предыдущую статью?):
Формат разметки меню стандартен:
В приведенном листинге задаются два пункта меню, и только один из них может быть активным (подсвечивается), за что отвечает флаг checkableBehavior=»single». Дополнительно создаются два элемента подменю, отделенные от основного меню заголовком title=»@string/nav_sub_menu».
В код приложения нужно добавить лишь пару (хорошо, немного больше) строк:
и переопределить метод onOptionsItemSelected, чтобы при нажатии на «гамбургер» открывалось именно боковое меню:
Осталось только написать обработчик элементов меню:
Здесь находим наш NavigationView и вешаем на него новый обработчик onNavigationItemSelected, который, во-первых, устанавливает текущий элемент меню setChecked(true) ; во-вторых, закрывает Navigation Drawer; в-третьих, делает все остальное, то есть выводит на экран сообщение (Toast).
TabLayout
Под занавес рассмотрим прокачанную версию вкладок (Tabs). Вернемся к разметке раздела CoordinatorLayout и после Toolbar’а добавим два виджета:
Всю работу будет выполнять TabLayout, а старенький ViewPager нужен для того, чтобы получить горизонтальную прокрутку между вкладками (рис. 11).
Рис. 11. Три вкладки
В методе onCreate, как всегда, находим виджеты и настраиваем вкладки:
Для работы с вкладками необходим адаптер, который будет хранить информацию обо всех Tab’ах. Каждая вкладка представляет собой фрагмент и содержит в разметке только текстовую метку (TextView) — «один», «два» или «три».
В приведенном адаптере содержатся два списка — mFragmentList, для хранения фрагментов вкладок, и mFragmentTitleList, для хранения заголовков TabLayout. В нашем простом случае все фрагменты одинаковы, а значит, класс TabFragment тоже один:
NewInstance возвращает новый экземпляр фрагмента (так называемый фабричный метод) и сохраняет в качестве аргумента (putString) переданный заголовок вкладки (title). В onCreateView этот заголовок извлекается и отображается на текстовой метке.
SwipeRefreshLayout, или «Потяните, чтобы обновить. »
За бортом остался простой, но очень популярный виджет — SwipeRefreshLayout. Он бывает нужен, когда в приложении есть обновляемая информация и пользователь, потянув контент жестом вниз, а потом отпустив, может ее актуализировать. Работать с ним очень просто, вот подробный пример.
Выводы
Как видишь, работать с новыми виджетами на старых Андроидах можно, и даже без велосипедов, мотыг и костылей. Очень приятно, что Google не (совсем) забывает о своем наследии. Так что, если ты разрабатываешь новое приложение, Material Design — лучший выбор, а вот вопрос о целесообразности тотальной переделки интерфейса уже имеющихся (читай: отлаженных) Holo-приложений в Material пока остается открытым. Как всегда, время покажет.
Уголок скептика
Material Design, безусловно, хорошая попытка систематизировать элементы дизайна и их поведение в GUI. Если разработчики будут следовать гайдлайнам Google, количество вырвиглазных приложений, вероятно, снизится. И это хорошо.
С другой стороны, не появится ли слишком много одинаковых приложений? На том же Droidcon в 2015 году в докладе, посвященном Material Design, были представлены в качестве примеров того, как не стоит делать, несколько платных приложений, точь-в-точь повторяющих примеры из SDK. Google не устает напоминать, что гайдлайны носят рекомендательный характер, но стоит только взглянуть хотя бы на одну такую «рекомендацию» (рис. 13), как становится как-то неуютно, если сделать отступ не 8 dp, а 10 dp. Почему, собственно, 8 dp? Откуда взялось это число? Сетка? Почему не, допустим, 16 dp?
Еще вопрос: если Action всего один, где его располагать? Слева? По центру? Одним словом, гайдлайны гайдлайнам рознь, но иметь свой взгляд на Material Design как в прямом, так и в переносном смысле лишним точно не будет.
Рис. 13. Простор для фантазии?