Навигация для андроид студио

Шаблон Navigation Drawer Activity

Метки: NavigationView , DrawerLayout , Material Design

Рассмотрим шаблон Navigation Drawer Activity. Создадим новый проект и выберем нужный шаблон.

Для беглого знакомства можете сразу запустить проект и посмотреть его в действии. При запуске приложение выглядит как обычная программа «Hello World». Но есть и отличия. Нажмите на значок в виде трёх горизонтальных полосок в заголовке. Значок в документации называется «гамбургером» (Hamburger menu). Это официальная позиция Гугла. Но в реальности значок символизирует полосатых котов (никому не рассказывайте). При нажатии слева вылезет навигационная шторка. Шторка работает как обычная шторка в ванной. По высоте она занимает весь экран, включая системную область. Можете подвигать шторку вперёд-назад, чтобы увидеть, что верхняя кромка шторки в системной области полупрозрачна и не закрывает системные значки. Подобное поведение доступно на устройствах под Android 5 и выше. На старых устройствах шторка находится под системной панелью. Недавно стал проверять работу под Android 8.0 и увидел, что шторка теперь не закрывает системную панель. Ниже для сравнения я привёл два варианта.

Шторка закрывает системную панель Шторка не закрывает системную панель

Сама шторка состоит из двух основных частей — в верхней части находится картинка и текст, а в нижней — меню со значками. Меню в свою очередь разделено на две группы. В верхней части значки можно выбрать и выбранный пункт останется выделенным. В нижней части меню пункты не выделяются. Уберите шторку обратно и вызовите теперь её не нажатием на значок гамбургера, а движением пальца от края экран в центр. Получилось? Отлично, а теперь выдвигайте шторку медленно и наблюдайте за значком гамбургера. Вы увидите, что во время движения значок трансформируется. К сожалению, шторка закрывает значок и непонятно, во что превращаются три полоски. А превращаются они в три кота ж! стрелку. Позже я покажу, как увидеть её. А может не покажу, я ещё не решил.

Возвращаемся в студию и начинаем изучать код проекта.

Если открыть файл activity_main.xml в режиме Design, то можно увидеть, как будет выглядеть приложение с открытой шторкой.

Небольшие расхождения имеются, но в целом совпадает с реальным приложением.

Посмотрим на его содержание.

Сейчас важно запомнить, что за выдвигающую шторку отвечает элемент NavigationView, который входит последним в контейнере DrawerLayout и представляет собой навигационное меню. А перед меню находится вставка include, указывающая на разметку app_bar_main.xml.

Атрибут tools:openDrawer позволяет указать студии, что навигационное меню нужно отобразить в раскрытом виде в режиме просмотра разметки.

NavigationView

В 2014 году Google показал новый дизайн и различные новые примеры по навигации. Но вначале они использовали подручные средства, которые были под рукой — фрагменты.

Спустя год компания разработала на основе предка FrameLayout новый компонент NavigationView, который стал частью библиотеки Android Design Support Library.

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

Необходимые рекомендации по созданию навигационной выдвижной шторки можно найти на странице Navigation drawer — Patterns.

Перейдём к деталям.

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

Тег NavigationView содержит ссылку на собственную разметку в атрибуте app:headerLayout, который указывает на файл nav_header_main.xml (верхняя часть шторки), а также на меню в атрибуте app:menu, который ссылается на ресурс меню menu/activity_main_drawer.xml.

Откроем файл nav_header_main.xml и посмотрим на разметку шторки.

Разметка состоит из ImageView и двух TextView, размещённых в контейнере LinearLayout. Фон контейнера определён в ресурсе drawable/side_nav_bar.xml и представляет собой градиент.

Остальные атрибуты понятны и не требуют пояснений.

Можно (но не нужно) настроить верхнюю часть шторки не через XML, а программно.

После обновления одной из версий библиотеки Design Support, доступ к шапке осуществляется теперь через другой код.

Теперь рассмотрим ресурс навигационного меню res/menu/activity_main_drawer.xml.

Принцип создания элементов меню остался стандартным. Каждый пункт меню представляет собой тег item с указанием значка и текста. Для группировки используется элемент group. Поведение элементов меню в группе регулируется атрибутом android:checkableBehavior. В примере используется значение single — при нажатии на пункт меню, он останется выделенным (принцип переключателя RadioButton). Всего доступно три варианта.

• single – можно выбрать один элемент группы (переключатель)
• all — можно выбрать все элементы группы (флажок)
• none – элементы не выбираются

В библиотеке Android Support Design версии 23 вариант all не работает и будет действовать, как со значением single.

