Библиотека подкачки с пользовательским источником данных не обновляет строку при обновлении комнаты - PullRequest
0 голосов
/ 16 мая 2018

Я внедряю новую библиотеку подкачки с RecyclerView с приложением, созданным поверх Компонентов архитектуры .

.данные для заполнения списка получены из базы данных Room .Фактически, он выбирается из сети, хранится в локальной базе данных и предоставляется в список.

Чтобы предоставить необходимые данные для построения списка, я реализовал свой собственный пользовательский PageKeyedDataSource .Все работает, как и ожидалось, за исключением одной маленькой детали.Как только список отображается, если какие-либо изменения происходят с данными элемента строки списка, он не обновляется автоматически.Так, если, например, в моем списке отображается список элементов, имеющих поле name , и внезапно это поле обновляется в локальной базе данных Room для определенного элемента строки, список не обновляет строкуПользовательский интерфейс автоматически.

Это происходит только при использовании пользовательского источника данных, в отличие от того, когда источник данных автоматически получается из DAO , возвращая фабрику источников данных напрямую.Однако мне нужно реализовать собственный источник данных.

Я знаю, что его можно обновить, вызвав метод invalidate () в DataSource, чтобы перестроить обновленный список.Однако, если приложение показывает 2 списка одновременно (например, по половине экрана), и этот элемент отображается в обоих списках, необходимо вызвать invalidate () для обоих списков по отдельности.

Я подумал о решении, в котором вместо использования экземпляра класса элемента для заполнения каждого ViewHolder он использует LiveData его обернутую версию, чтобы сделатькаждая строка отслеживает изменения в своем элементе и обновляет интерфейс строки, когда это необходимо.Тем не менее, я вижу некоторые недостатки этого подхода:

  1. A LifeCycleOwner (например, фрагмент, содержащий RecyclerView) должен быть передан в PagedListAdapter и затем перенаправьте его в ViewHolder для наблюдения за упакованным элементом LiveData.
  2. Новый наблюдатель будет зарегистрирован для новой строки каждого списка, поэтому я вообще не знаю, имеет ли он чрезмерные вычислительные и затраты памятиучитывая, что это будет сделано для каждого списка в приложении, в котором есть много списков.
  3. Поскольку LifeCycleOwner, наблюдающий за обернутым элементом LiveData, будет, например, фрагментом, содержащим RecyclerView, вместосам ViewHolder, наблюдатель будет уведомляться каждый раз, когда происходит изменение этого элемента, даже если строка, содержащая этот элемент, даже не видна в тот момент, потому что список прокручивается, что мне кажется пустой тратой ресурсов, которые могли быувеличивать вычислительные затраты без необходимости.

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

Спасибозаранее.

...