Incorporate the Paging3 library

[gmale]

As a wallet developer, I'd like paging to be easy to use in the SDK so that I can display transactions efficiently in the wallet.

Background:

• Paging is currently broken! Therefore this bug is labeled as high-severity.
  • It relies on a class that I had been told would be moved into Android but there's a bug
  • We are passing in 1000 as the "page size" to mask the fact that paging is broken!!!
  • We should be passing something more reasonable like 10 (the number that can fit on one or two screens of the app)
• I was contemplating writing a component myself until I found out that Chris Banes created basically the same thing so I switched to his implementation of a paging datasource that was compatible with flows
• At the time the maintainers of the Paging library said they were working on a complete overhaul:

  we're working on a Coroutine-first overhaul of the Paging library, with the focus and benefits more on moving the loading APIs (DataSource) to coroutines. We're planning to natively support flow.

Criteria:

• leverages the new Paging 3 library
• paging is easy and intuitive
• paging is no longer broken

[ccjernigan]

I spent some time investigating this issue.

I'm not sure how we categorize severity. The current implementation appears to limit the number of transactions that can be queried to 1000 to avoid returning an unbound number of items. If there are more than 1000 transactions, some will not be displayed. So this is broken but it doesn't crash, is consistently reproducible, and is easy to explain as a "known issue." I suspect we can limp along with this issue for a bit longer. Are we aware of end user or SDK customer impacts that might shift this priority higher?

As it comes to prioritizing this issue, some items to consider:

• This is not a small task, it'll require a bit of effort to resolve.
• Implementing this will be a breaking API change for clients of the SDK.
• Implementing this will mean that we're dependent on the Android paging library, as our SDK would be emitting classes from the Paging library in our public API.

I'd like to consider whether we might be able to have a separate module in the SDK (sort of like -ktx modules in Android X) that adds the Paging extensions. This would avoid putting Paging classes directly in the public API of the core SDK. It shouldn't add much build complexity on our end, as this additional library would live in the same SDK repo and could get published at the same time as the core SDK. The paging libraries have already had API changes in the past (e.g. paging 2 to paging 3), so it would be nice to avoid future dependency hell with clients of our SDK if possible. As a separate library, we could even publish a version for paging 2, paging 3, and some future paging 4 simultaneously.

[ccjernigan]

If we implement paging, it will be done as paging primitives on the public API rather than using the Paging library. We don't want our public API to be tightly coupled with Google.