Пользовательский интерфейс Android: понимание представлений

Класс View является базовым классом, который расширяют все компоненты. View рисует что-то на экране и отвечает за обработку событий, когда пользователь взаимодействует с ним. Даже общий класс ViewGroup расширяет View . ViewGroup является специальным View которое содержит другие представления и размещает эти представления в соответствии с некоторыми правилами. Мы увидим, что Android предоставляет некоторые специализированные представления, которые помогают нам обрабатывать текст, изображения, пользовательский ввод, кнопки и так далее.

Все эти взгляды имеют несколько общих общих аспектов:

• Все виды имеют набор свойств: эти свойства влияют на способ отображения. Существует набор свойств, общих для всех представлений, в то время как есть некоторые другие свойства, зависящие от типа представления.
• Фокус: система управляет фокусом на каждом представлении, и в зависимости от пользовательского ввода мы можем изменить и навести фокус на конкретное представление.
• Прослушиватели: все представления имеют прослушиватели, которые используются для обработки событий, когда пользователь взаимодействует с представлением. Мы можем зарегистрировать наше приложение для прослушивания определенных событий, которые происходят в представлении.
• Видимость: мы можем контролировать, является ли представление видимым или нет, и мы можем изменить видимость также во время выполнения.

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

• число
• строка
• ссылка на значение, написанное где-то еще

Первые два варианта тривиальны, третий является наиболее интересным, потому что мы можем создать файл (всегда в XML), который содержит список значений, и мы можем ссылаться на него в нашем значении свойства. Это лучший подход, которым нужно следовать, особенно когда мы используем темы и стили или хотим поддерживать многоязычные приложения.

Одним из наиболее важных свойств является идентификатор представления : это уникальный идентификатор для представления, и мы можем искать конкретное представление, используя этот идентификатор. Это «статическое» свойство, означающее, что мы не можем изменить его, как только мы его определили.

Когда мы хотим установить свойство представления, у нас есть два способа сделать это:

• используя XML, пока мы определяем наше представление
• программно

Например, предположим, что мы хотим определить TextView (он пишет текст). В XML мы имеем:

Как вы можете заметить, мы определили идентификатор с именем textView1 , некоторые другие свойства, которые имеют строковые значения, и другое свойство с именем android: текст, который ссылается на значение, записанное в другом месте.

Мы могли бы сделать то же самое, используя только строки кода:

Это один из самых простых компонентов. Мы используем его, когда хотим показать текст на экране. Мы видели это раньше:

где android:text содержит текст, который мы хотим показать. У него есть некоторые атрибуты, которые мы можем использовать, чтобы указать, как мы хотим показать текст:

• android:fontFamily — это семейство шрифтов.
• android:shadowColor — это цвет тени.
• android:shadowDx — это смещение оси х тени.
• android:shadowDy — это смещение оси y тени.
• android:textStyle — это стиль (полужирный, курсив, полужирный).
• android:textSize — это размер текста.

Ниже приведены некоторые примеры TextView :

Input controls — это компоненты, с которыми пользователь может взаимодействовать. Используя такой компонент, вы можете, например, дать пользователю возможность вставить некоторые значения. Инфраструктура пользовательского интерфейса Android предоставляет широкий спектр элементов управления вводом: text field , text field input field , toggle buttons , radio buttons , buttons , checkbox , средства buttons и так далее. Каждый из них имеет специализированный класс, и мы можем создавать сложные интерфейсы, используя эти компоненты.
Ниже приведен список общих компонентов с классом, который его обрабатывает:

Мы хотим сфокусировать наше внимание на компоненте Button который широко используется в пользовательском интерфейсе Android. Сначала мы должны определить наш пользовательский интерфейс, используя файл XML:

Обратите внимание, что в идентификаторе кнопки мы использовали @+id означает, что мы добавляем новый идентификатор, а атрибут android:text — это строка, которую мы хотим показать на кнопке. Вы можете использовать ссылку вместо того, чтобы писать текст напрямую. Если мы создадим простое приложение с использованием этого макета и запустим его, у нас будет:

К настоящему времени мы создали пользовательские интерфейсы Android, но мы не рассматривали, как обрабатывать события, которые пользователь генерирует при взаимодействии с нашим приложением.

Listeners являются важным аспектом при разработке пользовательского интерфейса в Android. Вообще говоря, когда пользователь взаимодействует с интерфейсом нашего приложения, система «создает» некоторые события. Каждое представление, которое создает наш интерфейс, способно генерировать события и предоставлять средства для их обработки.

С точки зрения API, если мы посмотрим на класс View , мы можем заметить, что есть несколько открытых методов; эти методы вызываются системой при возникновении некоторых событий. Они называются методами callback , и они являются способом, которым мы можем фиксировать события, которые происходят, когда пользователь взаимодействует с нашим приложением. Обычно эти методы обратного вызова начинаются с on + event_name .

Каждое View предоставляет набор методов обратного вызова. Некоторые являются общими для нескольких представлений, в то время как другие являются специфичными для представлений. В любом случае, чтобы использовать этот подход, если мы хотим поймать событие, мы должны расширить View и это явно не практично. По этой причине каждое View имеет набор интерфейсов, которые мы должны реализовать, чтобы получать уведомления о происходящих событиях. Эти интерфейсы предоставляют набор методов обратного вызова. Мы называем эти интерфейсы слушателями событий. Поэтому, например, если мы хотим получать уведомления, когда пользователь нажимает кнопку, у нас есть интерфейс для реализации, который называется View.onClickListener .

Давайте рассмотрим пример выше, когда мы использовали Button в нашем пользовательском интерфейсе. Если мы хотим добавить слушателя, первое, что нам нужно сделать, это получить ссылку на Button :

