XML-Layout vs. Jetpack Compose – dasselbe UI, zwei Welten
Ein einfacher Screen mit Bild, Titel und Button – einmal als klassisches XML-Layout mit findViewById, einmal deklarativ in Jetpack Compose. Der direkte Vergleich zeigt, warum Compose so viel Boilerplate spart.
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
Du brauchst mehr als ein Snippet?
Ich entwickle Android-Apps in Kotlin und moderne Websites für Selbstständige und kleine Unternehmen — von der ersten Idee bis zum Release.
Projekt anfragen →Verwandte Snippets
kotlinx.serialization: JSON und data class ohne Handarbeit verbinden
Eine API antwortet mit JSON, deine App will eine data class. Dazwischen steht in vielen Projekten ein handgeschriebener Parser. Mit kotlinx.serialization sind es eine Annotation und eine Zeile – und ein Schalter, ohne den deine App beim nächsten API-Update abstürzt.
AnimatedVisibility in Jetpack Compose – ein- und ausblenden, das nicht springt
Ein Element einfach mit if wegzulassen, poppt hart weg. AnimatedVisibility blendet es weich ein und aus – mit sinnvollen Voreinstellungen und, wenn du willst, deiner eigenen Kombination aus Faden und Bewegung. Ich zeige dir beides.
snapshotFlow in Jetpack Compose – aus Compose-Zustand einen Flow machen
Manchmal willst du auf einen Compose-Zustand reagieren wie auf einen Datenstrom – entprellen, kombinieren, sammeln. Genau das macht snapshotFlow. Ich zeige dir das an der häufigsten Aufgabe: mehr laden, wenn der Nutzer ans Listenende scrollt.