Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 4
А не могли бы вы пояснить в чем заключается проблема обратной совмести и конфликт между Toolbar и NavigationDrawer при использовании варианта со вьюхами? Второй момент, что то мне кажется, что мы можем получить вьюху стрелки по id android.R.id.home.
Хорошие вопросы.
По поводу конфликта: Проблема в том, что NavigationDrawer использует ActionBarDrawerToggle для управления меню и когда мы его создаём, то просто передаём ему Toolbar, а он сам решает где отобразить иконку и даже как эта иконка будет выглядеть. Пример:
В теории мы можем сами задать иконку + её место расположение и размеры, но на практике, в случаи кастомного layout, мне так и не удалось заставить ActionBarDrawerToggle выглядеть одинаково хорошо на Nexus 5 и Samsung Galaxy S2. У нас просто нет возможности нормально выровнять иконку с кастомным layout Toolbar-a. Возможно я что-то делал не так, но вариант с MenuItem показался мне более простым.
Ещё одна проблема совместимости с которой я сталкивался — это телефоны на которых язык по умолчанию с письмом справа налево (в моём случае иврит). Многие прошивки стараются адаптировать приложения и переворачивают Toolbar. В случаях кастомного layout, на Android 4.0 — 4.1 это приводило к непредвидимым последствиям (всё просто перемешивалось).
Уверен, что с этими проблемами можно справиться, поэтому и указал в статье такую возможность создания Toolbar, но мне кажется если Toolbar будет простым и можно уложиться в функционал MenuItem, лучше использовать этот вариант.
По поводу android.R.id.home: в идеале мы можем получить вью стрелки через это id, но на практике «стрелка» это виджет и никто не гарантирует нам, что её id будет именно android.R.id.home, всё зависит action bar для конкретной версии Android и версии support library. Кроме того, мы не можем быть уверены, что android.R.id.home всегда вернём нам View, а не MenuItem или другой обьект. На stackoverflow есть много жалоб на то, что findViewById(R.android.id.home) или findViewById(item.getItemId()) возвращает null. Например, хорошее объяснение проблемы есть в этом вопросе: stackoverflow
Вариант с Field видится мне более надёжным, если у класса Toolbar есть член с именем «mNavButtonView» мы его всегда получим.
По поводу конфликта: Проблема в том, что NavigationDrawer использует ActionBarDrawerToggle для управления меню и когда мы его создаём, то просто передаём ему Toolbar, а он сам решает где отобразить иконку и даже как эта иконка будет выглядеть. Пример:
ActionBarDrawerToggle mDrawerToggle = new ActionBarDrawerToggle(activity, mDrawerLayout,
(Toolbar) activity.findViewById(R.id.toolbar_actionbar),
R.string.sliding_menu, R.string.sliding_menu)
В теории мы можем сами задать иконку + её место расположение и размеры, но на практике, в случаи кастомного layout, мне так и не удалось заставить ActionBarDrawerToggle выглядеть одинаково хорошо на Nexus 5 и Samsung Galaxy S2. У нас просто нет возможности нормально выровнять иконку с кастомным layout Toolbar-a. Возможно я что-то делал не так, но вариант с MenuItem показался мне более простым.
Ещё одна проблема совместимости с которой я сталкивался — это телефоны на которых язык по умолчанию с письмом справа налево (в моём случае иврит). Многие прошивки стараются адаптировать приложения и переворачивают Toolbar. В случаях кастомного layout, на Android 4.0 — 4.1 это приводило к непредвидимым последствиям (всё просто перемешивалось).
Уверен, что с этими проблемами можно справиться, поэтому и указал в статье такую возможность создания Toolbar, но мне кажется если Toolbar будет простым и можно уложиться в функционал MenuItem, лучше использовать этот вариант.
По поводу android.R.id.home: в идеале мы можем получить вью стрелки через это id, но на практике «стрелка» это виджет и никто не гарантирует нам, что её id будет именно android.R.id.home, всё зависит action bar для конкретной версии Android и версии support library. Кроме того, мы не можем быть уверены, что android.R.id.home всегда вернём нам View, а не MenuItem или другой обьект. На stackoverflow есть много жалоб на то, что findViewById(R.android.id.home) или findViewById(item.getItemId()) возвращает null. Например, хорошее объяснение проблемы есть в этом вопросе: stackoverflow
Вариант с Field видится мне более надёжным, если у класса Toolbar есть член с именем «mNavButtonView» мы его всегда получим.
Теперь зададим Toolbar, как ActioanBar, это обеспечит нам обратную совместимость с предыдущими версиями Android (API Level < 21).Это не так, Toolbar будет работать с любой версией андроида. Запихивать его в Actionbar нужно тогда, когда разработчик ленится переносить логику по работе с Actionbar в новый API, или когда проект имеет много скринов и переход будет трудозатратен.
По новым гайдам NavigationDrawer закрывает Header, потому нету смысла более иметь ActionBarDrawerToggle — обходитесь без него.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Material Design. Динамический Toolbar на живом примере