Нативная разработка мобильных приложений

Как использовать свое представление
Выше мы узнали довольно много о пользовательских представлениях и ком
-
понентах, но наше описание по большей части было упорядочено и достаточ
-
но логично. Оно освещает основную механику, характерную для фреймворка, 
и может показаться не особенно ценным. Чтобы приложение могло творить 
свое волшебство, нам нужно перепрыгнуть через несколько ступенек – не рас
-
страивайтесь, если что-то останется для вас непонятным; мы сами иногда 
сталкиваемся с малопонятными проявлениями и ищем ответы на возникаю
-
щие в связи с этим вопросы.
Для начала определим основу для последующего обсуждения. У нас есть 
подкласс 
TextView
из предыдущего примера: 
BottomBorderTextView
. Он будет 
представлен в XML, как любой другой компонент 
TextView
, и для него будут 
определены свойства из пространства имен 
android
, такие как 
android:text
и 
android:textSize
. Но нам также нужно добавить новое свойство: 
borderColor
.
Этот новый атрибут не является частью пространства имен 
android
– он от
-
носится к пространству имен XML нашего приложения (
http://schemas.android.
com/apk/res/com.yourapp
). В предыдущей главе, посвященной представлениям, 
мы видели, что можно использовать «автоматическое» пространство имен 
http://schemas.android.com/apk/res/auto
и привязать его непосредственно к про
-
странству имен текущего приложения.
Сначала определим свой атрибут как компилируемое значение 
values
. Тра
-
диционно такие определения атрибутов помещаются в файл 
res/values/attrs.
xml
, но вообще его можно поместить в любой подкаталог внутри 
res/values
.
Определение должно находиться в узле 
resources
в виде узла 
declare­styleable
с атрибутом 
name
, содержащим имя пользовательского компонента. Каждое 
свойство (в данном примере мы определяем только одно свойство 
borderColor
) 
должно быть представлено узлом 
attr
с атрибутом 
name
, содержащим имя свой
-
ства, и атрибутом 
format
, представляющим приемлемые типы данных (
color
, 
boolean
, 
dimension
, 
integer
и др.).
Вот как выглядит такое определение:

---

Android 

67



Создав определение пользовательского свойства, на него можно сослаться 
в макете XML своего компонента:
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res­auto"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="Hello world!"
app:borderColor="#FFFF9900" />
Затем нужно получить значение этого атрибута во время создания пред
-
ставления. Для этого приходится использовать малопонятный код. Взгляните 
на следующий пример, который поможет вам понять то, что сложно объяснить 
на простом языке:
Java
public BottomBorderTextView(Context context, 
@Nullable AttributeSet attrs,
int defStyleAttr) {
super(context, attrs, defStyleAttr);
TypedArray a = context.getTheme().obtainStyledAttributes(
attrs,
R.styleable.BottomBorderTextView,
0, 0);
try {
int color = a.getBoolean(R.styleable.BottomBorderTextView_borderColor,
Color.BLACK);
setBorderColor(color);
} finally {
a.recycle();
}
}
Kotlin
constructor(context: Context, attrs: AttributeSet, defStyleAttr: Int) :
super(context, attrs, defStyleAttr) {
val a = context.theme.obtainStyledAttributes(attrs,
R.styleable.BottomBorderTextView, 0, 0)
try {
borderColor = a.getInt(R.styleable.BottomBorderTextView_borderColor, Color.BLACK)
} finally {
a.recycle()
}
}
}
Откуда взялось это: 
R.styleable.BottomBorderTextView
? А это: 
R.styleable.Bot­
tomBorderTextView_borderColor
? Ответ прост: магия. Система творит волшебство 

---

68

Пользовательские компоненты
за кулисами, но вы можете быть уверены, что, создав ресурс XML, как было 
показано выше, вы получите эти значения в глобальном экземпляре 
R
. Узел 
declare­styleable
генерирует имя из своего атрибута 
name
и затем добавляет 
в конец символ подчеркивания и значение атрибута 
name
вложенного узла 
attr
. 
Тип 
TypedArray
тоже немножко волшебный, и мы очень сомневаемся, что вам 
когда-либо доведется использовать 
context.getTheme().obtainStyledAttributes
в других ситуациях. Как обычно, мы рекомендуем обратиться к документации 
для разработчиков, а также заглянуть в исходный код, но в данном случае (как 
это характерно для операций компиляции на уровне платформы) мы призы
-
ваем вас просто довериться нам.
Возможно, вы захотите завернуть эту пользовательскую логику обработки атрибу
-
та в метод 
initialize
и вызывать его в каждом конструкторе своего представле
-
ния, или можно использовать удобный трюк, вызывая каждый конструктор уров
-
нем выше со значениями по умолчанию или 
null
.
iOS
Настроить свое представление в iOS и добавить его в сцену можно в раскадров
-
ке или непосредственно в файле XIB в XCode. К сожалению, подобный подход 
быстро становится неустойчивым из-за сложности повторного использования 
такого представления. Как правило, под «пользовательским представлением» 
в iOS подразумевается пользовательский класс, который наследует стандартный 
класс представления из iOS. Такие представления часто можно использовать 
повторно, и они, как правило, обладают более широкими функциональными 
возможностями, чем при соблюдении принципа единственной ответственно
-
сти и непосредственном добавлении этих возможностей в контроллер пред
-
ставления. Давайте поближе познакомимся с некоторыми приемами создания 
пользовательских представлений в iOS и с использованием UIKit.