Также следует обратить внимание, что теперь проект ссылается на векторные рисунки, которые находятся в папке drawable-21.

Осталось рассмотреть тег include, который ссылается на файл ресурса res/layout/app_bar_main.xml. Он вам будет знаком по шаблону Blank Activity, который мы изучали в статье Библиотека Android Support Design. Только там он находился в файле activity_main.xml, а здесь его перенесли в файл app_bar_main.xml. Всё остальное осталось без изменений. Повторяться не будем.

Теперь изучим код активности для работы со шторкой.

В классе активности реализуется интерфейс OnNavigationItemSelectedListener с его методом onNavigationItemSelected():

Логика кода ничем не отличается о работы с обычным меню. Определяется идентификатор выбранного пункта и далее вам нужно написать свой код. Затем вызывается метод closeDrawer() для закрытия шторки.

Добавим код для первого пункта меню.

При нажатии кнопки «Назад» проверяется состояние шторки. Если шторка открыта (isDrawerOpen()), то её закрываем с помощью метода closeDrawer().

В методе onCreate() происходит инициализация шторки.

Теперь поговорим об изменениях, которые можно внести в проект.

Хотите выдвигать шторку справа? Установите значение end у атрибута layout_gravity. Обычно используется для стран с обратным порядком букв.

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

Тем не менее, можно реализовать забавный эффект — добавить вторую шторку на экран. Первая будет работать главной и реагировать на нажатие значка, а вторая будет дополнительной для вывода какой-то информации. Достаточно в разметку добавить второй NavigationView с атрибутом android:layout_gravity=»end»

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

Для изменения цвета значков и текста в навигационном меню используйте атрибуты app:itemIconTint и app:itemTextColor.

Данным атрибутам соответствуют методы setItemIconTintList() и setItemTextColor() компонента NavigationView.

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

Напоследок покажу превращение значка гамбургера в стрелку в явном виде, как и обещал в начале статьи. Напомню, что по рекомендации Material Design шторка должна закрывать всю область экрана. Но если вы хотите поместить шторку под заголовком, то следует немного поправить разметку. Откроем файл app_bar_main.xml и вырежем из него небольшой кусок. Затем в файле activity_main.xml добавим LinearLayout в качестве корневого контейнера и вставим скопированный ранее кусок кода.

Смотрим на значок.

Сама анимация значка зависит от переменной toggle (объект класса ActionBarDrawerToggle). Если вы её уберёте, то никакого значка в заголовке приложения не будет.

Можно поменять цвет значка гамбургера. Откроем файл стилей res/values/styles.xml и добавим:

Элемент spinBars со значением true позволяет использовать анимацию. В противном случае значок будет статичным.

Навигация

В шаблоне присутствует метод onNavigationItemSelected() с аннотацией @SuppressWarnings(«StatementWithEmptyBody») (Оператор с пустым телом). Нам нужно добавить свой код для навигации, который должен реагировать на нажатия в меню шторки. Нам понадобятся фрагменты. Для примера создадим первый фрагмент.

Разметка для первой активности.

По такому же образу создайте второй фрагмент SecondFragment и т.д.

Определим RelativeLayout в файле content_main.xml в качестве контейнера.

Теперь можем написать недостающий код для навигации по фрагментам в MainActivity.

Добавляем счётчик в меню шторки

Откройте файл res/menu/activity_main_drawer.xml и добавьте атрибут app:actionViewClass=»android.widget.TextView» ко второму и третьему элементу меню из шаблона. Теперь эти элементы будут связаны с текстовыми метками.

Объявим текстовые метки и инициализируем их в методе onCreate(). В отдельном методе будем управлять их свойствами.

Вы можете переделать метод под себя, чтобы динамически изменять показания счётчика.

Сдвигаем содержимое экрана

При выдвижении шторки можно сдвинуть основное содержание. Потребуется небольшая модификация кода. Для начала нужно присвоить идентификатор контейнеру ConstraintLayout в content_main.xml.

В MainActivity добавим экземпляру ActionBarDrawerToggle метод onDrawerSlide() и сдвинем содержимое на определённую величину. При желании можно также изменить размер, используя второй параметр метода slideOffset.

Дополнительное чтение

Библиотека mxn21/FlowingDrawer с прикольным эффектом.

Источник

Android navigation component. Простые вещи, которые приходится делать самому

Всем привет! Хочу рассказать об особенностях в работе Navigation Architecture Component, из-за которых у меня сложилось неоднозначное впечатление о библиотеке.

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

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

