MVVM и выбор элементов в адаптере — Базовый адаптер

[anegin]

Если в каждый ViewHolder в bindItem() передается onClick: (() -> Unit)?, значит там где-то будет someView.setOnClickListener { onClick() }, а это значит каждый раз создается новый инстанс View.OnClickListener при каждом onBindViewHolder(). Почему бы не передавать onClick в конструктор ViewHolder?

Что в этом подходе не так — адаптер теперь слишком много знает: о существовании Lifecycle, о том, что есть LiveData-источники данных, и есть какое-то выделение элементов. К тому же у адаптера появляется два источника данных — отдельно список элементов и отдельно события о выделении элементов (по position). При неправильном использовании извне это может привести к рассинхрону, например, когда событие selection change пришло для позиции, на которой уже стоит другой элемент из-за того, что в адаптер за мгновение до этого была добавлена/удалена строчка при событии items change.
У адаптера интерфейс четко прописан — вернуть кол-во элементов, создать и забиндить ViewHolder. Уже готовые к отображению данные (items с selection) ему передают извне, например, через submitList().

[ircover]

Ура, кто-то всё-таки читает мою писанину! Благодарю за Вашу реакцию)

1. Передать onClick в конструктор холдера — идея хорошая. Видимо, чтобы получить позицию кликнутого элемента, надо будет из холдера доставать adapterPosition (или как он там называется). Я подумаю над этим.
2. Для работы адаптеру не нужно знать ни про какие Lifecycle или LiveData-источники. Подписка на элементы происходит в активити (откуда Lifecycle и взялся), а метод setCallback добавлен только для более простого создания колбэка на основе этого источника. Наверно, если бы этот метод я сделал расширением (как изначально и хотел), класс адаптера получился бы чище.
3. Я, конечно, допускал, что писал велосипед, но не похоже, чтобы подход с submitList как-то решал мою задачу — перенос логики с выбором элементов на сторону ViewModel (я писал об этом в предыдущих статьях). Но я обязательно ещё почитаю по этому поводу.
4. Проблема с рассинхроном списка элементов и выбранными позициями мной ещё подробно не анализировалась. Возможно, это часть общей проблемы потокобезопасности, решение которой я указал в перспективах. Честно говоря, я пока даже не представляю, как корректно должен обработаться описанный Вами случай. Если обновление списка произошло "за мгновение до этого", то пользователь ещё не успел увидеть новые данные. Правильно ли говорить, что было осознанно выбрано то, что ты ещё не увидел? Хотя как минимум проанализировать возможность крашей в таких ситуациях лишним не будет, конечно.