Pindah dari Web ke Android Development: Yang Saya Pelajari
Sebelum serius di Android development, saya udah cukup lama kerja di web. Pindah dari mindset web ke mobile ternyata butuh beberapa penyesuaian yang nggak saya duga — dan beberapa di antaranya baru kerasa setelah app-nya kelar terus ada bug aneh muncul di production.
Lifecycle itu nyata dan penting
Di web, “halaman” biasanya hidup dan mati sederhana — load, lalu unload, selesai. Di Android, Activity dan Fragment punya lifecycle yang jauh lebih kompleks (onCreate, onStart, onResume, onPause, dan seterusnya), dan lupa handle salah satu state bisa bikin app crash atau leak memory. Bug pertama yang bikin saya beneran ngerti ini: user muter layar (rotasi device), Activity-nya di-destroy dan dibikin ulang, terus state yang saya simpen di variabel biasa hilang begitu aja. Di web nggak ada konsep “layar diputer terus semuanya reset” — jadi ini benar-benar hal baru yang harus dipelajari dari nol, bukan cuma sintaks baru buat konsep yang udah saya kenal.
Resource constraint itu nyata
Di web, kamu biasanya nggak terlalu mikirin memory atau battery user — browser dan OS yang nanggung sebagian besar bebannya. Di mobile, setiap background task, setiap wake lock, punya cost langsung ke battery life user, dan mereka bakal uninstall app kamu kalau boros. Saya pernah ship fitur yang polling server tiap beberapa detik di background tanpa mikir dua kali — kebiasaan yang biasa aja di web, tapi di Android itu langsung bikin battery drain yang kentara, dan itu ketauan dari review satu bintang di Play Store, bukan dari testing internal.
Async itu default, bukan opsional
Network call, disk I/O, semuanya harus async supaya nggak block main thread dan bikin UI freeze. Kotlin Coroutines bikin ini jauh lebih manageable dibanding callback hell yang saya inget dari awal-awal belajar Android pakai Java. Tapi transisi dari cara kerja async di web (Promise, async/await yang relatif straightforward) ke coroutine scope, structured concurrency, dan lifecycle-aware coroutine di Android itu butuh waktu buat beneran paham, bukan cuma niru-niru pattern dari StackOverflow.
Testing lebih ribet
Nggak ada “refresh browser” buat lihat perubahan. Build-deploy-test cycle di Android jauh lebih lambat dibanding hot-reload di web, walau makin membaik dengan tools modern kayak Jetpack Compose Preview. Awal-awal ini bikin saya frustrasi — kebiasaan iterasi cepat dari web itu bikin saya nggak sabaran nunggu build Android yang bisa makan waktu semenit lebih cuma buat liat perubahan satu baris.
Yang paling saya syukuri dari pengalaman ini: mindset “resource-aware” dari mobile development ternyata bikin saya nulis kode web yang lebih efisien juga — sekarang saya lebih peka soal berapa kali sebuah komponen re-render atau berapa sering satu request ke-fire, kebiasaan yang saya nggak punya sebelum belajar Android.