В нашей Activity есть метод findViewById который можно использовать для получения ссылки на представление, определенное в нашем пользовательском интерфейсе. Получив ссылку, мы можем обработать щелчок пользователя:

Как вы можете видеть, мы использовали компактную форму, и вы можете заметить метод обратного вызова onClick . Этот метод вызывается системой, когда пользователь нажимает на нашу кнопку, поэтому здесь мы должны обработать событие. Мы могли бы получить тот же результат другим способом: мы можем заставить нашу Activity реализовать интерфейс View.OnClickListener и снова реализовать View.OnClickListener . Запустив приложение мы имеем в итоге:

Ранее мы коротко представили концепцию Activity . Настало время лучше объяснить его функцию. Пользовательский интерфейс Android не может существовать, если нет контейнера, в котором он содержится. Этот контейнер называется Activity и это одна из самых важных концепций в Android. Каждое приложение, которое мы создадим, имеет по крайней мере одно действие, и обычно более сложные приложения имеют несколько действий, которые взаимодействуют друг с другом, обмениваясь данными и информацией с помощью Intents . Activity заботится о создании окна, где мы размещаем наш пользовательский интерфейс.

Теперь мы можем создать законченное приложение, которое использует компоненты пользовательского интерфейса, показанные выше, и смешать их. Предположим, мы хотим создать приложение, которое запрашивает имя пользователя и имеет кнопку для его подтверждения.

К настоящему времени мы говорили о компонентах пользовательского интерфейса, которые показывают только одно значение. Некоторые компоненты могут отображать несколько значений или набор данных. Этот тип управления называется List управления. Если мы хотим использовать эти элементы управления в Android, мы не можем использовать один компонент, как мы делали раньше, но мы должны использовать два компонента: один, который управляет отображением данных, и другой, который управляет основными данными. Последний называется Adapter . AdapterView управления списком расширяет AdapterView а самые «известные» элементы управления списком:

• Посмотреть список
• волчок
• Вид сетки
• Галерея

Компонент ListView отображает свой элемент в списке. Это очень часто используется в пользовательском интерфейсе Android.

Spinner — это еще один компонент, который отображает только один элемент, но позволяет пользователю выбирать из нескольких элементов.

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

Gallery показывает элемент в горизонтальной прокрутке. Этот компонент устарел начиная с уровня API 16. Мы сосредоточим наше внимание на первых двух компонентах, поскольку они очень полезны при создании пользовательских интерфейсов.

Другим важным аспектом является взаимодействие между пользователем и компонентами списка. Мы фокусируем наше внимание на ListView . Те же соображения могут быть применены к другим типам компонентов списка. Обычно, когда у нас есть ListView в интерфейсе приложения, мы хотим знать элемент, по которому щелкнул пользователь. Мы можем использовать, как и для других компонентов пользовательского интерфейса, прослушиватели событий. Если вы вспомните предыдущий пример о ListView , код для обработки события будет следующим:

Анализируя приведенный выше код, мы просто устанавливаем прослушиватель onItemCick элементов, и в этом случае мы должны переопределить метод с именем onItemCick . В этом методе мы получаем, в качестве параметра, AdapterView , представление, по AdapterView , положение внутри ListView и его идентификатор. Мы уже знаем, что View является TextView потому что мы использовали ArrayAdapter строк, чтобы мы могли безопасно преобразовать представление в текстовое представление. Как только мы узнаем, что TextView нажал, мы можем получить текст.

В некоторых случаях стандартных адаптеров недостаточно, и мы хотим иметь больший контроль над дочерним представлением или добавить другие компоненты в дочернее представление. Есть и другие причины, которые следует учитывать при принятии решения о внедрении настраиваемого адаптера: возможно, у вас есть некоторые требования к управлению данными, которые вы не можете удовлетворить с помощью настраиваемых адаптеров, или вы хотите реализовать политику кэширования.

Во всех этих случаях мы можем реализовать пользовательский адаптер: вы можете решить расширить абстрактный класс BaseAdapter или вы можете расширить какой-нибудь специализированный класс, например, ArrayAdapter . Выбор зависит от типа информации, которую вы должны обработать. Чтобы упростить задачу и сосредоточить наше внимание на пользовательском адаптере, мы предположим, что мы хотим создать ListView, в котором дочерние представления имеют две текстовые строки.

Сначала мы создаем наш адаптер и начинаем реализовывать некоторые методы:

Мы должны реализовать четыре метода. Прежде чем сделать это, мы определяем класс, который является нашей моделью данных. Для простоты мы можем предположить, что у нас есть класс Item с двумя открытыми атрибутами: name и descr . Теперь нам нужен дочерний макет, чтобы мы могли отображать данные:

В нашем адаптере нам нужен конструктор, чтобы мы могли передавать данные, которые мы хотим отобразить:

Теперь переопределить метод довольно просто, кроме getView :

Обратите внимание, что в getItemId мы возвращаем уникальное значение, которое представляет элемент. Немного getView метод getView . Это сердце нестандартного адаптера, и мы должны тщательно его реализовать. Этот метод вызывается каждый раз, когда ListView должен отображать дочерние данные. В этом методе мы можем создать представление вручную или накачать файл XML:

Анализируя код, мы можем заметить, что сначала мы проверяем, что представление, переданное в качестве параметра, не является нулевым. Это необходимо, потому что система Android может повторно использовать представление, чтобы не тратить ресурсы. Поэтому, если представление не является нулевым, мы можем избежать раздувания файла макета XML. Если это ноль, тогда мы должны надуть файл макета. Следующим шагом является поиск TextView внутри нашего макета, чтобы мы могли установить их значения. Запустив приложение, мы получим: