Как стать автором
Обновить

Комментарии 4

А не могли бы вы пояснить в чем заключается проблема обратной совмести и конфликт между Toolbar и NavigationDrawer при использовании варианта со вьюхами? Второй момент, что то мне кажется, что мы можем получить вьюху стрелки по id android.R.id.home.
Хорошие вопросы.

По поводу конфликта: Проблема в том, что 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 — обходитесь без него.
Спасибо за комментарий, попробую больше поэкспериментировать с Toolbar не задавая его как ActioanBar и проверю как это будет работать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории