Не так давно для андроид-разработчиков Google представил новую библиотеку — Android Architecture Components. Она помогает реализовать в приложении архитектуру на основе паттернов MVx (MVP, MVVM etc.). Кроме того, уже давно выпущена другая библиотека от Google — Data Binding Library. Она позволяет прямо в разметке связывать отображение UI-контролов со значениями, содержащимися в объектах. Это важная особенность паттерна MVVM — связывать слой View со слоем ViewModel.
Обе библиотеки направлены на построение архитектуры Android-приложений в MVVM стиле.
Я расскажу, как можно использовать их вместе для создания проекта с архитектурой на основе MVVM.
Немного об MVVM
Паттерн MVVM предполагает разделение архитектуры приложения на 3 слоя:
- Model — слой данных. Содержит всю бизнес-логику приложения, доступ к файловой системе, базе данных, ресурсам системы и другим внешним сервисам;
- View — слой отображения. Все, что видит пользователь и с чем может взаимодействовать. Этот слой отображает то, что представлено в слое ViewModel. Также он отправляет команды (например, действия пользователя) на выполнение в слой ViewModel;
- ViewModel — слой представления. Связан со слоем View байндингами. Содержит данные, которые отображены на слое View. Связан со слоем Model и получает оттуда данные для отображения. Также обрабатывает команды, поступающие из слоя View, изменяя тем самым слой Model.
Основной интерес в статье будет прикован к байндингам. Это связи отображения конкретных параметров View (например, “text” у TextView) с конкретными полями представления ViewModel (например, поле “имя пользователя”). Задаются они в разметке View (в layout), а не в коде. ViewModel, в свою очередь, должна так представлять данные, чтобы их было легко связать байндингами с View.
Зачем нам это все надо?
Сам по себе паттерн MVVM, как и MVP, и MVC, позволяет разделить код на независимые слои. Основное отличие MVVM — в байндингах. То есть, в возможности прямо в разметке связать отображение того, что видно пользователю — слой View, с состоянием приложения — слоем Model. В общем, польза MVVM в том, чтобы не писать лишний код для связывания представления с отображением — за вас это делают байндинги.
Google двигается в сторону поддержки архитектуры на основе паттерна MVVM. Библиотеки Android Architecture Components (далее, AAC) и Data Binding — прямое тому подтверждение. В будущем, скорее всего, этот паттерн будет использоваться на большинстве проектах под Android.
На данный момент проблема в том, что ни AAC, ни Data Binding не предоставляет возможности реализовать MVVM паттерн в полной мере. AAC реализует слой ViewModel, но байндинги надо настраивать вручную в коде. Data Binding, в свою очередь, предоставляет возможность написать байндинги в разметке и привязать их к коду, но слой ViewModel надо реализовывать вручную, чтобы прокидывать обновление состояния приложения через байндинги к View.
В итоге, вроде бы, все уже готово, но разделено на две библиотеки, и чтобы это было действительно похоже на MVVM, нужно просто взять и объединить их.
В общем, что надо для этого сделать:
- реализовать слой View на байндингах;
- реализовать слой ViewModel на основе классов LiveData и ViewModel из AAC;
- связать эти два слоя минимальным количеством кода;
- оформить это так, чтобы это можно было переиспользовать в проектах.
Сделать это попробуем на примере простого экрана профиля пользователя.
Описание примера
На экране будет три элемента:
- кнопка войти/выйти. Текст зависит от того, авторизован пользователь или нет;
- поле ввода логина. Показывается, когда пользователь не авторизован;
- лэйбл с логином. Показывает логин авторизованного пользователя.
Логин будет храниться в SharedPreferences. Пользователь считается авторизованным, если в SharedPreferences записан какой-нибудь логин.
Для простоты не будут использоваться сторонние фреймворки, запросы к сети, а также отображение ошибок.
Слой View
Начну я со слоя View, чтобы было понятно, что будет видно пользователю на экране. Сразу же размечу нужные мне байндинги без привязки к конкретной ViewModel. Как это все будет работать — станет понятно позже.
Собственно, layout:
<layout xmlns:android="http://schemas.android.com/apk/res/android">
<data>
<import type="touchin.aacplusdbtest.R"/>
<import type="android.view.View"/>
<!-- Это ViewModel для экрана, к которой будет все байндиться -->
<variable name="profileViewModel" type="touchin.aacplusdbtest.ProfileViewModel"/>
</data>
<LinearLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
android:orientation="vertical">
<!-- Текст с логином авторизованного пользователя.
Байндится логин, как текст из поля userLogin.
Байндится visibility к полю isUserLoggedIn,
так как отображается элемент только если пользователь авторизован. -->
<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="@{profileViewModel.userLogin}"
android:visibility="@{profileViewModel.isUserLoggedIn ? View.VISIBLE : View.GONE}"/>
<!-- Поле ввода логина.
Байндится введенный логин, как текст из поля inputLogin,
этот байндинг двусторонний, то есть при изменении inputLogin
во ViewModel будет меняться отображение на View,
и наоборот - при вводе пользователем другого текста
он будет изменяться в поле inputLogin.
Байндится visibility к полю isUserLoggedIn,
так как отображается элемент только если пользователь не авторизован. -->
<touchin.aacplusdbtest.views.SafeEditText
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:addTextChangedListener="@{profileViewModel.inputLogin}"
android:text="@{profileViewModel.inputLogin}"
android:visibility="@{profileViewModel.isUserLoggedIn ? View.GONE : View.VISIBLE}"/>
<!-- Кнопка войти/выйти.
Байндится текст к полю isUserLoggedIn:
отображается текст "Выйти", если пользватель авторизован,
текст "Войти" - если не авторизован.
Также настраивается вызов команды по клику
в зависимости от значения в поле isUserLoggedIn:
вызывается команда logout или login. -->
<Button
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@{profileViewModel.isUserLoggedIn ? R.string.logout : R.string.login}"
android:onClick="@{(v)-> profileViewModel.loginOrLogout()}"/>
</LinearLayout>
</layout>Класс LiveData
Перед реализацией слоя Model надо разобраться с классом LiveData из AAC. Он нам понадобится для нотификации слоя ViewModel об изменениях слоя Model.
LiveData — это класс, объекты которого поставляют данные и их обновления подписчикам. Он представляет собой реализацию паттерна Observer. На LiveData можно подписаться, а сама LiveData реализует внутри то, как она будет вычислять и обновлять данные для подписчиков.
Особенность LiveData в том, что она может быть привязана к объекту жизненного цикла и активироваться, только когда такой объект в состоянии started. Это удобно для обновления слоя View: пока активити или фрагмент в состоянии started, это значит, что у них инициализирован весь UI и им нужны актуальные данные. LiveData реагирует на это и активизируется — рассчитывает актуальное значение и уведомляет подписчиков об обновлении данных.
Слой Model
От слоя Model нам нужна следующая функциональность: методы login(String login), logout() и возможность отслеживать текущий логин авторизованного пользователя на основе LiveData.
Добавим класс ProfileRepository, который будет отвечать за логику авторизации пользователя:
class ProfileRepository(context: Context) {
private val loginKey = "login"
private val preferences = context.getSharedPreferences("prefs", Context.MODE_PRIVATE)
// LiveData, на которую можно подписаться
// и получать обновления логина пользователя
private val innerLoggedInUser = LoggedInUserLiveData()
val loggedInUser: LiveData<String?>
get() = innerLoggedInUser
fun login(login: String) {
preferences.edit().putString(loginKey, login).apply()
notifyAboutUpdate(login)
}
fun logout() {
preferences.edit().putString(loginKey, null).apply()
notifyAboutUpdate(null)
}
private fun notifyAboutUpdate(login: String?) {
innerLoggedInUser.update(login)
}
private inner class LoggedInUserLiveData : LiveData<String?>() {
// так лучше не делать в конструкторе, а высчитывать текущее значение асинхронно
// при первом вызове метода onActive. Но для примера сойдет
init { value = preferences.getString(loginKey, null) }
// postValue запрашивает обновление на UI-потоке
// используем, так как мы не уверены, с какого потока будет обновлен логин
// для немедленного обновления на UI-потоке можно использовать метод setValue
fun update(login: String?) {
postValue(login)
}
}
}Этот объект разместим в Application, чтобы было проще получить к нему доступ, имея Context:
class AacPlusDbTestApp : Application() {
lateinit var profileRepository: ProfileRepository
private set
override fun onCreate() {
super.onCreate()
profileRepository = ProfileRepository(this)
}
}Класс ViewModel
Перед реализацией слоя ViewModel надо разобраться с основным классом из AAC, использующимся для этого.
ViewModel — это класс, представляющий объекты слоя ViewModel. Объект такого типа может быть создан из любой точки приложения. В этом классе всегда должен быть либо дефолтный конструктор (класс ViewModel), либо конструктор с параметром типа Application (класс AndroidViewModel).
Чтобы запросить ViewModel по типу, нужно вызвать:
mvm = ViewModelProviders.of(fragmentOrActivity).get(MyViewModel::class.java)Либо по ключу:
mvm1 = ViewModelProviders.of(fragmentOrActivity).get("keyVM1", MyViewModel::class.java)
mvm2 = ViewModelProviders.of(fragmentOrActivity).get("keyVM2", MyViewModel::class.java)ViewModel хранятся отдельно для каждой активити и для каждого фрагмента. При первом запросе они создаются и помещаются для хранения в активити или фрагменте. При повторном запросе — возвращается уже созданная ViewModel. Уникальность конкретной ViewModel — это ее тип или строковый ключ + где она хранится.
Создаются ViewModel и AndroidViewModel по умолчанию через рефлексию — вызывается соответствующий конструктор. Так что, при добавлении своих конструкторов, в методе ViewModelProviders.of(...) нужно явно указывать фабрику создания таких объектов.
Слой ViewModel
От ProfileViewModel нам надо следующее:
- метод loginOrLogout, который будет представлять команду логина или логаута пользователя, в зависимости от того, авторизован ли пользователь;
- изменяемое значение isUserLoggedIn, которое будет представлять состояние — авторизован ли пользователь;
- изменяемое значение loggedInUser, которое будет представлять логин текущего авторизованного пользователя;
- изменяемое значение inputLogin, которое будет представлять то, что пользователь ввел на экране в поле логина.
Создадим ProfileViewModel и свяжем ее с ProfileRepository:
// наследуем от AndroidViewModel, для доступа к ProfileRepository через Application
class ProfileViewModel(application: Application) : AndroidViewModel(application) {
private val profileRepository: ProfileRepository = (application as AacPlusDbTestApp).profileRepository
// класс Transformations — это класс-хэлпер для преобразования данных
// метод map, просто конвертирует данные из одного типа в другой - в данном случае из String? в boolean
val isUserLoggedInLiveData = Transformations.map(profileRepository.loggedInUser) { login -> login != null }
// LiveData чтобы отслеживать логин авторизованного пользователя
val loggedInUserLiveData = profileRepository.loggedInUser
// представляет логин, введенный пользователем с клавиатуры
// TextField - это ObservableField, реализующий интерфейс TextWatcher
// это нужно, чтобы можно было байндиться к text и addTextChangedListener,
// организовав таким образом двустронний байндинг.
// При вводе текста в EditText изменяется ViewModel, при изменении ViewModel — изменяется EditText.
val inputLogin = TextField()
fun loginOrLogout() {
// необходимо получить текущее состояние - авторизован пользователь или нет и решить, что делать
isUserLoggedInLiveData.observeForever(object : Observer<Boolean> {
override fun onChanged(loggedIn: Boolean?) {
if (loggedIn!!) {
profileRepository.logout()
} else if (inputLogin.get() != null) {
// вызываем логин только если пользователь что-то ввел в поле ввода
profileRepository.login(inputLogin.get())
} else {
// по идее, тут можно отобразить ошибку "Введите логин"
}
// при выполнении команды приходится отписываться вручную
isUserLoggedInLiveData.removeObserver(this)
}
})
}
}Теперь при вызове метода loginOrLogout в ProfileRepository будет обновляться LoginLiveData и эти обновления можно будет отображать на слое View, подписавшись на LiveData из ProfileViewModel.
Но LiveData и ViewModel пока что не адаптированы под байндинг, так что использовать этот код еще нельзя.
Адаптация ViewModel под Data Binding
С доступом к ViewModel из разметки проблем особых нет. Объявляем ее в разметке:
<layout xmlns:android="http://schemas.android.com/apk/res/android">
<data>
<variable name="profileViewModel" type="touchin.test.ProfileViewModel"/>
</data>
...
</layout>И устанавливаем в активити или фрагменте:
// наследуем от LifecycleActivity, так как это может понадобиться для LiveData.
// LiveData будет активироваться, когда эта активити будет в состоянии started.
class ProfileActivity : LifecycleActivity() {
lateinit private var binding: ActivityProfileBinding
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
// инициализируем байндинг
binding = DataBindingUtil.setContentView<ActivityProfileBinding>(this, R.layout.activity_profile)
// устанавливаем ViewModel для байндинга
binding.profileViewModel = ViewModelProviders.of(this).get(ProfileViewModel::class.java)
}
}Адаптация LiveData под Data Binding
Адаптировать LiveData я решил на основе класса ObservableField. Он позволяет привязать изменяющееся значение произвольного типа к конкретному свойству view.
В моем примере надо будет прибайндить visibility у view к тому, авторизован пользователь или нет. А также свойство text к логину пользователя.
У ObservableField есть два метода — addOnPropertyChangedCallback и removeOnPropertyChangedCallback. Эти методы вызываются, когда добавляется и удаляется байндинг из view.
По сути, эти методы — те моменты, когда нужно подписываться и отписываться от LiveData:
// наследуем от ObservableField
// имплементируем Observer (подписчик для LiveData) чтобы синхронизировать значения LiveData и ObservableField
class LiveDataField<T>(val source: LiveData<T?>) : ObservableField<T>(), Observer<T?> {
// отслеживаем количество подписчиков на этот ObservableField
private var observersCount: AtomicInteger = AtomicInteger(0)
override fun addOnPropertyChangedCallback(callback: Observable.OnPropertyChangedCallback) {
super.addOnPropertyChangedCallback(callback)
if (observersCount.incrementAndGet() == 1) {
// подписываемся на LiveData, когда к ObservableField прибайндивается первая view
source.observeForever(this)
}
}
override fun onChanged(value: T?) = set(value)
override fun removeOnPropertyChangedCallback(callback: Observable.OnPropertyChangedCallback) {
super.removeOnPropertyChangedCallback(callback)
if (observersCount.decrementAndGet() == 0) {
// отписываемся от LiveData, когда все view отбайндились от ObservableField
source.removeObserver(this)
}
}
}Для подписки на LiveData я использовал метод observeForever. Он не передает объект жизненного цикла и активирует LiveData независимо от того, в каком состоянии находятся активити или фрагмент, на котором находятся view.
В принципе, из объекта OnPropertyChangedCallback можно достать view, из view — context, context привести к LifecycleActivity и привязать LiveData к этой активити. Тогда можно будет использовать метод observe(lifecycleObject, observer). Тогда LiveData будет активироваться только когда активити, на которой находится view, в состоянии started.
Выглядеть этот хак будет примерно так:
class LifecycleLiveDataField<T>(val source: LiveData<T?>) : ObservableField<T>(), Observer<T?> {
...
override fun addOnPropertyChangedCallback(callback: Observable.OnPropertyChangedCallback) {
super.addOnPropertyChangedCallback(callback)
try {
// немножко рефлексии, по-другому никак
val callbackListenerField = callback.javaClass.getDeclaredField("mListener")
callbackListenerField.setAccessible(true)
val callbackListener = callbackListenerField.get(callback) as WeakReference<ViewDataBinding>
val activity = callbackListener.get()!!.root!!.context as LifecycleActivity
if (observersCount.incrementAndGet() == 1) {
source.observe(activity, this)
}
} catch (bindingThrowable: Throwable) {
Log.e("BINDING", bindingThrowable.message)
}
}
...
}Теперь изменим ProfileViewModel так, чтобы к ней можно было легко прибайндиться:
class ProfileViewModel(application: Application) : AndroidViewModel(application) {
...
// представляет логин авторизованного пользователя или null
val userLogin = LifecycleLiveDataField(loggedInUserLiveData)
// представляет авторизован ли пользователь
val isUserLoggedIn = LifecycleLiveDataField(isUserLoggedInLiveData)
...
}Важно! В процессе тестирования обнаружился один неприятный недостаток в библиотеке Data Binding — прибайнденные view не вызывают метод removeOnPropertyChangedCallback даже когда активити умирает. Это приводит к тому, что слой Model держит ссылки на объекты слоя View через слой ViewModel. В общем, утечка памяти из объектов LiveDataField.
Чтобы этого избежать, можно использовать еще один хак и вручную обнулить все байндинги на onDestroy активити:
class ProfileActivity : LifecycleActivity() {
...
override fun onDestroy() {
super.onDestroy()
// обнуляем поле profileViewModel
binding.profileViewModel = null
// необходимо вручную вызвать обновление байндингов,
// так как автоматическое обновление не работает на этапе onDestroy :(
binding.executePendingBindings()
}
}Кроме того, внимательные читатели могли заметить в разметке класс SafeEditText. В общем, он понадобился, из-за бага в Data Binding Library. Суть в том, что она добавляет в листенер вводимого текста через addTextChangedListener даже если этот листенер null.
Так как на этапе onDestroy я обнуляю модель, то сперва в EditText добавляется null-листенер, а потом обновляется текст, который стал тоже null. В итоге на onDestroy происходил NPE краш при попытке оповестить null-листенер о том, что текст стал null.
В общем, при использовании Data Binding будьте готовы к таким багам — их там довольно много.
Не идеально, но получилось
В общем, с некоторыми трудностями, хаками и некоторыми разочарованиями, но связать AAC и Data Binding получилось. Скорее всего, в скором времени (года 2?) Google добавит какие-нибудь фичи, чтобы связать их — тот же аналог моей LiveDataField. Пока что AAC в альфе, так что там многое еще может измениться.
Основные проблемы на текущий момент, на мой взгляд, связаны с библиотекой Data Binding — она не подстроена под работу с ViewModel и в ней есть неприятные баги. Это наглядно видно из хаков, которые пришлось использовать в статье.
Во-первых, при байндинге сложно получить активити или фрагмент, чтобы получить LifecycleObject, необходимый для LiveData. Эту проблему можно решить: либо достаем это через рефлексию, либо просто делаем observeForever, который будет держать подписку на LiveData, пока мы вручную не обнулим байндинги на onDestroy.
Во-вторых, Data Binding предполагает, что ObservableField и прочие Observable объекты живут тем же жизненным циклом, что и view. По факты эти объекты — это часть слоя ViewModel, у которой другой жизненный цикл. Например, в AAC этот слой переживает перевороты активити, а Data Binding, не обновляет байндинги после переворота активити — для нее все view умерли, а значит, и все Observable объекты тоже умерли и обновлять ничего нет смысла. Эту проблему можно решить обнулением байндингов вручную на onDestroy. Но это требует лишнего кода и необходимости следить, что все байндинги обнулены.
В-третьих, возникает проблема с объектами слоя View без явного жизненного цикла, например, ViewHolder адаптера для RecyclerView. У них нет четкого вызова onDestroy, так как они переиспользуются. В какой момент обнулять байндинги во ViewHolder — сложно сказать однозначно.
Не сказал бы, что на текущий момент связка этих библиотек выглядит хорошо, хотя использовать ее можно. Стоит ли использовать такой подход с учетом недостатков, описанных выше — решать вам.
Пример из статьи можно посмотреть на гитхабе Touch Instinct.
Автор: Touch Instinct
