@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.
Oddbean new post about login | logout