Ну у нас кстати так сделано, в OnBindViewHolder создается типа презентера класс которому сообщается модель с данными по номеру position, и в этом презенторе уже реализуется логика чтения нажатия например, отображения и т.д.

то есть сколько айтемов рециклятся столько презентеров и создается

не лагает скролл?

Адаптер должен преобразовывать данные одного вида в данные другого вида согласно паттерну.
Дроидовский адаптер впринципе выполняет эту задачу. Он преобразовует из списка неких объектов в список viewholder-ов, которые в свою очередь отдает AdapterView, когда она его просит.

Но тут получается проблема. Вью-холдер - это по сути вьюшка. Он отображает данные и делегирует действия пользователя  классу, ответственному за управление(согласно шаблону, который вы используете).
И тут становится вопрос: а что собственно является таким классом для холдера? Адаптер?  И куда этот адаптер ложить? В презентер, или во вью? Он вроде как занимается рендерингом айтемов. Так что по-идее вью. Но он же вроде как анализирует список. Так что по идее презентер. И вот куда его?

Я тут вижу два логичных  варианта:
1. Инкапсулировать адаптер во вью. Это вроде проще. Но тогда этот... эм... модуль нагружается логикой по типу: обнови состояние такое-то на  айтеме в позиции N. И по факту выходит , что вью А(фрагмент) управляет вью Б(вью-холдер), что нагружает ее и делает на мой взгяд слишком умной для вью.
2. То, что я собсно предложил. Тогда вью презентер MyListView подписуется на "получен новый итем", "итем удален" и ... собственно все. А управлением каждым холдером , занимается отдельный презентер(ну или что у вас там). Тогда адаптер, как тулза для рендеринга становится вполне логичной частью вью без компромиссов.

Я видел третий вариант, когда адаптер принимают за отельный вью. По мне так это странный вариант, но имеет право на жизнь впринципе.

Важно понимать, что я не пытаюсь сказать: "вот так правильно".  Это скорее что-то вроде: "можно вот так сделать. Вроде норм получается"

я тестил. На бюджетном сяоми начинает лагать к 4 тысячам айтемов.
метстами помнится были подтормаживания в начале скролла. Но я уже не помню, было ли это связано с такой организацией и где там вообще собака порылась

а такой вопрос. Как правильно обрабатывать клики в recycler? Правильно ли будет пробросить в адаптер презентер, в качестве слушателя?

интерфейс же

это не очевидно?)

раз спрашиваешь - нет

ну имел ввиду интерфейс, конечно же

а презентер тогда зачем, если интерфейс для покликух?

имелось ввиду, что этот интерфейс реализует презентер

ну я в целом неправильно выразился, да

да норм, у них ж жц один

Ну это такой же вопрос, как "можно ли имплементить презентере(контроллере, вью модели) OnClickListener.
C точки зрения SOLID не стоит. Потому, как сегодня у вас действие юзера триггерится нажатием на кнопку. А завтра дизайнер передумал, и вам нужно отлавливать свайп некой вьюшки вправо. Принцип лисков говорит о том, что изминений в презентере в такой ситуации происходить не должно. Если вы дергаете метод "OnUserActionTriggered()" на презентере - принцип выдерживается. Если презентер имплементит onClickListener - нет.

Но впринципе, если вы так сделаете - беды не случится. Не думаю, что это будет серьезной проблемой, если вы понимаете, что , зачем и почему делаете.

я вообще для себя придумал, что в презентере для списка есть метод onEventTriggered(Any) и кайфую

        public override void OnBindViewHolder(RecyclerView.ViewHolder holder, int position)
        {
            var cellHolder = holder as TableCollectionViewCellVC;

            if (cellHolder != null)
            {
                var index = GetIndexPathByPosition(position);

                TableCellMC model = ModelController.GetCell(index, cellHolder.ModelController);

                if (cellHolder.ModelController == null)
                {
                    cellHolder.BindWithModel(model);
                }

                cellHolder.InSight = true;
            }
        }

это какой-то замарин

ну суть одна

и как сделать в идеале тогда?