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
Room-Migrationen – das Schema ändern, ohne Nutzerdaten zu verlieren
Eine neue Spalte in der Entity, und beim nächsten Start ist der Spielstand weg – weil fallbackToDestructiveMigration die Datenbank einfach löscht. So machst du es richtig, inklusive Test.
stateIn und shareIn – aus einem kalten Flow wird geteilter Zustand
Jeder Sammler eines kalten Flows startet die Arbeit neu – zwei Beobachter, zwei Datenbankabfragen. stateIn und shareIn machen daraus einen Strom, den sich alle teilen, samt aktuellem Wert und Abschalten bei Inaktivität.
viewModelScope – Coroutinen, die mit dem Bildschirm verschwinden
Eine Coroutine, die nach dem Schließen des Bildschirms weiterläuft, schreibt in ein ViewModel, das niemand mehr sieht – und hält im schlimmsten Fall die ganze Activity im Speicher. viewModelScope beendet sie automatisch.