О чем все-таки говорит developer.android.com про RecyclerView

[MetalFan]

спасибо за инфу!
очепятка в «Где и как?»
в списке два раза упомянут «onViewAttachedToWindow» вместо видимо «onViewDetachedFromWindow»

[ookami_kb]

Спасибо, исправил!

[NonameNoferstname]

Замечательная статья! Лучше, чем у меня получилось ))) Однако именно о порядке обращения RecyclerView к методам обратного вызова в документации на developer.android.com я ничего не нашёл (хотя не факт, что там этого нет, а если есть, то, пожалуйста, потыкайте, кто знает, носом). И именно это толкнуло на эксперименты с RecyclerView.
По вопросу размещения слушателей: в качестве довода «соображения симметрии» не кажутся мне убедительными, ведь располагая их «на экваторе» процессов, а именно, в методе onBindViewHolder() с применением флагов и их анализа, мы ничего не теряем, кроме умозрительной симметрии.

[ookami_kb]

Спасибо!

Кроме симметрии, есть 3 причины не использовать флаги:

1. Введение флагов – дополнительный код. Дополнительный код – усложнение решения.
2. Вы привязываете слушателя, т.е. навешиваете логику взаимодействия с элементом на основании того, что элемент был или не был отправлен в кэш (оптимизация производительности) – это разные абстракции, и их не стоить смешивать.
3. onRecycledView теоретически может вообще не быть вызван. Сходу мне не удалось воспроизвести такую ситуацию, но в исходом коде есть такая функция:

void addViewHolderToRecycledViewPool(@NonNull RecyclerView.ViewHolder holder, boolean dispatchRecycled)

Если ее вызвать с параметром dispatchRecycled = false, то элемент отправится в пул, но уведомления об этом не будет.

2 и 3 пункты, на мой взгляд, еще и отвечают на вопрос, почему в документации не расписан порядок вызова этих методов – onRecycledView не надо использовать для чего-то, кроме потенциальной очистки своего кэша.

[sayunot]

Кстати! Давно мучает один вопрос: почему мало кто использует RecyclerView.OnItemTouchListener как замену View.OnClickListener? Как по мне, так для простых элементов RecyclerView (три-четыре действия) самое то. Плюс главное преимущество — OnItemTouchListener устанавливается на RecyclerView целиком, а не на каждый его элемент в отдельности (т.е. в onAttachedToRecyclerView/onDetachedFromRecyclerView, а не в onViewAttachedToWindow/onViewDetachedFromWindow).

[ookami_kb]

С RecyclerView.OnItemTouchListener получается больше возни. Он не дает прямого доступа к самому элементу (или к его позиции), который был нажат, надо подключать GestureDetector. Он все-таки предназначен для обработки более сложных жестов. Для простых случаев быстрее и проще навесить OnClickListener на сам элемент. Плюс, в зависимости от типа элемента, реакция на нажатие может быть разная, и выносить эту логику наверх, дальше от самого элемента, может быть неудобно.

[SpKiwi]

В чем минус привязывания listener в onCreateViewHolder()? Вызов данного метода происходит ограниченное количество раз, а доступ к позиции там можно получить при помощи getAdapterPosition().

[ookami_kb]

По большому счету, зависит от того, надо ли вам убирать этот listener.

Если вы просто устанавливаете OnClickListener, в котором дергаете какой-нибудь метод из активити, то я не вижу ничего плохо в привязывании в onCreateViewHolder.

Если же вы подписываетесь на какое-то внешнее событие (например, реагируете на какое-то событие от активити), то от него надо будет где-то отписываться. Если подписка была произведена в onCreateViewHolder, то где от нее отписываться?