Могу ли я использовать библиотеку Paging3 для API без запроса ‘страница = номер’?

#android #kotlin #android-paging-3

#Android #kotlin #android-paging-3

Вопрос:

Мне было интересно, могу ли я использовать библиотеку paging3 для API, которые не поддерживают ‘страница = RANDOM_NUMBER’ в своих запросах? Например, у меня есть API, в который я могу добавить пользовательский запрос типа ‘число = 50’, и в результате он отобразит 50 элементов. Я смущен тем, что я не смог бы использовать эту библиотеку для своего API без запроса page = RANDOM_NUMBER. Кто-нибудь может дать мне ответ?

Ответ №1:

Paging3 поддерживает произвольные типы ключей (вы определяете как ключ, так и способ его использования). Чтобы загружать данные постепенно, вы должны иметь возможность указать «загружать после ___», иначе невозможно продолжить загрузку данных после начальной загрузки. Если это что-то, что отслеживается независимо, скажем, файл cookie или токен сеанса, тогда вы можете попробовать сохранить значение maxSize равным unbounded и просто использовать любое ненулевое значение для nextKey.

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

 class MyPagingSource : PagingSource<String, Item>(
  val api: NetworkApi,
) {
  override suspend fun load(params: LoadParams): LoadResult<String, Item> {
    try {
      val result = withContext(Dispatchers.IO) {
         api.loadPage(after_id = params.key)
      }

      return LoadResult.Page(
        data = result.items,
        nextKey = result.items.lastOrNull().id,
      )
    } catch (exception: IOException) {
      return LoadResult.Error(exception)
    }
  }
}
  

В принципе, любое значение, которое вы передаете, nextKey будет передано LoadParams.key , когда пользователь находится в нижней части загруженных данных, и в случае, когда больше нет элементов или вы получаете пустой ответ от сети (из-за того, что находитесь в конце списка), вы можете вернуть null for nextKey , чтобы сообщить подкачке, что больше нечего загружать в этом направлении.

Обратите внимание, что я не рассмотрел prepend / prevKey , но если в вашем случае он не поддерживается, вы можете просто пройти null .

Если вы не поддерживаете prepend, вы не сможете возобновить загрузку с середины списка, поэтому вам нужно вернуть null in getRefreshKey() , в котором указывается, какую клавишу подкачки использовать для возобновления загрузки с позиции прокрутки в случае изменения конфигурации и т.д.

Комментарии:

1. можете ли вы привести убедительный пример или какую-либо ссылку? Я понимаю концепцию, но ее сложно реализовать в коде

2. Ну, это зависит от вашего API, после запроса первых 50 элементов, как вы запрашиваете следующие 50?

3. api запрашивается с помощью after_id , который получает «id» из идентификатора последнего элемента. При использовании after_id запрос вернет какие-то данные «следующей страницы».

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

5. Я думаю, что для сохранения будет переменная, after_id изначально after_id она была бы нулевой, поэтому api возвращает данные страницы 1 и after_id сохранит идентификатор последнего элемента из результата api. После прокрутки вниз API вызывается с after_id , чтобы получить данные страницы 2. Такова ли общая идея?