Coordinatorlayout android что это

Овладение Coordinator Layout

На презентации Google I/O 15, компания Google представила новую версию библиотеки поддержки которая реализует несколько компонентов, сильно связанных со спецификациями Material Design, среди этих компонентов вы можете найти новые типы ViewGroup такие как AppbarLayout , CollapsingToolbarLayout и CoordinatorLayout .

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

CoordinatorLayout

Как и предполагает его название, цель и философия этой ViewGroup является координация view элементов, которые находятся внутри него.

Рассмотрим следующую картинку:

В этом примере можем видеть как view элементы размещены друг относительно друга, не прибегая к детальному просмотру, мы видим как одни View зависят от других. (мы поговорим об этом позже).

Это будет простейшая структура использования CoordinatorLayout :

Рассмотрим скелет данного layout. У этого CoordinatorLayout имеется только три дочерних элемента: AppbarLayout , прокручиваемый view и закрепленный FloatingActionBar .

AppBarLayout

Проще говоря, AppBarLayout это LinearLayout на стероидах, их элементы размещены вертикально, с определенными параметрами элементы могут управлять их поведением, когда содержимое прокручивается.

Это может прозвучать запутано сначала, но как, — «Лучше один раз увидеть, чем сто раз услышать», к вашему вниманию .gif-пример:

В данном случае AppBarLayout это синяя view, размещенная под исчезающим изображением, она содержит Toolbar , LinearLayout с заголовком и подзаголовком и TabLayout с несколькими вкладками.

Мы можем управлять поведением элементов AppbarLayout с помощью параметров: layout_scrollFlags . Значение: scroll в данном случае присутствует почти во всех элементах view, если бы этот параметр не был указан ни в одном из элементов AppbarLayout, он остался бы неизменным, позволяя прокручиваемому контенту проходить позади него.

Со значением: snap , мы избегаем попадания в полу-анимационного-состояния, это значит, что анимация всегда скрывает или отображает полный размер view.

LinearLayout который содержит заголовок и подзаголовок будет всегда отображен при прокручивании вверх, ( enterAlways значение), и TabLayout будет видим всегда так как на него не установлен ни один флаг.

Как видите настоящая мощь AppbarLayout определяется должным управлением его флагами прокрутки в определенных view.

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

Флаги AppbarLayout

SCROLL_FLAG_ENTER_ALWAYS : При использовании флага, view будет прокручиваться вниз не зависимо от других прокручиваемых view.
SCROLL_FLAG_ENTER_ALWAYS_COLLAPSED : Дополнительный флаг для ‘enterAlways’, который изменяет возвращаемый view к изначально прокручиваемому, при исчезновении высоты.
SCROLL_FLAG_EXIT_UNTIL_COLLAPSED : При выходе, view будет прокручен до тех пор пока не исчезнет.
SCROLL_FLAG_SCROLL : Элемент view будет прокручиваться в направлении события прокрутки.
SCROLL_FLAG_SNAP : В конце прокрутки, если view видим только частично, он будет докручен до его ближайшего края.

CoordinatorLayout Behaviors

Проведем не большой эксперимент, запустим Android Studio (>= 1.4) и создадим проект из шаблона: Scrolling Activity, ничего не изменяя, компилирием и вот что мы видим:

При рассмотрении сгенерированного кода, ни макеты layout ни java классы не имеют ничего относящегося к маштабированию анимации плавающей кнопки при прокрутке. Почему?

Ответ находится в исходном коде FloatingActionButton , с тех пор как Android Studio v1.2 включает java декомпилятор, с помощью ctrl/cmd + click мы можем проверить исходный код и посмотреть что происходит:

За маштабирование анимации отвечает новый элемент, представленый вместе с design library, под названием Behavior . В данном случае , который зависит от некоторых факторов включая прокрутку, показывать FAB или нет, интересно, не правда ли?

SwipeDismissBehavior

Продолжим углубление в код, если вы посмотрите внутрь пакета виджетов design support library, то сможете найти открытй клас под названием: SwipeDismissBehavior . С этим новым Behavior мы можем очень легко реализовать функцию свайп для отмены в наших шаблонах с CoordinatorLayout :

Custom Behaviors

Создать свой шаблон поведения (Behavior) не так и сложно как может показаться, для начала мы должны принять во внимание несколько основных элементов: child и dependency.

Child и dependency

