Compose Lists

Fixed UIs

First, let's think about a fixed UI. We're asking the user to enter shipping information, which may or may not all fit on the screen. If the device has a large screen or the user is using a "small" font setting, we might get all fields on the screen. But as the screen shrinks or the user chooses "large" fonts, it's likely that some parts of the UI won't fit.

There are a few things you might do about this:

  • Mark your UI as scrollable. For example, if you use a Column to hold your fields, you can mark the column as scrollable:

    Column(
    modifier = Modifier
        .padding(paddingValues)
        .verticalScroll(rememberScrollState())
) { ... }

    This is a good idea whenever using a Column (or other layout) that may need to be scrolled to see all of its content. Keep in mind that devices come in many different form factors, and users will sometimes choose extra-large font sizes to make reading more comfortable.

    If, on the other hand, you're declaring a UI that has fixed content that always appears on the screen, and scales with the screen size to force it all to fit, you would skip the scroll modifier. (This might apply when writing a full-screen game, for example.)

  • Break the UI into more screens, each with fewer fields. If you have a long, scrollable, UI with many fields, double-check that the fields are all related. If grouping fields makes sense, you might consider creating more than one screen. You could

    • Create a "main" screen for that part of the UI, with buttons or links that open the grouped detail. For example, a shipping screen might have buttons to open an address-editor screen and present shipping rate choices.

    • Create a series of screens with "next"/"previous" actions to move between them. For example, a "purchase" might be presented as a series of screens:

      • Shopping cart display
      • Shipping address
      • Shipping rate options
      • Credit card entry
      • Confirmation

Choosing the right layout can be tricky. If you have some User-Experience (UX) Designers in your company, talk with them about what might make a good user interface. They may help set up an A-B study to test out alternatives with a user (or if you don't have dedicated UX folks, consider such a study yourself, or bounce ideas off other developers to see what might feel the best.)

If it feels like the best interface for your application would be a long scrolling list of fields, use a scrollable Column and test its performance. If the list of fields is really long and is causing performance issues, you may want to consider treating the fields as items in a list, and follow the next section.