Compose vs the View system

Jetpack Compose Junior Kotlin 2.0+ API 23+ Reviewed By Best Latest Apps

Pick the fix

A teammate calls api.track("screen_view") directly in a composable's body. What's the problem and the fix?

Options
Hint 1 of 1

How many times can a composable body run?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A The body can run many times; move it into LaunchedEffect(Unit)

Correct. Effects run once per entry into composition, not on every recomposition.

Why not the others?
  • B It's fine; composables run once. Composables re-run whenever state they read changes.
  • C Move it into remember { }. remember caches a value; using it for side effects is a hack and not cancellable.
  • D Wrap it in Modifier.clickable. That only runs on a tap.

30-second answer

With Views you build a tree of objects once and then mutate them (textView.text = ...). With Compose you write functions that describe the UI for the current state, and Compose re-runs the parts whose state changed. The UI can't drift out of sync with state, because there are no view objects to forget to update.

Practise saying it · 40 s. No recording, just a timer

Explain how Compose differs from Views.

Say your answer out loud, then check which of these points you covered:

  • Declarative: describe UI for state
  • Compose re-runs what read changed state
  • Composables must be side-effect free
  • Interop both ways

Deep dive

Composables are functions, not objects. They can run often and in any order, so they must be fast and free of side effects.

State is read through State<T> objects; Compose tracks which composables read which state and re-runs only those.

Layout is single-pass by design: a child can be measured only once per layout, which avoids the double-measure costs of nested weights in LinearLayout.

Views and Compose interoperate both ways: ComposeView inside XML and AndroidView inside a composable.

Common mistakes

  • Doing work such as network calls directly in a composable body.
  • Thinking Compose redraws the whole screen on every change.
  • Assuming you must rewrite the whole app at once.

Senior take & follow-ups

Avoid 'Compose is just faster'. Talk about the declarative model, state-driven updates and the interop path.

Follow-up questions

Think of your answer first, then open the hint.

  1. How would you migrate a large View app?

    Show hint

    Screen by screen, or leaf components first, using ComposeView and a shared theme.

  2. Why must composables be side-effect free?

    Show hint

    They can be re-run or skipped at any time; side effects belong in effect APIs.

Compare on iOS: SwiftUI vs UIKit: key differences SwiftUI vs UIKit is the same declarative-vs-imperative shift.

Related questions

Suggest a fix if something here is wrong or out of date.