child это элемент который усиливает поведение, dependency — тот кто будет обслуживать его как тригер для взаимодействия с child элементом. Посмотрим на пример, child — элемент ImageView, а dependency это Toolbar, таким образом, если Toolbar движется, ImageView тоже движется.

Теперь, когда мы определили концепт, можем поговорить о реализации, первым шагом будет наследование от:
, значение T будет класс который принадлежит view, что необходим нам для координации, в данном случае ImageView, после чего мы должны переопределить следующие методы:

• layoutDependsOn
• onDependentViewChanged

Метод: layoutDependsOn будет вызван каждый раз когда что-то случится в layout, чтобы вернуть true , как только мы определили dependency, в примере, этот метод срабатывает автоматически при прокручивании (т.к. Toolbar будет двигаться), таким образом, мы можем подать знак нашему child отреагировать соответствующим образом.

Всякий раз когда layoutDependsOn возвращает true будет вызван второй onDependentViewChanged . Вот тут-то мы и должны реализовать нашу анимацию, перевод или движения всегда зависят от предоставленной зависимости.

Источник

Что такое CoordinatorLayout?

Только что взглянул на демонстрационное приложение новой библиотеки дизайна поддержки Android. Он предоставлен Крисом Бэйнсом на github. Через приложение CoordinatorLayout активно используется. Кроме того, многие классы библиотеки дизайна поддержки, такие как FloatingActionButton , SnackBar , AppBarLayout и т. Д., Ведут себя по-разному при использовании внутри CoordinatorLayout .

Может ли кто-нибудь пролить свет на то, что такое CoordinatorLayout и чем он отличается от других ViewGroup в Android, или, по крайней мере, указать правильный путь к изучению CoordinatorLayout .

7 ответов

Вот она, которую вы ищете.

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

По этой ссылке вы увидите демонстрационные видеоролики всех вышеупомянутых просмотров.

Надеюсь это поможет 🙂

CoordinatorLayout — это сверхмощный FrameLayout .

По умолчанию, если вы добавляете несколько дочерних элементов к FrameLayout , они будут перекрывать друг друга. FrameLayout следует использовать чаще всего для хранения одного дочернего представления. Главная привлекательность CoordinatorLayout — это его способность координировать анимацию и переходы представлений внутри него. Используя только XML, вы можете описать макет, в котором FAB перемещается с пути входящей панели Snackbar, например, или иметь FAB (или любой другой View), который, по-видимому, прикреплен к другому виджету и перемещается по экрану с помощью виджет.

Вот основной источник учебник.

Важно отметить, что CoordinatorLayout не имеет врожденного понимания работы FloatingActionButton или AppBarLayout — он просто предоставляет дополнительный API в виде Coordinator.Behavior, который позволяет дочерним представлениям лучше контролировать события касания и жесты. а также объявлять зависимости друг от друга и получать обратные вызовы через onDependentViewChanged ().

Представления могут объявлять поведение по умолчанию с помощью аннотации CoordinatorLayout.DefaultBehavior (YourView.Behavior.class) или устанавливать его в файлах макета с помощью атрибута app: layout_behavior = «com.example.app.YourView $ Behavior». Эта структура позволяет любому представлению интегрироваться с CoordinatorLayout.

Доступен сейчас! Библиотека дизайна доступна сейчас, поэтому обязательно обновите репозиторий поддержки Android в SDK Manager. Затем вы можете начать использовать библиотеку дизайна с одной новой зависимостью:

Compile ‘com.android.support:design:22.2.0’ Обратите внимание, что поскольку библиотека дизайна зависит от библиотек поддержки Support v4 и AppCompat, они будут включены автоматически, когда вы добавите зависимость библиотеки дизайна. Мы также позаботились о том, чтобы эти новые виджеты можно было использовать в представлении «Дизайн» редактора макетов Android Studio (их можно найти в CustomView), что дает вам более простой способ предварительного просмотра некоторых из этих новых компонентов.

Библиотека дизайна, AppCompat и вся библиотека поддержки Android являются важными инструментами, предоставляющими строительные блоки, необходимые для создания современного, великолепно выглядящего приложения для Android без создания всего с нуля.

Чтобы быстро понять, что полезно в Android Документация:

Используйте CoordinatorLayout, чтобы просто контролировать реляционное поведение ваших представлений,

