Panduan Mobile Development: Framework, Kotlin, dan Rilis Android

Tabel perbandingan framework jarang memutuskan apa pun, karena Flutter, React Native, dan Kotlin sama-sama tampak meyakinkan di atas kertas. Cara yang lebih jujur adalah membangun aplikasi yang sama tiga kali dalam ukuran sangat kecil: satu layar berisi kolom isian, tombol Tambah, dan daftar yang bertambah setiap kali tombol ditekan. Proyek seukuran itu cukup untuk merasakan bahasa, alat, dan cara tiap framework menyusun tampilan. Waktu sekitar 6 sampai 10 jam per jalur, tersebar dalam 1 sampai 2 minggu, biasanya memadai untuk sampai pada keputusan.

Di Flutter, pembelajar menulis Dart, menyusun widget seperti Column, TextField, dan ListView, lalu merasakan hot reload yang memperbarui layar dalam hitungan detik. Di React Native, pembelajar yang sudah memakai JavaScript langsung mengenali pola komponen dan state dari pengembangan web, dan Expo memudahkan menjalankan proyek di ponsel tanpa pemasangan yang berat. Di Kotlin dengan Jetpack Compose, pembelajar bekerja di Android Studio, menulis fungsi composable, dan mencoba hasilnya di emulator.

Sesudah tiap percobaan, catat tiga hal: bagian mana yang membuat buntu paling lama, seberapa mudah pesan galatnya dipahami, dan apakah ada keinginan melanjutkan proyek itu esok hari. Jawaban atas pertanyaan terakhir sering lebih menentukan daripada angka kinerja. Begitu satu jalur dipilih, dua jalur lainnya disimpan dulu sampai satu aplikasi benar-benar selesai, sebab berpindah framework di tengah jalan menghabiskan berbulan-bulan tanpa karya yang bisa ditunjukkan.

Proyek Android pertama di Android Studio hampir selalu dibuka dengan menunggu Gradle sync, proses yang mengunduh pustaka dan menyiapkan konfigurasi build. Pada koneksi lambat langkah ini bisa memakan waktu lama, dan pesan galat pertama sering muncul di sini: versi plugin yang tidak cocok, pustaka yang gagal diunduh, atau SDK yang belum terpasang. Dua berkas yang perlu dikenali adalah build.gradle.kts tingkat proyek dan tingkat modul app, tempat versi SDK dan daftar dependensi dituliskan.

Saat aplikasi berjalan lalu tertutup mendadak, jawabannya ada di Logcat. Pembelajar perlu terbiasa menyaring Logcat menurut nama paket aplikasinya sendiri dan menurut tingkat Error, sebab tanpa saringan layar itu dipenuhi pesan sistem. Stack trace dibaca dari atas: baris pertama menyebut jenis galat, lalu cari baris pertama yang menunjuk berkas buatan sendiri, misalnya MainActivity.kt baris 42. Bila ada bagian berlabel Caused by, sebab utamanya biasanya tertulis di sana.

Latihan yang baik adalah sengaja merusak aplikasi Halo Dunia dengan tiga cara: memanggil !! pada nilai null, mengakses indeks daftar di luar batas, dan membuka Activity kedua yang belum dideklarasikan di AndroidManifest. Untuk tiap kerusakan, temukan baris penyebabnya lewat Logcat sebelum membaca ulang kode. Pembelajar yang sudah bisa menunjuk baris penyebab dalam satu atau dua menit siap pindah ke tahap tampilan dengan bekal yang tenang.

Jetpack Compose menyusun layar dari fungsi composable, dan layar diperbarui lewat recomposition: setiap kali state yang dibaca sebuah composable berubah, fungsi itu dijalankan ulang dan bagian layar yang terdampak digambar kembali. Konsep ini paling sering membingungkan pembelajar yang terbiasa mengubah tampilan secara langsung, misalnya mengganti teks sebuah label dengan satu perintah.

