Belajar Jetpack Compose - Sejarah, Latar Belakang & Mengapa Memilih Jetpack Compose

#Pendahuluan

Sebelum menulis baris kode Compose, penting memahami mengapa Compose ada. Episode 0 sudah menyiapkan environment kalian; sekarang kita mundur sejenak ke sejarah UI Android untuk melihat masalah yang coba dipecahkan Compose.

Pendekatan lama Android — layout XML ditambah logika imperatif di Activity — bertahan lebih dari satu dekade dan sukses di banyak aplikasi. Tapi kompleksitasnya tumbuh tidak terkendali: adapter, view holder, dan sinkronisasi state manual membuat bug mudah merayap masuk. Compose hadir sebagai jawaban.

Episode 1 ini membedah perjalanan evolusi tersebut, keunggulan Compose, perbandingan dengan pendekatan lain, dan di mana Compose paling unggul dipakai.

#Evolusi UI Android dari XML ke Compose

#Era Imperatif: XML, findViewById, dan Adapter

Android lahir dengan model UI imperatif. Kalian mendeklarasikan layout di file XML, lalu menghubungkan elemennya dengan findViewById di Activity. Setiap perubahan data harus diikuti pembaruan manual pada view — misalnya memanggil notifyDataSetChanged pada RecyclerView adapter.

Model ini bekerja, tapi boilerplate-nya besar. Semakin banyak state di layar, semakin banyak kode sinkronisasi yang harus dijaga. Kalau kalian lupa memperbarui satu view, UI dan data tidak lagi sinkron.

#Lahirnya Compose

Jetpack Compose diumumkan Google pada tahun 2019 dan mencapai versi stable 1.0 pada Juli 2021. Compose mengganti pendekatan imperatif dengan deklaratif: kalian mendeskripsikan UI sebagai fungsi dari state, dan framework yang mengurus pembaruannya.

UI deklaratif dengan Compose

@Composable
fun KartuSalam(nama: String) {
    Card(Modifier.fillMaxWidth()) {
        Column(Modifier.padding(16.dp)) {
            Text("Halo, $nama!")
            Text("Selamat datang di Compose")
        }
    }
}

Card(Modifier.fillMaxWidth()) dan Column(Modifier.padding(16.dp)) menunjukkan gaya Compose: setiap elemen adalah fungsi Kotlin yang menerima modifier. Tidak ada lagi file XML terpisah atau findViewById — struktur, data, dan perilaku berada di satu tempat.

#Stabilitas dan Kompatibilitas API

Compose dirilis dengan kebijakan kompatibilitas yang ketat. Sejak versi 1.0, Google berkomitmen menjaga API tetap stabil — perubahan besar selalu diumumkan lebih dulu dan melewati masa deprecation sebelum dihapus. Bagi kalian yang memulai project baru, ini berarti kode Compose yang ditulis sekarang tetap bisa dipelihara bertahun-tahun ke depan.

Meski begitu, versi library tetap perlu dijaga. Dependency Compose dikelola lewat version catalog di gradle/libs.versions.toml, dan kalian bisa memeriksa dependency yang sudah ketinggalan zaman lewat perintah Gradle. Konsistensi versi ini penting karena Compose, compiler, dan library pendukungnya saling bergantung satu sama lain.

#Keunggulan Compose: Deklaratif, Kotlin-native, dan Reaktif

#Kotlin-native Tanpa Boilerplate

Seluruh API Compose adalah fungsi Kotlin. Kalian memakai bahasa yang sama untuk UI dan logika bisnis, dengan type safety penuh saat kompilasi. Tidak ada R.id lookup, tidak ada adapter untuk list sederhana, dan preview bisa di-render langsung di IDE.

Inilah yang membuat onboarding developer baru jauh lebih singkat dibandingkan era XML: tidak ada lagi boilerplate adapter dan tidak ada lagi sinkronisasi manual antara XML dan kode.

#Reaktif dan State-driven

Compose membaca state dan memperbarui hanya bagian UI yang berubah. Proses ini disebut recomposition: Compose membandingkan komposisi sebelumnya lalu menjalankan ulang hanya composable yang inputnya berubah. Kalian tidak lagi memanggil fungsi update manual — cukup ubah state, UI mengikuti.

