К сожалению, нет (по крайней мере, не было, когда я последний раз создавал проект). Библиотеки надо добавлять самому в зависимости от функционала. Для определенных вещей есть обратная совместимость (c помощью google support библиотек), например для Toolbar или для RecyclerView, а вот для Ripple Effect например ее можно добится только подключением стороних библиотек.
Просто не было необходимости поддерживать другие языки. Как будет свободное время проверю как класс рисует русские буквы, если все ок, подправлю проверку. Убирать ее нельзя т.к есть арабский, китайский и другие языки и надо тестить как все это будет выглядеть.
Artem_007 да, для ripple effect на андроиде ниже 5 придется использовать сторонние библиотеки( Поэтому я обычно использую отдельные, стандартные селекторы для Андроида < 5, имхо раз уж Google не реализовали обратную совместимость ripple effect в своих support библиотеках, то лучше просто использовать стандартные селекторы в зависимости от версии ОС.
Nagg awesome-android-ui — очень крутая подборка библиотек, частенько заглядываю туда за вдохновлением. Мои фишки не требуют сторонних библиотек (кроме Palette от Google из первого примера) + показаны на примере реальной апликации. Поэтому одно другому не мешает :)
По поводу конфликта: Проблема в том, что 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» мы его всегда получим.
По поводу конфликта: Проблема в том, что 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» мы его всегда получим.