Dua alat utamanya adalah remember dan mutableStateOf. Variabel biasa di dalam composable kembali ke nilai awal setiap kali recomposition terjadi, sehingga penghitung yang ditulis tanpa remember tampak membeku di angka nol walau tombol terus ditekan. remember menyimpan nilai selama composable masih tampil, sedangkan rememberSaveable juga mempertahankannya ketika layar diputar. Kasus penghitung yang membeku ini sangat umum dan menjadi latihan diagnosis yang bagus untuk memahami cara Compose berpikir.

Langkah berikutnya adalah state hoisting. State dipindahkan ke composable induk, lalu composable anak menerima nilai dan fungsi callback sebagai parameter, seperti pasangan value dan onValueChange pada TextField. Pola ini membuat composable kecil mudah dipakai ulang dan mudah dilihat lewat @Preview tanpa menjalankan seluruh aplikasi. Latihannya: bangun layar daftar tugas berisi TextField, tombol Tambah, dan LazyColumn, lalu pecah menjadi tiga composable yang state-nya dipegang satu induk.

Seluruh penggambaran layar Android dikerjakan di thread utama. Bila thread itu sibuk membaca basis data atau menunggu jawaban server, layar membeku, dan bila kebekuan berlangsung sekitar lima detik, sistem menampilkan dialog Aplikasi tidak merespons yang dikenal sebagai ANR. Android bahkan menolak pemanggilan jaringan di thread utama dengan NetworkOnMainThreadException, jadi setiap pembelajar akan menjumpai batas ini begitu aplikasinya mulai mengambil data.

Kotlin coroutine adalah cara ringkas memindahkan pekerjaan berat. Fungsi bertanda suspend bisa berhenti sementara tanpa memblokir thread. viewModelScope.launch memulai pekerjaan yang otomatis dibatalkan ketika ViewModel dibersihkan, dan withContext(Dispatchers.IO) memindahkan pembacaan berkas atau jaringan ke thread latar. Room dan Retrofit sudah mendukung fungsi suspend, sehingga kode pembelajar cukup memanggilnya dari dalam coroutine.

Konsep ini terasa abstrak, jadi latihlah dengan percobaan yang kasatmata. Buat tombol yang menjalankan Thread.sleep(6000) di thread utama dan rasakan layar membeku, lalu ganti dengan delay(6000) di dalam coroutine dan lihat animasi tetap berjalan. Tambahkan indikator pemuatan yang tampil selama menunggu. Kuasai satu konsep sampai tuntas, misalnya suspend dan scope, sebelum menumpuknya dengan Flow dan operatornya, supaya tahap ini tetap terkendali.

Aplikasi yang diunggah ke Google Play harus ditandatangani. Lewat menu Build lalu Generate Signed Bundle/APK, Android Studio membuat berkas keystore (.jks) berisi kunci unggah beserta alias dan kata sandinya. Berkas ini disimpan di luar repositori, dicadangkan di tempat aman, dan dijauhkan dari GitHub publik. Dengan Play App Signing, Google memegang kunci penandatanganan aplikasi, dan kunci unggah yang hilang bisa diganti lewat permintaan reset, walau prosesnya memakan waktu.

Sejak Agustus 2021, aplikasi baru di Google Play diunggah dalam format Android App Bundle (.aab), lalu Play membuat APK yang disesuaikan dengan perangkat tiap pengguna. Setiap unggahan wajib memakai versionCode yang lebih besar dari unggahan sebelumnya, sedangkan versionName adalah label yang dibaca pengguna, misalnya 1.0.2. Lupa menaikkan versionCode membuat Play Console menolak unggahan tersebut.

Sebelum rilis publik, jalur pengujian internal di Play Console memungkinkan aplikasi dipasang oleh sekelompok kecil penguji lewat tautan. Akun pengembang pribadi yang baru juga diminta menjalankan pengujian tertutup bersama sejumlah penguji sebelum boleh rilis produksi, dan syarat terbarunya dibaca langsung di Play Console. Halaman toko perlu ikon, tangkapan layar, deskripsi, kebijakan privasi, yang tetap diwajibkan walau aplikasi tidak mengumpulkan data pribadi, dan formulir keamanan data. Bagi yang belum siap rilis, repositori GitHub dengan README yang jelas sudah menjadi portofolio yang layak ditunjukkan.