XML-Layout vs. Jetpack Compose – dasselbe UI, zwei Welten

Wenn du von klassischem Android kommst, kennst du das Muster: Layout in einer XML-Datei, aufgeblasen über setContentView, Views per findViewById (oder ViewBinding) heraussuchen und im Code verdrahten. Jetpack Compose dreht das um – die UI ist eine Kotlin-Funktion, die beschreibt, *wie* der Zustand aussehen soll. Hier derselbe Screen in beiden Welten.

Klassisch: XML + ViewBinding

<!-- res/layout/profile.xml -->
<LinearLayout
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="vertical"
    android:padding="16dp">

    <TextView
        android:id="@+id/title"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:textSize="22sp" />

    <Button
        android:id="@+id/follow"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="Folgen" />
</LinearLayout>

class ProfileActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val b = ProfileBinding.inflate(layoutInflater)
        setContentView(b.root)

        b.title.text = "Michael"
        b.follow.setOnClickListener { /* folgen */ }
    }
}

Zwei Dateien, inflate, drei manuelle Verdrahtungen – und das UI und der Code driften mit der Zeit auseinander.

Deklarativ: dasselbe in Compose

@Composable
fun Profile(name: String, onFollow: () -> Unit) {
    Column(Modifier.padding(16.dp)) {
        Text(name, fontSize = 22.sp)
        Button(onClick = onFollow) { Text("Folgen") }
    }
}

Eine Funktion, ein Ort. Kein findViewById, kein separates XML, keine Gefahr, dass ein id ins Leere zeigt.

Der entscheidende Unterschied

• XML ist imperativ: Du baust das Layout und *änderst* es danach von Hand (title.text = …). Bei jedem Zustandswechsel musst du selbst nachziehen.
• Compose ist deklarativ: Du beschreibst das UI als Funktion des Zustands. Ändert sich name, ruft Compose die Funktion neu auf (Recomposition) und aktualisiert nur, was sich unterscheidet.

Für neue Apps ist Compose heute der empfohlene Weg – weniger Boilerplate, Vorschau direkt in Android Studio und Zustandslogik an einem Ort. Bestehende XML-Screens kannst du übrigens Schritt für Schritt migrieren; beides läuft in derselben App nebeneinander.

Du willst eine Android-App modern in Kotlin & Compose umsetzen – oder eine alte XML-App behutsam migrieren? Sprich mich an.

Quellen

• Why Compose (developer.android.com)
• Thinking in Compose (developer.android.com)