Android UI Basics

In 2026, Android UI is built primarily with Jetpack Compose, which uses a declarative layout model — you describe what the UI should look like given the current state, and Compose handles rendering and updates. The older XML-based View system is still supported and widely found in existing codebases, so knowing both is expected.

Jetpack Compose layout composables

Compose does not use named "layout types" in the same way as the View system; instead, it uses composable functions:

• Column: arranges children vertically, top to bottom. Equivalent to a vertical LinearLayout.
• Row: arranges children horizontally. Equivalent to a horizontal LinearLayout.
• Box: stacks children on top of each other (last child on top). Equivalent to FrameLayout.
• LazyColumn / LazyRow: efficiently displays large scrollable lists, composing only visible items. The modern replacement for RecyclerView.
• LazyVerticalGrid / LazyHorizontalGrid: grid layouts for large datasets.
• ConstraintLayout (compose-constraint): available in Compose via androidx.constraintlayout.compose, for complex constraint-based layouts when Row/Column nesting becomes unwieldy.
• Scaffold: provides Material Design structure — top app bar, bottom navigation, FAB, snack bar host — coordinated in one composable.

XML / View-based layout types (legacy but still relevant)

• LinearLayout: arranges children in a single row or column. Simple but can create deep view hierarchies when nested.
• ConstraintLayout: the most powerful XML layout. Define relationships between views using constraints. Recommended for flat, complex layouts without deep nesting. Significantly better performance than nested LinearLayouts.
• FrameLayout: single child (or stacked children). Used as a fragment container and for overlapping views.
• RelativeLayout: position views relative to each other or the parent. Largely replaced by ConstraintLayout.
• CoordinatorLayout: from the Material Components library. Enables coordinated scrolling behaviors (collapsing toolbars, anchored FABs). Works with AppBarLayout and CollapsingToolbarLayout.
• RecyclerView: not a layout per se, but the standard scrollable list/grid widget in the View system.

Which to use when

New code should use Compose. For screens with many complex constraints and animations, ConstraintLayout in Compose is available. In legacy codebases, ConstraintLayout is the go-to XML layout for anything beyond a simple linear arrangement. Avoid deep nesting of LinearLayout — it degrades measure/layout performance.

Common gotcha: in Compose, LazyColumn items are not composed until they scroll into view, so you cannot reliably use remember to hold state across items — each item composable is a separate call site. Use LazyListState and persistent storage for scroll position and item state.

How you reference a UI element depends on whether you are using Jetpack Compose or the traditional View-based system.

Jetpack Compose (modern approach)

In Compose, there is no concept of "referencing a UI element by ID" because composables are functions, not objects you hold references to. Instead, state drives the UI — you pass data and callbacks down to composables and respond to changes through state holders:

@Composable
fun GreetingScreen(viewModel: GreetingViewModel = hiltViewModel()) {
    val name by viewModel.name.collectAsStateWithLifecycle()
    Text(text = "Hello, $name!")
    Button(onClick = { viewModel.updateName("World") }) {
        Text("Update")
    }
}

You interact with the UI by updating state, not by grabbing a reference to a Text composable and calling .setText().

View-based system (legacy / XML layouts)

In XML-based code you assign an android:id attribute to the view in the layout file:

Then in code you reference it using one of these approaches:

ViewBinding (recommended for View-based code)

// In an Activity
private lateinit var binding: ActivityMainBinding

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    binding = ActivityMainBinding.inflate(layoutInflater)
    setContentView(binding.root)
    binding.greetingText.text = "Hello, World!"
}

ViewBinding generates a type-safe binding class for each layout. It is null-safe (no risk of referencing a view from the wrong layout) and faster than findViewById. Enabled in build.gradle with viewBinding { enabled = true }.

findViewById (older pattern, still common)

val textView = findViewById(R.id.greetingText)
textView.text = "Hello, World!"

findViewById is error-prone: it returns null if the ID doesn't exist (or the wrong view on Android versions below API 26), and requires an unchecked cast. ViewBinding is preferred.

DataBinding (declarative binding)

DataBinding goes a step further by binding data directly in XML and observing LiveData/StateFlow. It is functional but adds build complexity; most new codebases use ViewBinding for Views or Compose for new screens instead.

Common gotcha: calling findViewById before setContentView() returns null. In fragments, do not call findViewById in onCreateView; use onViewCreated or ViewBinding, and always null out the binding reference in onDestroyView to prevent memory leaks.

fill_parent and match_parent are functionally identical — both instruct a view to expand to fill the available space of its parent.

fill_parent was the original name introduced in Android 1.0. It was renamed to match_parent in API level 8 (Android 2.2, released in 2010) because the new name more accurately describes what the attribute does: the view's size "matches" its parent's size rather than "filling" it. fill_parent was deprecated at the same time.

In practice, both values have always compiled to the same constant (-1 in the LayoutParams class), so they behave identically. However, you should always use match_parent in any code written or maintained today — fill_parent is a historical artifact you might encounter in very old codebases or tutorials.

