LayoutInflater
Однажды я пытался раскрыть вам тайное значение названия метода inflate() — слово inflate происходит от словосочетания in flat — в квартиру. Существует старинная традиция запускать в квартиру первым кота, который исследует все закоулки дома и заявляет о своём согласии жить в нём. Однако, мы сделаем вид, что поверили официальной версии, что по-английски inflate переводится как надувать, т.е. мы как бы надуваем данными из XML-файла объекты View.
Мы рассмотрим надувание компонентов применимо к LayoutInflater. Существует также класс MenuInflater, который использует тот же принцип.
Фрагменты тоже часто используют механизм надувания. Обратите внимание на сигнатуру метода onCreateView():
Сам механизм надувания прост и не требует особых объяснений, изучения достоин один аспект.
Вероятно, вам не раз приходилось писать/копировать такой код:
Даже у меня на сайте есть такие примеры. Недавно я заметил, что среда разработки ругается на последний параметр null.
Оказывается, это неправильно. Давайте изучать этот код.
Существует две версии метода inflate() для стандартных приложений.
В первом параметре указывается идентификатор ресурса разметки, который мы собираемся надуть. Во втором параметре указывается корневой компонент, к которому нужно присоединить надутые объекты. В третьем параметре (если он используется) указывается, нужно ли присоединять надутые объекты к корневому элементу.
LayoutInflater автоматически пытается присоединить надутые компоненты к корневому элементу. Иногда сама среда разработки может создать заготовку с использованием null, чтобы избежать возможного краха приложения. И разработчики используют предложенный вариант, хотя можно было использовать второй вариант метода с тремя параметрами.
Но давайте узнаем, чего мы лишаемся, когда используем null для корневого элемента.
Надувание компонентов часто применяется в адаптерах, когда разметка отдельного элемента списка задаётся в XML-файле, а затем динамически конвертируется в набор компонентов в методе getView():
Среда разработки заругалась. Исправим null на parent, который по названию вроде подходит под корневой элемент. Однако, запустив проект, мы получим ошибку. Йожкин кот, что мы наделали?!
Вспоминаем, что есть другая версия метода и исправляем на следующий вариант.
Пример работает, предупреждение не выводится. Но осадочек остался.
При использовании null среда разработки как-бы пытается сказать: «Я не знаю, какой элемент является родительским, поэтому прости, между нами всё кончено «, я буду использовать null.
Тогда зачем нам этот родительский элемент? На самом деле он может сыграть важную роль в различных ситуациях.
Проблемы могут возникнуть при использовании атрибутов android:layout_xxx в родительском элементе. В результате, не зная ничего о родителе, мы не можем использовать его LayoutParams и система будет игнорировать вашу разметку. А вы будете думать, что это баг.
Без LayoutParams родительский ViewGroup надует компоненты с настройками по умолчанию. И в большинстве случае это вполне работает.
Рассмотрим конкретный пример. Создадим разметку для отдельного элемента списка layout/list_item.xml.
Мы хотим использовать фиксированную высоту для каждого элемента и используем атрибут android:layout_height у родительского элемента.
Попробуем неправильный вариант.
В этом варианте игнорируется родитель и соответственно его настройки.
Результат на экране.
Теперь вам должна быть ясна разница между разными вариантами и правильный код для применения.
Но бывают случаи, когда использование null оправданно.
Одним из таких примеров является использование разметки в AlertDialog. Допустим, у нас есть код.
AlertDialog.Builder не нуждается в родительском элементе для построения диалогового окна.
Рассмотрим случаи, когда нужен true. Допустим, у нас есть отдельная разметка кнопки.
Мы можем программно присоединить кнопку к LinearLayout в активности или фрагменте.
Мы указали, что хотим надуть кнопку из его собственной разметки и присоединить полученную кнопку к LinearLayout (второй параметр). Это решение эквивалентно вызову метода с двумя параметрами.
Как вариант, можно не присоединять при надувании, а добавить программно через addView().
Другой случай использования true встречается при создании собственного компонента, когда применяется .
У файла разметки нет корневого ViewGroup и мы указываем свой собственный компонент на основе LinearLayout в качестве корневого. Если бы мы использовали в своей разметке вместо merge любой компонент, например, FrameLayout, то тогда был бы другой случай.
Теперь вы знаете, в каких ситуациях нужно использовать разные методы inflate(). Это как с котом — надутого кота можно обратить в null, когда вы не нуждаетесь в двойниках.
Источник
Полный список
— делаем свой вариант списка
На прошлом уроке мы узнали, зачем нужен класс LayoutInflater и сделали небольшой пример, на котором подробно рассмотрели метод inflate и его параметры. Для закрепления темы сделаем еще один, чуть более сложный пример.
Мы сделаем свой аналог списка. Для начала придумаем данные. Пусть это снова будет штатное расписание с именами работников, должностями и зарплатой. Т.е. каждый пункт нашего списка будет содержать три текстовых не редактируемых поля — name, position, salary. А пункты мы разместим в виде вертикального списка.
Для реализации нам понадобятся два layout-файла:
main.xml — основной экран для Activity, контейнер для пунктов списка
item.xml — экран с FrameLayout и тремя текстовыми полями в нем. Это будет пункт списка.
Приложение будет параллельно перебирать три массива данных, создавать для каждой тройки View-элемент из layout-файла item.xml, заполнять его данными и добавлять в вертикальный LinearLayout в main.xml.
Project name: P0411_LayoutInflaterList
Build Target: Android 2.3.3
Application name: LayoutInflaterList
Package name: ru.startandroid.develop.p0411layoutinflaterlist
Create Activity: MainActivity
ScrollView обеспечит нам прокрутку списка, если все пункты не влезут в экран. А в нем LinearLayout, в который мы будем добавлять элементы.
FrameLayout, и три TextView в нем.
Кодим реализацию. MainActivity.java:
Не так уж много нужно кода, чтобы сделать несложный список. Мы запускаем цикл по кол-ву элементов в массивах данных. В каждой итерации создаем View-элемент item из layout-файла item.xml. В нашем случае item — это FrameLayout, который содержит три TextView. Мы их находим в созданном item и заполняем данными из массивов.
В методе inflate мы указали root — linLayout, чтобы получить от него LayoutParams и далее использовать для настройки ширины. Также для наглядности раскрашиваем пункты методом setBackgroundColor.
Обратите внимание — третий параметр inflate мы указали false. Т.е. мы не стали сразу добавлять создаваемый View-элемент к linLayout, а делаем это в конце кода методом addView. Этому есть объяснение. Если бы мы указали true — то метод добавил бы item к linLayout и вернул бы нам linLayout, общий для всех пунктов списка. Через linLayout заполнять TextView необходимым нам текстом было бы затруднительно. Поэтому мы получаем пункт item (FrameLayout), заполняем его TextView данными и только потом помещаем к остальным пунктам в linLayout методом addView.
Все сохраним и запустим:
Список удался и работает прокрутка.
Урок получился короткий, но полезный. На всякий случай хочу заметить, что это еще не классический Android-список называемый List. Но этот пример значительно облегчит понимание списка. Т.к. принцип схож. Для построения List мы также должны будем предоставлять массив данных и layout-файл для пунктов. Этим и займемся на следующем уроке.
На следующем уроке:
— используем ListView для построения списка
Присоединяйтесь к нам в Telegram:
— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.
— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование
— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня
— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме
Источник
Полный список
— разбираем как можно использовать LayoutInflater
После изучения SQLite самое время приступить к изучению списков – List. Но перед этим полезно будет узнать про LayoutInflater. Это знание пригодится нам в создании расширенных списков. Также перед этим уроком рекомендую снова прочесть урок про LayoutParams, освежить знания.
LayoutInflater – это класс, который умеет из содержимого layout-файла создать View-элемент. Метод который это делает называется inflate. Есть несколько реализаций этого метода с различными параметрами. Но все они используют друг друга и результат их выполнения один – View.
Как видим, на вход метод принимает три параметра:
resource — ID layout-файла, который будет использован для создания View. Например — R.layout.main
root – родительский ViewGroup-элемент для создаваемого View. LayoutParams от этого ViewGroup присваиваются создаваемому View.
attachToRoot – присоединять ли создаваемый View к root. Если true, то root становится родителем создаваемого View. Т.е. это равносильно команде root.addView(View). Если false – то создаваемый View просто получает LayoutParams от root, но его дочерним элементом не становится.
Посмотрим на практике.
Project name: P0401_LayoutInflater
Build Target: Android 2.3.3
Application name: LayoutInflater
Package name: ru.startandroid.develop.p0401layoutinflater
Create Activity: MainActivity
Открываем main.xml и рисуем такой экран:
На экране две ViewGroup — linLayout и relLayout. В них по TextView с соответствующим текстом.
Создадим еще один layout-файл text.xml:
Тут просто TextView без всяких ViewGroup. На нем мы и будем испытывать LayoutInflater.
Открываем MainActivity.java и пишем код:
Мы получаем LayoutInflater методом getLayoutInflater, используем его для получения View-элемента из layout-файла text.xml и считываем LayoutParams у свежесозданного view.
Обратите внимание на параметры, которые мы использовали для метода inflate. Мы указали ID layout-ресурса, передали null в качестве родительского элемента и, соответственно, привязка к родителю — false.
Все сохраним и запустим.
На экране ничего не изменилось. Т.к. мы конвертнули layout в view, но никуда его не поместили. Он просто висит в памяти.
Class of view: class android.widget.TextView
LayoutParams of view is null: true
Text of view: Layout with TextView
Мы видим класс созданного элемента — TextView. Все верно — этот элемент и был в файле text.xml. Далее видим null вместо LayoutParams. Это произошло потому, что родителя в методе inflate мы указали null. А именно от родителя view и должен был получить LayoutParams. Третья строка лога показывает текст TextView. Он тот же, что и в layout-файле text.xml – все верно.
Давайте немного изменим программу. Будем добавлять наш созданный элемент в linLayout из main.xml. Делается это просто – командой addView.
(добавляете только выделенные строки)
Мы нашли linLayout с экрана и добавили в него созданный с помощью LayoutInflater элемент.
Сохраняем, запускаем. Видим, что элемент добавился на экран в linLayout.
Теперь давайте попробуем указать родителя (root) при вызове метода inflate. Перепишем метод onCreate:
Мы находим элементы linLayout и relLayout с экрана и с помощью LayoutInflater создаем два View-элемента из layout-файла text.xml. Для первого указываем root – linLayout, для второго – relLayout. Но третий параметр attachToRoot оставляем false. Это значит, что созданный View-элемент получит LayoutParams от root-элемента, но не добавится к нему.
Все сохраним, запустим. На экране ничего не поменялось. Т.к. мы ни к чему новые элементы не добавляли и attachToRoot = false.
Class of view1: class android.widget.TextView
Class of layoutParams of view1: class android.widget.LinearLayout$LayoutParams
Text of view1: Layout with TextView
Class of view2: class android.widget.TextView
Class of layoutParams of view2: class android.widget.RelativeLayout$LayoutParams
Text of view2: Layout with TextView
По логам видно, что класс созданных элементов – TextView. А класс LayoutParams различается. В первом случае – это LinearLayout$LayoutParams, т.к. в качестве root элемента в методе inflate мы указали linLayout, а это объект класса LinearLayout. Во втором случае класс LayoutParams у созданного элемента — RelativeLayout$LayoutParams. Потому, что в качестве root указали relLayout (класс RelativeLayout).
Теперь у нас два варианта, как добавить созданные view1 и view2 на экран.
1) Снова использовать методы addView
2) Передавать true в качестве третьего параметра метода inflate. Тогда созданный View-элемент будет добавлен к root.
Выберем второй вариант и внесем изменения в код:
Передаем true в качестве третьего параметра в методе inflate и убираем строки выведения в лог текстов из TextView. Сейчас будет понятно почему.
Все сохраним и запустим приложение.
Как видим, созданные TextView появились в своих родителях, которых мы указали в методе inflate. В RelativeLayout элементы наложились друг на друга, т.к. мы не настроили расположение. В данный момент это не существенно.
Class of view1: class android.widget.LinearLayout
Class of layoutParams of view1: class android.widget.LinearLayout$LayoutParams
Class of view2: class android.widget.RelativeLayout
Class of layoutParams of view2: class android.widget.LinearLayout$LayoutParams
Обратите внимание на класс элементов. В первом случае — это LinearLayout, а во втором — RelativeLayout. Т.е. метод inflate вернул нам не созданные из layout-файла View-элементы, а те, что мы указывали как root. А созданные из layout-файла View элементы он добавил в root как дочерние аналогично команде addView. Это произошло потому, что мы указали true в третьем параметре (attachToRoot) метода inflate.
Соответственно LayoutParams для view1 и view2 будет LinearLayout$LayoutParams, т.к. linLayout и relLayout имеют родителя LinearLayout. И LayoutParams берут от него.
Для закрепления темы на следующем уроке сделаем пример поинтереснее.
На следующем уроке:
— делаем свой вариант списка
getLayoutInflater
Присоединяйтесь к нам в Telegram:
— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.
— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование
— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня
— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме
Источник
