Знакомьтесь: библиотека TiRecycler

Всем привет! Меня зовут Александр Гузенко, и в Тинькофф я занимаюсь всякими техническими вещами вроде 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 :)