android:layout_width="match_parent"


android:layout_width="fill_parent"

In Jetpack Compose, the equivalent is the fillMaxWidth(), fillMaxHeight(), or fillMaxSize() modifiers:

Text(
    text = "Hello",
    modifier = Modifier.fillMaxWidth()
)

There is no XML attribute in Compose — layout sizing is expressed through Modifier chaining.

Common interview follow-up: what is the difference between match_parent and wrap_content? match_parent sizes the view to its parent's size; wrap_content sizes the view to just fit its own content.

How you handle user interactions depends on whether you are using Jetpack Compose or the View-based system.

Jetpack Compose (modern approach)

In Compose, interaction handling is declarative. You pass lambda callbacks directly into composables:

@Composable
fun LoginScreen(viewModel: LoginViewModel = hiltViewModel()) {
    var username by remember { mutableStateOf("") }

    Column {
        TextField(
            value = username,
            onValueChange = { username = it },
            label = { Text("Username") }
        )
        Button(onClick = { viewModel.login(username) }) {
            Text("Log In")
        }
    }
}

There are no setOnClickListener calls — the event handler is declared as a parameter. Compose provides interaction-specific APIs as well:

• Modifier.clickable { } — tap events with ripple feedback.
• Modifier.pointerInput(Unit) { detectTapGestures { } } — low-level pointer handling.
• Modifier.draggable / Modifier.swipeable — drag and swipe gestures.

View-based system (legacy)

In XML + Kotlin code, you attach listeners to view objects:

Click listener

binding.submitButton.setOnClickListener {
    viewModel.submit()
}

Long click listener

binding.itemView.setOnLongClickListener {
    showContextMenu()
    true // consume the event
}

Text changes

binding.searchField.addTextChangedListener { text ->
    viewModel.search(text.toString())
}

Touch events

view.setOnTouchListener { v, event ->
    when (event.action) {
        MotionEvent.ACTION_DOWN -> { /* finger down */ true }
        MotionEvent.ACTION_UP -> { /* finger up */ true }
        else -> false
    }
}

Wiring UI events to the ViewModel

In both Compose and the View system, event handlers should delegate to the ViewModel rather than performing business logic directly in the UI layer. The ViewModel processes the event and updates state; the UI observes the state and recompose/re-renders:

// ViewModel
class LoginViewModel : ViewModel() {
    private val _uiState = MutableStateFlow(LoginUiState())
    val uiState: StateFlow = _uiState.asStateFlow()

    fun login(username: String) {
        viewModelScope.launch { /* call repository */ }
    }
}

Common gotcha: in Compose, lambdas passed to event handlers should be stable (not create new lambda instances on every recomposition) to avoid unnecessary recomposition. Use remember { } or pass ViewModel method references directly.

This question is typically asked about the XML View system. In Jetpack Compose, attributes are replaced by Modifier functions and composable parameters — there are no XML files. For existing codebases or hybrid apps using Views, the following XML attributes are fundamental.

Layout and sizing

• android:id — unique identifier for the view, referenced in code as R.id.myView.
• android:layout_width / android:layout_height — required on every view. Values: match_parent (fill parent), wrap_content (shrink to content), or a specific dp value.
• android:layout_margin / android:layout_marginStart / android:layout_marginEnd etc. — space outside the view's bounds.
• android:padding / android:paddingStart etc. — space inside the view's bounds, between the view edge and its content.

Appearance

• android:background — background color (@color/primary) or drawable (@drawable/rounded_button).
• android:elevation — shadow depth in dp, part of Material Design's z-axis.
• android:alpha — opacity from 0.0 (transparent) to 1.0 (opaque).
• android:visibility — visible, invisible (hidden but still occupying space), or gone (hidden and not occupying space).

Text (TextView, Button, EditText)

• android:text — the text content, ideally referencing a string resource (@string/label).
• android:textSize — font size in sp (scaled pixels, respects user font size preference).
• android:textColor — text color.
• android:hint — placeholder text shown when the field is empty (EditText).
• android:inputType — keyboard type for EditText: text, number, textPassword, textEmailAddress, etc.
• android:maxLines / android:ellipsize — control text truncation.

Layout behavior

• android:gravity — alignment of content within the view (e.g., center, end).
• android:layout_gravity — alignment of the view within its parent (FrameLayout, LinearLayout).
• android:layout_weight — in LinearLayout, distributes remaining space proportionally among children.
• android:orientation — horizontal or vertical for LinearLayout.

Interaction

• android:clickable — whether the view responds to clicks.
• android:focusable — whether the view can receive keyboard/d-pad focus.
• android:contentDescription — accessibility label for screen readers. Required for ImageView and icon-only buttons.

In Jetpack Compose, all of these map to Modifier extensions and composable parameters. For example:

Text(
    text = stringResource(R.string.label),
    fontSize = 16.sp,
    color = MaterialTheme.colorScheme.onSurface,
    modifier = Modifier
        .fillMaxWidth()
        .padding(16.dp)
        .background(MaterialTheme.colorScheme.surface)
)