Замечательная статья! Лучше, чем у меня получилось ))) Однако именно о порядке обращения RecyclerView к методам обратного вызова в документации на developer.android.com я ничего не нашёл (хотя не факт, что там этого нет, а если есть, то, пожалуйста, потыкайте, кто знает, носом). И именно это толкнуло на эксперименты с RecyclerView.
По вопросу размещения слушателей: в качестве довода «соображения симметрии» не кажутся мне убедительными, ведь располагая их «на экваторе» процессов, а именно, в методе onBindViewHolder() с применением флагов и их анализа, мы ничего не теряем, кроме умозрительной симметрии.
Во-первых, мне не ясно, почему вы считаете, что метод onViewRecycled() не имеет отношения к жизненному циклу вью? Ведь согласно этому документу это не так. Во-вторых, видимо, я не очень внятно в заметке обратил внимание на то, что я НЕ предлагаю менять реализацию жизненного цикла вью. Я предлагаю учитывать порядок обращения ОС к методам обратного вызова, одним из которых является onViewRecycled(). В-третьих, разница в том в каком кэше сохраняется вью как раз-таки и есть, потому, что в одном случае производится вызов метода onCreateViewHolder() и, следом, onBindViewHolder(), а в другом — нет.
Безусловно, есть случаи, когда эта разница не актуальна. Но есть случаи, когда она важна. Например, когда в слушателе необходимо учитывать позицию элемента в списке, доступ к которой есть в методе onBindViewHolder() и отсутствует в onViewAttachedToWindow()
Во-первых, я совершенно не претендую на знание истины в последней инстанции. Во-вторых, по-существу вопроса: метка утилизатора в коллекции данных для адаптера позволяет избежать ненужного повтора выполнения кода, хоть в методе onBindViewHolder, хоть в методах onViewAttachedToWindow и onViewDetachedFromWindow. Это имеет смысл тогда, когда код слушателей «весит» больше, чем метка с кодом её проверки, или когда в коде необходима позиция элемента списка. Возможно, есть ещё какие-нибудь варианты.
По вопросу размещения слушателей: в качестве довода «соображения симметрии» не кажутся мне убедительными, ведь располагая их «на экваторе» процессов, а именно, в методе
onBindViewHolder()с применением флагов и их анализа, мы ничего не теряем, кроме умозрительной симметрии.onViewRecycled()не имеет отношения к жизненному циклу вью? Ведь согласно этому документу это не так. Во-вторых, видимо, я не очень внятно в заметке обратил внимание на то, что я НЕ предлагаю менять реализацию жизненного цикла вью. Я предлагаю учитывать порядок обращения ОС к методам обратного вызова, одним из которых являетсяonViewRecycled(). В-третьих, разница в том в каком кэше сохраняется вью как раз-таки и есть, потому, что в одном случае производится вызов методаonCreateViewHolder()и, следом,onBindViewHolder(), а в другом — нет.Безусловно, есть случаи, когда эта разница не актуальна. Но есть случаи, когда она важна. Например, когда в слушателе необходимо учитывать позицию элемента в списке, доступ к которой есть в методе
onBindViewHolder()и отсутствует вonViewAttachedToWindow()onBindViewHolder, хоть в методахonViewAttachedToWindowиonViewDetachedFromWindow. Это имеет смысл тогда, когда код слушателей «весит» больше, чем метка с кодом её проверки, или когда в коде необходима позиция элемента списка. Возможно, есть ещё какие-нибудь варианты.