Belajar Jetpack Compose - Real-world Use Cases & Patterns

#Pendahuluan

Semua materi sebelumnya terasa terpisah-pisah: state, navigation, persistence, testing, performa. Episode 20 merangkai semuanya menjadi pola nyata yang dipakai tim produksi di aplikasi sosial, e-commerce, dan dashboard.

Di dunia nyata, tidak ada satu pola yang menjawab semuanya. Yang dibutuhkan adalah pemahaman arsitektur: bagaimana data mengalir, bagaimana state dibagi, dan bagaimana aplikasi tumbuh tanpa menjadi kacau.

Episode 20 ini meliputi studi kasus, pola arsitektur, penskalaan modul, dan design system yang terawat.

#Use Case: Sosial, E-commerce, dan Dashboard

#Aplikasi Sosial

Aplikasi sosial berpusat pada feed dan notifikasi: LazyColumn dengan Paging (episode 9), state interaksi seperti like dan komentar yang naik ke ViewModel, serta animasi untuk feedback instan. Unidirectional data flow sangat membantu di sini karena banyak state yang saling memengaruhi.

#Aplikasi E-commerce

E-commerce kaya form dan keranjang: navigasi dengan argumen dan deep link (episode 8), persistence offline untuk keranjang (episode 11), validasi input (episode 7), dan theming yang konsisten untuk branding (episode 6).

#Dashboard dan Internal Tool

Dashboard membutuhkan data real-time dan tata letak adaptif: BoxWithConstraints untuk layar lebar, refresh berkala dengan coroutine (episode 10), serta chart kustom memakai custom layout (episode 18). Dashboard juga jadi kandidat kuat untuk Compose Multiplatform di episode 17.

#Pola Arsitektur: MVI dan MVVM

#Unidirectional Data Flow

Semua pola arsitektur Compose modern berpegang pada prinsip yang sama: data mengalir satu arah. UI mengirim intent, ViewModel memproses, state baru mengalir kembali ke UI:

Alur data satu arah

UI --> Intent --> ViewModel --> State --> UI

Alur satu arah membuat aplikasi mudah dilacak: setiap perubahan state punya penyebab yang jelas. Ini menghindari bug yang lahir dari banyaknya jalur pembaruan state yang saling timpang tindih.

#MVI dengan Sealed State

MVI mengekspresikan seluruh kondisi layar dalam satu state. Gabungkan pola sealed UiState dari episode 10 dan intent sebagai event:

State dan intent MVI

sealed interface PencarianIntent {
    data class UbahQuery(val teks: String) : PencarianIntent
    data object Cari : PencarianIntent
}
 
data class PencarianUiState(
    val query: String = "",
    val hasil: List<Hasil> = emptyList(),
    val memuat: Boolean = false
)

PencarianUiState adalah satu sumber kebenaran layar, dan PencarianIntent adalah satu-satunya jalur perubahan. UI men-render state; ViewModel menerima intent dan menghasilkan state baru.

#MVVM untuk Skala Menengah

MVVM lebih ringan daripada MVI: ViewModel mengekspos state lewat StateFlow, dan UI memakai collectAsStateWithLifecycle (episode 10). Pilih MVVM saat tim lebih kecil, MVI saat aplikasi kompleks dan perlu jejak perubahan yang ketat.

Cara cepat menilai kecocokan pola: tulis dulu skenario alur data yang paling kompleks di aplikasi. Jika alurnya linear dan sedikit, MVVM sudah cukup. Jika banyak event saling memengaruhi dan butuh jejak audit, MVI memberikan gambaran yang lebih jelas. Keduanya tetap bisa diuji tanpa UI — jalankan ./gradlew :app:testDebugUnitTest untuk memverifikasi logika state setiap kali pola berubah.

#Penskalaan Aplikasi dengan Modul

#Modularisasi Gradle

Saat fitur tumbuh, pecah menjadi modul Gradle: :core:designsystem, :core:network, :feature:auth, :feature:keranjang. Setiap modul punya batas dan dependency yang jelas:

Dependency modul

dependencies {
    implementation(project(":core:designsystem"))
    implementation(project(":core:data"))
}

implementation(project(":core:designsystem")) membuat modul fitur bergantung pada design system bersama. Modularisasi memangkas waktu build dan memaksa batas arsitektur yang sehat.

#Navigation per Modul

Gabungkan modularisasi dengan navigation modular dari episode 8: setiap modul mendaftarkan rutenya lewat extension NavGraphBuilder. Root app hanya menyusun graph-nya. Hasilnya: fitur bisa dikembangkan dan diuji secara terpisah.

Satu hal yang perlu diingat: pola arsitektur bukan tujuan akhir, melainkan alat agar aplikasi tetap mudah diubah. Setiap keputusan — MVI, MVVM, modularisasi, atau jumlah modul — harus diukur dari kemudahan tim menambah fitur dan memperbaiki bug. Jika sebuah lapisan hanya menambah boilerplate tanpa mengurangi biaya perubahan, pertimbangkan kembali.

#Design System yang Mudah Dipelihara

#Satu Sumber Kebenaran

Design system adalah modul tersendiri yang berisi token theme, primitif UI, dan komponen bersama. Seluruh fitur memakainya, bukan mendefinisikan warna sendiri. Setiap perubahan visual cukup dilakukan sekali.

#Kontrak dan Versi

Jadikan design system seperti library: versi dan changelog. Perubahan breaking di-publish lebih dulu sebelum modul fitur mengadopsi. Dengan kontrak yang jelas, tim fitur bisa bergerak cepat tanpa merusak satu sama lain.

#Penutup

Episode 20 merangkai materi menjadi pola nyata: studi kasus sosial, e-commerce, dan dashboard, arsitektur MVI dan MVVM dengan unidirectional data flow, penskalaan aplikasi lewat modularisasi Gradle dan navigation per modul, serta design system sebagai modul dengan kontrak yang jelas.

Inti yang harus dibawa pulang:

• Data mengalir satu arah: intent masuk, state keluar.
• MVI cocok untuk aplikasi kompleks, MVVM untuk skala menengah.
• LazyColumn dengan Paging adalah tulang punggung feed sosial.
• Modularisasi Gradle memangkas build dan mempertegas batas arsitektur.
• Design system adalah modul dengan versi dan changelog.
• Setiap pola harus disesuaikan dengan kebutuhan tim, bukan dogma.

Di episode 21 selanjutnya kita akan membahas ekosistem dan tools — Android Studio, Compose Preview, dan DevTools, library seperti Accompanist, Coil, Retrofit, dan Hilt, sumber daya komunitas, serta cara mengikuti perkembangan Compose.