Например, если вы хотите, чтобы панель инструментов сворачивалась или скрывалась. Google упростил эту задачу, представив AppBarLayout и CollapsingToolbarLayout, которые лучше всего работают в CoordinatorLayout.

Другая наиболее часто используемая ситуация — это когда вы хотите, чтобы элемент FloatingActionButton прилипал к нижней части CollapsingToolbar и перемещался вместе с ним, помещая их под координаторLayout и используя app:layout_anchor=»@id/YourAppBarId» для клея (!) И app:layout_anchorGravity=»bottom|end» в качестве позиции вам будет достаточно, чтобы увидеть волшебное дело!

Используя этот макет в качестве контекста, дочерние представления будут лучше взаимодействовать и вести себя разумно, потому что они будут знать друг о друге через контекст CoordinatorLayout, это означает, что ваши кнопки FloatingAction больше не будут перекрываться SnackBar и т. Д.

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

CoordinatorLayout — это, по сути, макет фрейма с множеством возможностей что очевидно из названия, он автоматизирует координацию между своими детьми и помогает строить красивые виды. Его реализацию можно увидеть в приложении Google Play Store, как панель инструментов сворачивается и меняет цвет.

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

Еще одно замечание. Поскольку ОП специально спросил

Кроме того, многие классы библиотеки дизайна поддержки, такие как Floating Action Button, SnackBar, AppBarLayout и т. Д., Ведут себя по-разному при использовании внутри CoordinatorLayout.

Думаю, это из-за этого.

CoordinatorLayout — это сверхмощный FrameLayout.

FAB Button, SnackBar работает по концепции FrameLayout, и, поскольку сам CoordinatorLayout имеет функциональность FrameLayout, он может заставить другие представления вести себя иначе!

Что такое CoordinatorLayout? Не позволяйте причудливому названию ввести вас в заблуждение, это не что иное, как FrameLayout на стероидах.

Чтобы лучше понять, что такое / делает CoordinatorLayout , вы должны прежде всего понять / иметь в виду, что он означает для Координатора.

Если вы погуглите слово

Это то, что ты получаешь:

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