Pola pikir ini juga mempermudah testing: karena UI hanyalah fungsi dari state, perilaku layar bisa diverifikasi tanpa menggerakkan emulator. Strategi pengujian ini akan dibahas lengkap di episode 14, tapi sejak sekarang ingat bahwa desain deklaratif dan state-driven lahir untuk membuat aplikasi lebih mudah diverifikasi.

#Perbandingan dengan XML dan Framework Cross-platform

#Compose vs XML-based UI

XML masih dipakai untuk aplikasi legacy, dan Compose menyediakan jalur migrasi bertahap lewat interop (dibahas di episode 16). Untuk project baru, Compose unggul dalam produktivitas karena boilerplate lebih sedikit dan UI lebih mudah diuji.

#Compose vs Flutter dan React Native

Flutter memakai Dart dan mengontrol seluruh rendering sendiri, sedangkan React Native memakai JavaScript dengan bridge ke view native. Compose berbeda: dia berjalan langsung di Android framework dengan komponen Material asli, dan terintegrasi dalam dengan system seperti perangkat lunak aksesibilitas dan lifecycle.

Kelebihan Compose di sini adalah fidelity native: tidak ada lapisan rendering tersendiri, sehingga konsistensi visual dengan platform dan fitur Android lainnya lebih tinggi.

Keunggulan lain adalah ekosistem yang menyatu: Compose menikmati update langsung dari Google bersama library Android lainnya, sehingga fitur baru seperti dynamic color dan adaptive layouts sampai ke kalian tanpa memerlukan library pihak ketiga. Bagi tim yang sudah berinvestasi di Kotlin, ini mengurangi biaya belajar sekaligus biaya pemeliharaan.

Keputusan memakai Compose bukan keputusan binary: kalian bisa mulai dari satu screen dan memperluasnya pelan-pelan. Karena Compose hidup di atas Android framework yang sama, jalur adopsi bertahap ini tidak memaksa menulis ulang seluruh aplikasi sekaligus.

#Use Cases: Kapan Memakai Compose

Compose paling unggul dalam skenario berikut:

• Aplikasi Android modern yang mengandalkan UI dinamis dan data reaktif.
• Design system reusable: komponen UI yang dibungkus sebagai composable dan dipakai lintas fitur.
• Screen dengan banyak state: form, dashboard, dan feed yang responnya mengubah banyak elemen sekaligus.
• Tim Kotlin: karena seluruh stack satu bahasa, onboarding anggota baru lebih cepat.

Untuk aplikasi yang sudah berjalan lama dengan UI XML, Compose tetap bisa diadopsi bertahap — pola hybrid ini akan dibahas di episode 16. Kuncinya adalah tidak perlu pindah sekaligus.

#Memulai dari Project Baru

Jika kalian memulai project baru, pastikan build pertama sukses sejak awal:

./gradlew :app:assembleDebug

Jalankan ./gradlew :app:assembleDebug untuk memastikan seluruh dependency dan plugin terunduh dengan benar. Jika build sukses, fondasi kalian siap untuk menulis composable pertama di episode 3.

#Penutup

Episode 1 menjelaskan konteks sejarah Compose: dari era XML yang imperatif dan penuh boilerplate, lahir pendekatan deklaratif yang Kotlin-native dan reaktif. Kalian juga melihat perbandingan dengan Flutter dan React Native, serta skenario di mana Compose paling diuntungkan.

Inti yang harus dibawa pulang:

• Android lama memakai XML plus pembaruan view manual yang rawan bug.
• Compose stabil sejak Juli 2021 dan mengganti model itu dengan deklaratif.
• Compose Kotlin-native: satu bahasa untuk UI dan logika bisnis.
• Recomposition memperbarui hanya bagian UI yang state-nya berubah.
• Compose terintegrasi dalam dengan framework Android, bukan rendering mandiri.
• Adopsi ke aplikasi lama bisa bertahap lewat interop.

Di episode 2 selanjutnya kita akan membahas konsep dasar dan arsitektur Compose — composable functions, recomposition, composition tree dan slots, pipeline rendering, serta cara Compose berdampingan dengan Android views. Ini adalah fondasi konseptual yang akan kalian pakai di semua episode berikutnya.