Всем привет! Меня зовут Александр Гузенко, и в Тинькофф я занимаюсь всякими техническими вещами вроде CI/CD, gradle и внедрением новых подходов. Хочу рассказать вам про библиотеку, которую мы создали в команде Тинькофф Бизнеса, когда столкнулись с многословными адаптер-делегатами.
Уникальность библиотеки и отличия от адаптер-делегатов
Способ написания экранов со списками при помощи адаптер-делегатов очень многословен и заставляет писать много бойлерплейт-кода. Все дело в самом устройстве: его архитектура не подталкивает к написанию меньшего количества кода и большему переиспользованию.
Многие компании предпочитают библиотеку AdapterDelegates: она упрощает работу со списками в Android. Автор Ханнес Дорфман для своего времени написал отличную библиотеку, которую до сих пор используют в некоторых проектах и у нас в компании. Но разработка не стоит на месте, в ИТ все устаревает еще до того, как попадает в прод, поэтому мы решили написать что-то своe.
Не нужно писать весь адаптер целиком, чтобы отобразить на экране новый элемент. За это отвечает ViewHolder, а адаптер просто передает ему данные и вызывает его методы. Эти две задачи достаточно высокоуровневые, чтобы от них абстрагироваться. Я думаю, некоторые, даже используя адаптер-делегаты, выносят ViewHolder в отдельный класс. Так можно переиспользовать их в разных адаптерах. Предлагаю рассмотреть класс адаптер-делегата и придумать, что там можно «вынести за скобки»:
/** * @param <T> the type of adapters data source i.e. List<Accessory> */ public interface AdapterDelegate<T> { /** * Called to determine whether this AdapterDelegate is the responsible for the given data * element. * * @param items The data source of the Adapter * @param position The position in the datasource * @return true, if this item is responsible, otherwise false */ public boolean isForViewType(@NonNull T items, int position); /** * Creates the {@link RecyclerView.ViewHolder} for the given data source item * * @param parent The ViewGroup parent of the given datasource * @return The new instantiated {@link RecyclerView.ViewHolder} */ @NonNull public RecyclerView.ViewHolder onCreateViewHolder(ViewGroup parent); /** * Called to bind the {@link RecyclerView.ViewHolder} to the item of the datas source set * * @param items The data source * @param position The position in the datasource * @param holder The {@link RecyclerView.ViewHolder} to bind */ public void onBindViewHolder(@NonNull T items, int position, @NonNull RecyclerView.ViewHolder holder); }
Шаг 1: выносим isForViewType в модель
В этом методе для определения ViewType мы передаем наш айтем и позицию.
А можно ли с ним что-то сделать, чтобы было удобнее? Да, можно, если наш дженерик будет не простым T, а T extends ViewTyped. ViewTyped — это наш интерфейс, в котором определим viewType для вьюхолдера. Это позволит вынести его за рамки каждого адаптер-делегата, но все еще иметь к нему доступ.
Предлагаю еще одно коренное изменение. Что вы обычно используете для определения ViewType? У нас в компании, да и во многих статьях по ресайлеру я видел повсеместные instance of/is. Но что насчет лейаута? Обычно одной конкретной модельке соответствует один конкретный лейаут.
Если нужно будет отобразить какую-нибудь модельку вида:
data class AccountDetailUi( val icon: Int, val detailTitle: String, val moneyAmount: MoneyAmount, val date: Date )
То ей может соответствовать такой лейаут:
Предлагаю добавить в модельку наследование от интерфейса ViewTyped и знание о лейауте. Модель будет выглядеть так:
data class AccountDetailUi( val icon: Int, val detailTitle: String, val moneyAmount: MoneyAmount, val date: Date, override val viewType: Int = R.layout.item_account_details ) : ViewTyped
Получается, на уровне Adapter, который не делегат, а обычный, можно брать данные о том, что инфлэйтить и чем наполнять. Значит, от этого метода в делегатах мы избавились и перенесли его на уровень UI-модели.
Шаг 2: превращаем onCreateViewHolder в фабрику
Иду дальше, встречаю onCreateViewHolder. Тут почти в 100% случаев все вызывают inflate и передают view в конструктор ViewHolder'а. Так давайте вспомним, чему нас учит SOLID, и вынесем это в отдельный класс. Назовем его HolderFactory:
abstract class HolderFactory: (ViewGroup, Int) -> BaseViewHolder<ViewTyped> { abstract fun createViewHolder(view: View, viewType: Int): BaseViewHolder<*>? final override fun invoke(viewGroup: ViewGroup, viewType: Int): BaseViewHolder<ViewTyped> { val view: View = viewGroup.inflate(viewType) return when (viewType) { // тут у нас сразу будет создаваться пачка базовых ViewHolder, например R.layout.item_progress -> BaseViewHolder<ProgressItem>(view) R.layout.item_error -> ErrorViewHolder(view) R.layout.item_empty_content -> EmptyContentViewHolder(view) //и так далее в зависимости от готовности вашего проекта к шаблонным лейаутам else -> checkNotNull(createViewHolder(view, viewType)) { "unknown viewType=" + viewGroup.resources.getResourceName(viewType) } } as BaseViewHolder<ViewTyped> } }
Хочу обратить внимание на строчку:
R.layout.item_progress -> BaseViewHolder<ProgressItem>(view)
Мы «не плодим сущности сверх необходимого»: для ProgressItem нам не нужно создавать отдельный ViewHolder, потому что его задача — просто отрисовать xml-вьюшку и ничего более.
Шаг 3: выносим onBindViewHolder в отдельный класс
В предыдущем примере у нас мелькал класс BaseViewHolder, его-то мы сейчас и разберем:
open class BaseViewHolder<T : ViewTyped>( override val containerView: View ) : RecyclerView.ViewHolder(containerView), LayoutContainer { open fun bind(item: T) = Unit open fun bind(item: T, payload: List<Any>) = Unit //при необходимости сюда можно добавить и другие колбэки из разряда //onViewRecycled и вот это все, но у нас пока не было надобности, //а как говорил Оккама, «не плоди сущности сверх необходимого» }
Простой и маленький класс, в котором только самое необходимое. Метод bind, в который передается дженерик, — наследник ViewTyped и его перегрузка. В нее можно передать payload, чтобы обновить одну или несколько частей ViewHolder, не обновляя его полностью.
Шаг 4: Адаптер. Собираем все воедино
Мы разделили методы интерфейса AdapterDelegate по своим обязанностям и теперь можем связать их в классе Adapter. У нас получилось два адаптера — это связано с тем, что где-то у нас есть DiffUtils, а где-то они не нужны. Поэтому рассмотрим сначала базовую реализацию, а конкретные реализации разберем дальше:
abstract class BaseAdapter<T : ViewTyped>(internal val holderFactory: HolderFactory) : RecyclerView.Adapter<BaseViewHolder<ViewTyped>>() { abstract var items: List<T> override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): BaseViewHolder<ViewTyped> = holderFactory(parent, viewType) override fun getItemCount(): Int = items.size override fun onBindViewHolder(holder: BaseViewHolder<ViewTyped>, position: Int) = holder.bind(items[position]) override fun onBindViewHolder(holder: BaseViewHolder<ViewTyped>, position: Int, payloads: MutableList<Any>) { if (payloads.isNotEmpty()) { holder.bind(items[position], payloads) } else { super.onBindViewHolder(holder, position, payloads) } } override fun getItemViewType(position: Int): Int { return items[position].viewType } }
Дальше делегируем работу нашим помощникам.
Для определения viewType — нашему интерфейсу ViewTyped, для создания ViewHolder'а — holderFactory, для наполнения ViewHolder данными — нашему BaseViewHolder
Ловкость рук, и никакого дублирования.
Как работаем с адаптером DiffUtils
Для работы с DiffUtils добавим в наш интерфейс еще одну проперти:
interface ViewTyped { val viewType: Int val uid: String get() = error("provide uid for viewType $this") }
Хочу подсветить, что теоретически каждый элемент может начать использоваться с DiffUtils, но пока эта функциональность не будет нужна, мы не обязываем переопределять uid.
А если мы решим перевести экран на использование DiffUtils и где-то не укажем uid для наших элементов, свалимся с ошибкой. Еще на этапе разработки мы увидим проблемный класс и сможем быстро его поправить. Чтобы наконец все заработало, нам нужны еще две детали. Первая — ViewTypedDiffCallback:
open class ViewTypedDiffCallback<T : ViewTyped>() : DiffUtil.ItemCallback<T>() { override fun areItemsTheSame(oldItem: T, newItem: T): Boolean { return oldItem.uid == newItem.uid } override fun areContentsTheSame(oldItem: T, newItem: T): Boolean { return oldItem.equals(newItem) } }
Вторая — AsyncAdapter:
class AsyncAdapter<T : ViewTyped>( holderFactory: HolderFactory, diffItemCallback: DiffUtil.ItemCallback<T> ) : BaseAdapter<T>(holderFactory) { private val asyncListDiffer = AsyncListDiffer(this, diffItemCallback) override var items: List<T> get() = asyncListDiffer.currentList set(newItems) = asyncListDiffer.submitList(newItems) }
Когда используем AsyncListDiffer, который предоставляет библиотека ресайклера, мы создаем асинхронный адаптер. Такой адаптер может использовать DiffUtils.
Как это выглядит в TiRecycler
Сначала покажу пример того, как мы в итоге все это используем, а потом объясню по порядку:
interface TiRecycler<T : ViewTyped> { fun setItems(items: List<T>) val adapter: BaseAdapter<T> companion object { @JvmOverloads operator fun <T : ViewTyped> invoke( recyclerView: RecyclerView, holderFactory: HolderFactory, diffCallback: DiffUtil.ItemCallback<T>? = null, init: TiRecyclerBuilder<T>.() -> Unit = {} ): TiRecycler<T> { return TiRecyclerBuilderImpl( holderFactory = holderFactory, diffCallback = diffCallback ) .apply(init) .build(recyclerView) } }
val tiRecycler = TiRecycler(recyclerView, CoreRecyclerHolderFactory()) { itemDismissCallbacks += ItemDismissTouchHelperCallback(this@CoreRecyclerDemoActivity, R.layout.item_text) } recycler.setItems(getStubItems())
Мы используем возможности Kotlin красиво написать объявление вызова, как конструктора интерфейса — просто красивый сахар. Снова делегируем всю работу в отдельный класс — TiRecyclerBuilderImpl, который конструирует нужный объект — наследник интерфейса TiRecycler.
В зависимости от значения — null или diffCallback — мы подставляем нужную реализацию адаптера и удобно добавляем dismiss-колбэки, тач-хелперы, декораторы и дефолтный LinearLayoutManager, если забыли объявить его в XML.
Как обрабатываем клики: Rx и MVI
Этот подход лучше всего работает для архитектур UDF like, потому что нужна реактивная связка для кликов. Но можно попробовать подружить его и с MVP-подходом. У нас есть кастомный Observable, который имплементирует работы View.OnClickListener:
data class ItemClick(val viewType: Int, val position: Int, val view: View) class TiRecyclerItemClicksObservable : Observable<ItemClick>(), TiRecyclerHolderClickListener { private val source: PublishRelay<ItemClick> = PublishRelay.create() override fun accept(viewHolder: BaseViewHolder<*>, onClick: () -> Unit) { viewHolder.itemView.run { setOnClickListener(Listener(source, viewHolder, this, onClick)) } } override fun accept(view: View, viewHolder: BaseViewHolder<*>, onClick: () -> Unit) { view.setOnClickListener(Listener(source, viewHolder, view, onClick)) } override fun subscribeActual(observer: Observer<in ItemClick>) { source.subscribe(observer) } class Listener( private val source: Consumer<ItemClick>, private val viewHolder: BaseViewHolder<*>, private val clickedView: View, private val onClick: () -> Unit ) : View.OnClickListener { override fun onClick(v: View) { if (viewHolder.bindingAdapterPosition != RecyclerView.NO_POSITION) { onClick() source.accept(ItemClick(viewHolder.itemViewType, viewHolder.bindingAdapterPosition, clickedView)) } } } }
В HolderFactory создаем экземпляр класса и пишем интересующие нас фильтры:
protected val clicks = TiRecyclerItemClicksObservable() fun clickPosition(vararg viewType: Int): Observable<Int> { return clicks.filter { it.viewType in viewType }.map(ItemClick::position) } fun clickPosition(viewType: Int, viewId: Int): Observable<Int> { return clicks.filter { it.viewType == viewType && it.view.id == viewId }.map(ItemClick::position) }
Аналогично сделано для лонг-кликов и свайпов. Следующим шагом нужно добавить дополнительный конструктор в BaseViewHolder, чтобы можно было ловить клики:
constructor(containerView: View, clicks: TiRecyclerHolderClickListener) : this(containerView) { clicks.accept(this) // так мы ловим клик на весь itemView //а клик на конкретную вью можно поймать по ее id, например так: //clicks.accept(binding.btnRepeat, this@ErrorViewHolder) }
Финальный этап — предоставить метод со стороны интерфейса Recycler для подписки в Activity/Fragment/View:
override fun <R : ViewTyped> clickedItem(vararg viewType: Int): Observable<R> { return adapter.holderFactory.clickPosition(*viewType).map { adapter.items[it] as R } } override fun <R : ViewTyped> clickedViewId(viewType: Int, viewId: Int): Observable<R> { return adapter.holderFactory.clickPosition(viewType, viewId).map { adapter.items[it] as R } }
На объекте recycler вызываем эти методы и передаем туда параметры:
tiRecycler.clickedItem(R.layout.onboarding_cell_item) //или tiRecycler.clickedItem(R.layout.onboarding_cell_item, R.id.someItem)
Но чтобы не плодить тонну подписок на каждый клик, у нас есть класс *UiEvents, который принимает Observable<ViewTyped>. Этот класс складывает клики в mergeArray и передает на единый вход store/presenter — это MVI-я прослойка с единым input-стримом, который дальше фильтруется нужным обработчиком.
Почему сделали так
Я знаю, что есть FastAdapter, в котором реализована примерно та же мысль, и сам AdapterDelegate выглядит лучше с котлин DSL. Нашему подходу уже около четырех лет, а я только нашел время, чтобы рассказать о нем. Возможно, «сейчас придет компоуз и всех вас уничтожит», но пока списки там работают не идеально, ждем. А пока ждем — улучшаем ситуацию с помощью нашего подхода TiRecycler :)
