Building conditional layouts in Jetpack Compose

Building dynamic UIs often means adapting to varying screen sizes and content. Learn how to intelligently show or hide Composables based on available space, without hard-coded values.

Jetpack Compose has revolutionized Android UI development, offering a declarative and intuitive approach. However, one common challenge developers face is creating layouts that gracefully adapt when there isn’t enough space to display all elements. You might have a scenario where you want to show a particular UI element only if it fits, otherwise, it should remain hidden to prevent clipping or overflow.

🚗 The High Cost of Screen Real Estate: Lessons from Android Auto

During my time working on Android Auto at Google, one of the most critical aspects of UI development was the extreme scarcity of screen real estate. Car displays come in a bewildering variety of sizes, aspect ratios, and orientations, and often present significantly less usable space than a typical phone or tablet.

Every pixel counted.

Pushing too many elements onto the screen not only led to inevitable clipping and poor user experience but, more importantly, introduced UI clutter. This clutter was a significant concern for driver distraction, directly impacting safety and the overall polish of the interface. We constantly grappled with the challenge of displaying essential information and controls while maintaining a clean, focused, and adaptable layout.

This experience hammered home the vital need for highly dynamic and context-aware layouts — precisely the problem we’re solving today with Jetpack Compose.

🚧 The Challenge: Space Management

Imagine you have a Column of three Text elements. Your requirement is simple: the topmost Text should only be visible if there’s enough vertical space on the screen. If not, only the bottom two should be displayed. This directly mirrors the kind of decisions we had to make for every single UI component in Android Auto.

📏 Here’s a visual example of the problem we’re trying to solve:

Visualizing the problem: Will the topmost Composable fit?

How This Was “Easier” in the View System

In the traditional Android View system, achieving this kind of conditional visibility based on available space often felt more straightforward, even if it involved more imperative code.

You would typically:

1. Inflate the layout: All views would be inflated regardless of space.
2. Measure in onMeasure: In a custom ViewGroup‘s onMeasure method, you could iteratively measure child views. After measuring a child, you’d check if getMeasuredHeight() of that child, plus the y offset so far, exceeded the heightMeasureSpec (available height).
3. Conditional Visibility: If a child didn’t fit, you could then set its visibility to View.GONE and re-layout.

The key difference was the direct access to View properties like getMeasuredHeight() and the ability to imperatively set visibility during or after the measure/layout pass. You’d typically just measure all children first, then iterate again to decide which ones to draw or set visible based on the space calculations. This often felt like a more linear process.

In Compose, the world is declarative. We don’t set View.GONE. Instead, we decide whether to compose a Composable at all. This paradigm shift requires understanding Compose’s two-pass layout system and leveraging tools like intrinsic measurements to make informed decisions before composition.

The Problem with Hardcoded Thresholds (Even in Compose)

Even in Compose, an initial thought might lead to BoxWithConstraints and a hardcoded threshold:

𝌣 The Solution: Intrinsic Measurements with Layout

Jetpack Compose provides a powerful mechanism called intrinsic measurements. This allows you to ask a composable, “What’s the minimum or maximum width/height you would naturally take given certain constraints?” This query doesn’t perform a full layout pass, making it very efficient.

Combined with the Layout composable, which gives us full control over measuring and placing its children, we can create a highly adaptive solution.

Let’s build a generic Layout composable that can conditionally place any number of children based on available space, from top to bottom.

Understanding the Key Concepts

1. Layout(content, modifier, measurePolicy): This composable is your direct gateway to Compose’s layout system. You provide a content lambda (your children) and a measurePolicy lambda where all the magic happens.
2. measurables: Inside measurePolicy, measurables is a list of all the children passed to your Layout composable. Each Measurable represents a child that you can query and measure.
3. constraints: This object is passed down from the parent of your Layout composable. It defines the minWidth, maxWidth, minHeight, and maxHeight that your Layout composable (and by extension, its children) must adhere to. Crucially, constraints.maxHeight tells us the total vertical space we have available.
4. measurable.minIntrinsicHeight(width): This is the hero of our solution. Instead of giving us the measured height (which changes based on constraints), it tells us the minimum height this child would ideally take if given width and infinite height. It’s a lightweight query that avoids a full layout pass. This is invaluable when working with unknown content sizes.
5. measurable.measure(constraints): Once we know a child fits based on its intrinsic height, we call measure() to actually calculate its final size based on the provided constraints. This returns a Placeable object.
6. placeable.place(x, y): After all measurements are done, the layout lambda is called. Here, you iterate through your Placeable objects and tell Compose exactly where to draw them on the screen using their x and y coordinates.

🔨 Putting it to Use

Now, let’s see how incredibly simple it is to use our GenericConditionalLayout:

And voila! now our Composables only get rendered if there’s enough space for them to be rendered.

This article was previously published on proandroiddev.com.