Oddbean

@f6beb887 You can create a denormalized table with just the data needed for presentation per row. The query will be super fast, the CursorWindow takes care of reading data in batches, so the all main thread does is turning in memory bytes into list items at rendering time, and occasionally moving the cursor window.

@f6beb887 @87c34046 I struggle to understand "the query will be super fast" it's super fast respect to network, but it's still an IO operation on disk, which is slow respect to anything in the main thread. I know we did that in old days, but it was not a good idea. Also based on your known knowledge of these subjects, I think either you are testing the Internet, or you are thinking far outside the box 😅

@8d18c0bf @f6beb887 with a db cursor plugged straight into the UI IO only happens when the cursor window needs to move. As you render rows you're just turning bytes into objects. Preloading with pages, on the other hand, requires reading an entire page of items and creating all the associated objects, which implies a higher latency, and then you need to make sure you keep preloading pages faster than you scroll.

@87c34046 @f6beb887 [CursorWindow](https://developer.android.com/reference/android/database/CursorWindow) just buffers the rows in memory, so it's still slow whenever you move the window. This means it has to read the data from the storage. In this aspect the memory usage is similar to preloading, except in the old days we ran the IO operation in the main thread, which was causing laggy experience for users, but now we should have learned our lessons.

@87c34046 @8d18c0bf @f6beb887 CursorWindow creates a noticeable jank when re-filling while scrolling in big lists. The paging library on the other hand supports placeholders, so you can display temporary empty rows if the user manages to scroll faster than the data is loaded.