CoordinatorLayout (ViewGroup) объединяет различные элементы (дочерние представления) в (̶a̶ ̶c̶o̶m̶p̶l̶e̶x̶ ̶a̶c̶t̶i̶v̶i̶t̶y̶ ̶o̶r̶ ̶a̶n̶ ̶o̶r̶g̶a̶n̶i̶z̶ati̶i̶iiizati̶i̶iiiiz̶ati̶i̶ii

С помощью CoordinatorLayout дочерние представления гармонично взаимодействуют друг с другом, чтобы реализовать такие замечательные модели поведения, как

перетаскивание, смахивание, бросок или любые другие жесты.

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

CoordinatorLayout — это очень крутая функция Material Design, которая помогает создавать привлекательные и гармоничные макеты.

Все, что вам нужно сделать, это заключить дочерние представления в CoordinatorLayout.

Это дает нам макет, который можно прокрутить, чтобы свернуть панель инструментов и скрыть FloatingActionButton.

Источник

Перехватываем всё с помощью CoordinatorLayout Behavior

Вы не продвинетесь далеко в изучении Android Design Support Library, не столкнувшись с CoordinatorLayout. Множество View из Design Library требуют CoordinatorLayout. Но почему? Сам по себе CoordinatorLayout делает не так уж и много, если использовать его с View, входящими в состав Android фреймворка, то он будет работать, как обычный FrameLayout. Так откуда берётся вся его магия? Вот где на сцену выходит CoordinatorLayout.Behavior. Подключив Behavior к дочерней View у CoordinatorLayout, вы сможете перехватывать касания, оконные вставки (window insets), изменения размеров и макета (measurement и layout), а также вложенную прокрутку. Design Library широко использует Behavior чтобы добавить силу большинству функционалу, которую вы видите.

Создание Behavior

Создать Behavior довольно просто: наследуем наш класс от Behavior:

Обратите внимание на generic тип, указанный в этом классе. В данном случае мы указываем, что можем подключить FancyBehavior к любой View. Однако, если вы хотите позволить подключать ваш Behavior к определённому типу View, вы можете написать так:

Это может спасти вас от приведения к нужному вам подтипу View большого количества параметров в методах – просто и удобно.

Есть методы, чтобы сохранить как временные данные Behavior.setTag()/Behavior.getTag(), так и сохранить состояние экземпляра Behavior с помощью onSaveInstanceState()/onRestoreInstanceState(). Я призываю вас создавать Behavior как можно более “лёгкими”, но эти методы позволяют создавать Behavior с возможностью сохранения состояния.

Подключение Behavior

Конечно, Behavior не делает ничего сам по себе, чтобы мы могли им пользоваться, он должен быть подключен к дочерней View у CoordinatorLayout. Есть три основных способа сделать это: программно, в XML или автоматически с помощью аннотации.

Программное подключение Behavior

Когда вы думаете о Behavior как о чём-то дополнительно подключённом к каждой View внутри CoordinatorLayout, вас не должно удивить (если вы читали наш пост о макетах) то, что Behavior на самом деле хранится в LayoutParams каждой View – вот почему Behavior должен быть объявлен у View внутри CoordinatorLayout, так как только у этих View есть конкретный подтип LayoutParams, который может хранить Behavior.

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

Подключение Behavior через XML

Конечно, если постоянно делать всё через код – это может вызвать беспорядок. Как и в случае с большинством пользовательских LayoutParams, есть соответствующий layout_ атрибут, чтобы сделать всё тоже самое. В нашем случае это layout_behavior атрибут:

Здесь, в отличии от программного способа, будет всегда вызван конструктор FancyBehavior(Context context, AttributeSet attrs). Зато, в качестве бонуса, вы можете объявить любые другие пользовательские атрибуты и извлечь их из XML AttributeSet, это важно, если вы хотите (а вы захотите) дать возможность другим разработчикам настраивать функционал вашего Behavior через XML.

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

Автоматическое подключение Behavior

Если вы создаёте свою View, которой нужен свой Behavior (как было в случае с большинством компонентов в Design Library), тогда вы скорее всего захотите подключить Behavior по умолчанию, без постоянного ручного подключения через код или XML. Чтобы сделать это, нужно лишь добавить простую аннотацию сверху класса вашей View:

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

Перехват касаний

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

Без CoordinatorLayout, это обычно вовлекало подклассы каждой ViewGroup, как сказано в Managing Touch Events training. Однако в случае с CoordinatorLayout, он передаст вызовы метода onInterceptTouchEvent() методу onInterceptTouchEvent() вашего Behavior, позволяя вашему Behavior перехватывать касания. Если вернуть в этом методе true, то ваш Behavior получит все последующие касания с помощью метода onTouchEvent() – всё это происходит в тайне от View. К примеру, так работает SwipeDismissBehavior с любой View.

Есть другой, более сложный случай перехвата касаний – блокировка любого взаимодействия. Достаточно вернуть в методе blocksInteractionBelow() true. Скорее всего вы захотите как-то визуально показать, что взаимодействие заблокировано (чтобы пользователи не подумали, что приложение сломано) – вот почему стандартный функционал blocksInteractionBelow() зависит от значения getScrimOpacity(). Возвращая значение не равное нулю, разом рисуем цвет (getScrimColor(), чёрный по умолчанию) поверх View и отключаем взаимодействия касанием. Удобно.

Перехват оконных вставок

Скажем, вы читали блог Why would I want to fitsSystemWindows?. Там мы подробно обсуждали что делает fitsSystemWindows, но всё сводилось к представлению оконных вставок (window insets), необходимых чтобы избежать рисования под системными окнами (такими как status bar и navigation bar). Behavior может проявить себя и тут. Если ваша View fitsSystemWindows=“true”, то любой подключенный Behavior получит вызов метода onApplyWindowInsets(), в приоритете над самой View.

Примечание: в большинстве случаев, если ваш Behavior не обрабатывает оконные вставки целиком, он должен передать эти вставки с помощью ViewCompat.dispatchApplyWindowInsets(), чтобы убедиться что все дочерние View получат возможность увидеть WindowInsets.

Перехват Measurement и Layout

Это два ключевых компонента в том, как Android рисует View. Поэтому, имеет смысл, что Behavior, как перехватчик всех событий, так же первым получит уведомления об изменении размера и макета путём вызова методов onMeasureChild() и onLayoutChild() .

К примеру, давайте возьмём любой generic ViewGroup и добавим к нему maxWidth. Как показано в классе MaxWidthBehavior.java.

Создание generic Behavior, который сможет работать с любыми View, весьма удобно. Но помните, что вы можете упростить себе жизнь, обдумав будет ли Behavior использоваться только внутри вашего приложения (не все Behavior поголовно должны быть generic!).

Понимание зависимостей между View

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

Behavior может сделать View зависимыми друг от друга двумя разными путями: когда View связана (anchor) с другой View (подразумеваемая зависимость) или когда вы явно возвращаете true в методе layoutDependsOn().

Связка возникает, когда ваша View внутри CoordinatorLayout использует layout_anchor атрибут. Этот атрибут, совмещённый с layout_anchorGravity, позволяет вам эффективно связать положение двух View вместе. К примеру, вы можете связать FloatingActionButton с AppBarLayout, тогда FloatingActionButton.Behavior будет использовать неявную зависимость, чтобы спрятать FAB, если AppBarLayout будет прокручена за граница экрана.

В любом случае, ваш Behavior получит вызовы метода onDependentViewRemoved(), когда зависимая View была удалена и onDependentViewChanged(), всякий раз как зависимая View была изменена (изменился размер или позиция).

Большинство классного функционала Design Library работает благодаря возможности связки View вместе. Возьмите к примеру взаимодействие между FloatingActionButton и Snackbar. Behavior у FAB зависит от добавленных в CoordinatorLayout экземпляров Snackbar, затем, используя вызов метода onDependentViewChanged(), перемещает FAB выше, чтобы не допустить перекрытие Snackbar.

Примечание: когда вы добавляете зависимость, View всегда будет размещена после зависимой View, независимо от последовательности в разметке.

Вложенная прокрутка

О, вложенная прокрутка. Я лишь слегка коснусь этой темы в посте. Нужно иметь в виду о нескольких вещах:

1. Вы не должны объявлять зависимости от View c вложенной прокруткой. Каждая View внутри CoordinatorLayout может получить события вложенной прокрутки.
2. Вложенная прокрутка может возникнуть не только у View внутри CoordinatorLayout, но и у любой дочерней View (например, “ребёнок” “ребёнка” “ребёнка” у CoordinatorLayout).
3. Я буду называть это вложенной прокруткой, но на самом деле под ним будет пониматься и просто прокрутка и быстрая прокрутка (fling).

События вложенной прокрутки начинаются с метода onStartNestedScroll(). Вы получите оси прокрутки (горизонтальная или вертикальная – можем легко игнорировать прокрутку в определённом направлении) и должны вернуть true, чтобы получить дальнейшие события прокрутки.

После того как вы вернёте true в методе onStartNestedScroll(), вложенная прокрутка работает в два этапа:

• onNestedPreScroll() вызывается перед тем как прокручиваемая View получила событие прокрутки и позволяет вашему Behavior обработать часть или всю прокрутку (последний int[] параметр – это “исходящий” параметр, где вы можете указать какую часть прокрутки обработал Behavior).
• onNestedScroll() вызывается как только прокручиваемая View была прокручена. Вы получите значение насколько View была прокручена и необработанные значения.

Есть аналогичные методы и для быстрой прокрутки (но метод обработки pre-fling должен обрабатывать либо всю прокрутку, либо не обрабатывать вовсе).

Когда вложенная (либо быстрая) прокрутка заканчиваются, вы получите вызов метода onStopNestedScroll(). Это обозначает окончание прокрутки и ожидание нового вызова метода onStartNestedScroll() перед тем как начнётся новая прокрутка.

Возьмите к примеру случай, когда вы хотите спрятать FloatingActionButton, когда прокручиваем вниз и показать FAB, когда прокручиваем вверх. Для этого нужно переопределить методы onStartNestedScroll() и onNestedScroll(), как видно в ScrollAwareFABBehavior.

И это только начало

Если каждая отдельная часть у Behavior лишь интересна, то когда они все вместе – начинается магия. Я очень рекомендую посмотреть исходный код Design Library, чтобы узнать больше возможностей. Расширение для Chrome Android SDK Search всё ещё одно из моих любимых ресурсов для исследования кода AOSP (Android Open Source Project). Помимо этого вы можете найти последние версии исходного кода по пути /extras/android/m2repository.

Дайте мне знать, как вы используете полученные основы о том, что может Behavior хэштегом #BuildBetterApps.

Присоединяйтесь к обсуждению на Google+ и подписывайтесь на Android Development Patterns Collection для ещё большей информации!

Источник