Итак, вот сценарии, при реализации которых ожидания по функционалу не совпали с реальностью в реализации:

• переключение между пунктами меню в navigation drawer
• открытие новой Activity со своим графом навигации
• передача параметров в startDestination

Переключение между пунктами меню

Это одна из тех функций, которые повлияли на решение использовать Navigation Component.

Нужно всего лишь сделать одинаковыми id пунктов меню

и id экранов (destination в графе навигации)

затем нужно связать меню с контроллером навигации:

Навигация в меню заработала — ну разве не чудо?!

Обратите внимание на «гамбургер» (иконка меню), при переключении между пунктами меню он меняет своё состояние на кнопку «назад». Такое поведение показалось непривычным (привычное — как в приложении play market) и, какое-то время, я пытался разобраться, что же сделал не так?

Всё так! Перечитав документацию по принципам навигации (а именно: пункты два и три), понял, что «гамбургер» показывается только для startDestination, вернее так: кнопка «назад» показывается для всех, кроме startDestination. Ситуацию можно поменять применив различные уловки в подписке (addOnNavigatedListener()) на изменение destination, но их даже описывать не стоит. Работает так, нужно смириться.

Открытие новой Activity

Activity может выступать в качестве navigation host и, в то же время, в графе навигации может выступать в роли одного из destination. Открытие Activity без вложенного графа навигации работает как ожидается, то есть вызов:

осуществит переход (как в случае с фрагментами) и откроет запрошенную Activity.
Гораздо интереснее рассмотреть случай, когда целевая Activity сама выступает в роли navigation host, то есть вариант 2 из документации:

В качестве примера давайте рассмотрим Activity для добавления заметки. В ней будет основной фрагмент с полями ввода EditFragment, он в графе навигации будет startDestination. Давайте положим, что при редактировании нам нужно прикрепить фото, для этого будем переходить к PhotoFragment для получения снимка с камеры. Граф навигации будет выглядеть так:

EditActivity мало отличается от MainActivity. Основное отличие в том, что на EditActivity нет меню:

Activity открывается, навигация внутри неё работает:

Опять обратим внимание на кнопку навигации в toolbar — на стартовом EditFragment нет кнопки «Назад к parent Activity» (а хотелось бы). С точки зрения документации, тут всё законно: новый граф навигации, новое значение startDestination, на startDestination не показывается кнопка «Назад», конец.

Для тех, кому хочется вернуть привычное поведение c parent activity, сохранив при этом функционал переключения между фрагментами, могу предложить такой костыль подход:

Подписка нужна для того, чтобы для NavigationUI.ActionBarOnNavigatedListener все destination не являлись startDestination. Таким образом NavigationUI.ActionBarOnNavigatedListener не будет скрывать кнопку навигации (за деталями стоит обратиться к исходникам). Добавим к этому обработку onSupportNavigateUp() штатным образом на startDestination и получим то, что хотелось.

Стоит сказать, что решение это далеко от идеала хотя бы потому, что это неочевидное вмешательство в поведение библиотеки. Полагаю, могут возникнуть проблемы в случае использования deep links (ещё не проверял).

Передача параметров в startDestination

В Navigation Component есть механизм передачи параметров от одного destination другому. Есть даже инструмент для обеспечения безопасности типов за счёт кодогенерации (неплохо).

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

Вернёмся к EditActivity, достаточно привычный сценарий, когда одна Activity используется для создания и редактирования объектов. При открытии объекта для редактирования в Activity нужно передать, например, id объекта — давайте сделаем это штатным образом:

Я добавил параметр непосредственно в корневой элемент графа (navigation), но можно добавить в целевой фрагмент. От этого изменится только способ получения параметра.

Я добавил add и edit action’s в одни из фрагментов, так они будут доступны только из него.

В этом примере ImportFragmentDirections — автоматически сгенерированый safe-args класс.

Вы, наверняка, обратили внимание на особенности получения параметров в EditFragment. Так работает, потому что edit action (из пункта 1) передаёт аргументы в EditActivity, а она, в свою очередь, почему-то жадничает не передаёт её в граф (например, вызовом navController.graph.setDefaultArguments()). Эту особенность можно обойти, если вручную подготовить navigation controller. Один из способов описан на StackOwerflow.

Пожалуй, наибольшая сложность возникнет при одновременном использовании в качестве startDestination и обычного destination. То есть, при переходе и передаче параметров в startDestination из любого другого destination этого графа, фрагменту придётся самостоятельно определять, откуда извлекать параметры: из arguments или из intent.extras. Это нужно иметь ввиду при проектировании переходов с передачей параметров.

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

Источник