После DataSource.Invalidate () новый PagedList имеет только одну страницу

Question

У меня есть список с нумерацией страниц, который я реализовал с помощью библиотеки подкачки.Элементы в этом списке могут быть изменены (изменены / удалены).Согласно официальной документации , я сначала изменяю кэш списка в памяти, из которого мои DataSource получают страницы, а после этого вызывают datasource.invalidate(), чтобы создать новую пару PagedList/DataSource:

Если у вас есть более детальные сигналы обновления, такие как сетевой API, сигнализирующий об обновлении одного элемента в списке, рекомендуется загружать данные из сети в память.Затем представьте эти данные в PagedList через DataSource, который оборачивает снимок в памяти.Каждый раз, когда изменяется копия в памяти, делает недействительной предыдущий источник данных, и может быть создан новый источник данных с новым состоянием снимка.

Это работает и выглядит ХОРОШО, еслипользователь изменяет элементы на первой странице.

Однако, если пользователь находится на второй странице или дальше во время datasource.invalidate(), он будет брошен в конце первой страницы .

Отладка показывает, что это происходит потому, что новая PagedList имеет только первую страницу , когда она отправляется на PagedListAdapter.submitList.Адаптер сравнивает старый и новый списки и удаляет все элементы не с первой страницы.Это происходит всегда, но не видно для пользователя, если он находится на первой странице.

Так что, мне кажется, новая пара PagedList/DataSource не имеет представления о количестве страниц, которые извлекли предыдущую пару, а datasource.invalidate() нетне подходит для ситуации в документах.Поведение, которое я считаю приемлемым для случаев, тогда пользователь обновляет весь список (например, пролистывание до обновления), но не

обновление для одного элемента в списке

Имееткто-нибудь сталкивался с такой проблемой или как-то архивировал вещи которые я хочу?Возможно, мне не хватает какой-то хитрости, которая помогает мне получить новые PagedList уже со всеми страницами.

Для пояснения: версия библиотеки 2.1.0.Пользовательский PageKeyedDataSource на основе кэша в памяти и удаленного обслуживания (№ Room)

Answer 1

Я хочу поделиться своим исследованием на случай, если кому-то будет интересно:

1. Проблема («отсутствие возможностей») известна, по крайней мере, я нашел пару связанных обсуждений на официальном трекере one two
2. Если вы используете PositionalDataSource или ItemKeyedDataSource, вы должны копать в направлении requestedStartPosition/requestedInitialKey от начальных параметров как этот ответ говорит.У меня не было много времени, чтобы создать полное решение, но эти параметры действительно различаются для начальной загрузки после аннулирования

О моем случае: PageKeyedDataSource. Здесь вы можете прочитать, что в этом типе источника данных нет аналогичных requestedInitialKey параметров.Тем не менее, я нашел решение, которое мне подходит, очень простое, хотя и выглядит как подвох:

Когда вызывается loadInitial() после invalidate() кэш в памяти возвращает все уже загруженные страницытолько из первого. Сначала я волновался, что что-то сломается, если, например, requestedLoadSize равно 5, но в результате получается список из 50 элементов, но оказывается, что это просто подсказка, и его можно игнорировать.Только не забудьте передать nextPageKey, что соответствует последней кэшированной странице, а не первой.

Надеюсь, это поможет

Answer 2

С помощью наблюдаемого метода вы получите только элементы списка первой страницы .... если вы хотите редактировать другие элементы, вы можете получить этот список с помощью метода adapter.currentlist.

Пример:

 private fun list():MutableList<String>{
    val list = mutableListOf<String>()
        for (value in videosAdapter.currentList.orEmpty()) {
            val abc = value.snippet.resourceId.videoId
            list.add(abc)
        }
    return list
}