Compose Lists

Overview

So far, we've displayed lists of data by iterating through all of the data and emitting Text nodes. Seems to work ok, but what happens when that list gets big?

When we emit to the composition tree, the Compose UI will render all of the nodes, even if some are offscreen. If there are relatively few offscreen nodes, it's not a big deal, but as the number of nodes increase, the added processing time can contribute to jank in the UI. We need a better approach to manage offscreen parts of our UI.

We'll look at this from the point of view of fixed and dynamic UIs.

• A fixed UI is one that presents all of its data all the time. Think about a data-entry form. Perhaps you're editing user shipping information. There are typically a fixed number of fields in the UI. Depending on the device configuration (in this case, the screen size and user-selected font scaling), we might not be able to fit all fields on the screen at once. We can make the screen scroll, but all data is always rendered.

• A dynamic UI is one that only displays part of the available, typically just what will fit on the screen (or a bit more for smooth animation). This is most apparent when presenting data from a database, such as songs in a playlist. The UI will repeat chunks of controls for each item, and can quickly grow past the screen bounds. The dynamic nature of the UI reduces the amount of rendering needed.