Composable Functions: Building UI with Kotlin Functions

WHY IT EXISTS Composable functions were created to replace Android's older XML-based, imperative UI system. The old way required developers to manually find and update View objects, a process that was complex and error-prone. Composables offer a declarative approach: you describe what the UI should look like for a given state, and the framework handles the updates automatically.

THE MENTAL MODEL Think of a composable function as a recipe for a piece of UI, not the finished dish. You write a function that says, "if the user is logged in, show a welcome message; otherwise, show a login button." The Compose framework is the chef that reads this recipe and renders the UI. When the user's login status changes, the chef just re-reads the recipe and updates the dish accordingly. This automatic update process is called recomposition.

HOW IT WORKS You annotate a standard Kotlin function with @Composable. This annotation tells the Compose compiler to add special tracking capabilities. Inside the function, you call other composables (like Text, Button, Column) to build a UI hierarchy. When the input data of a composable function changes, Compose schedules it for recomposition. This means the function is re-executed to produce an updated UI description. The framework is highly optimized to only update the specific parts of the screen that actually changed.

WHEN TO USE IT Use composable functions for all UI elements in a Jetpack Compose application. They are the fundamental unit for building layouts, displaying text, handling user input, and managing animations. You combine simple, focused composables to create larger, reusable components and entire application screens. This is the standard way to build UIs in modern Android development.

WHEN NOT TO USE IT Do not place business logic or heavy computations directly inside a composable function's body. Because they can be recomposed frequently (many times per second), any expensive or long-running operation will cause severe performance issues and UI jank. Side-effects like network requests, database transactions, or modifying global state must be handled outside the composable, typically in a ViewModel and triggered from a specific side-effect handler like LaunchedEffect.

ONE CANONICAL EXAMPLE A simple composable function takes data and transforms it into UI. For example: @Composable fun Greeting(name: String) { Text(text = "Hello, $name!") }. This function accepts a name string and describes a UI that displays a text greeting. You can then use this Greeting composable elsewhere in your app, like Greeting(name = "Android"), to render the UI.