Putus — apa itu, penyebab umum dan metode penyelesaian

Apa artinya "putus" di aplikasi seluler?

Putus — istilah pengguna yang menggambarkan situasi ketika aplikasi kehilangan koneksi dengan server, berhenti merespons tindakan, atau berakhir dengan kesalahan. Dalam arti teknis, ini bisa berupa: kesalahan jaringan (timeout, DNS failure), ANR (pemblokiran thread UI), crash (pengecualian yang tidak ditangani) atau race condition (kondisi balapan).

Bagi pengguna, semua skenario ini terlihat sama: aplikasi berhenti bekerja. Perbedaan bagi pengembang terletak pada pendekatan diagnostik dan perbaikan. Kesalahan jaringan diselesaikan dengan mekanisme retry, ANR dengan memindahkan operasi keluar dari thread UI, crash dengan penanganan pengecualian.

Menurut Crittercism (sekarang Apteligent), rata-rata aplikasi seluler kehilangan 1-2% penggunanya pada setiap crash. Untuk aplikasi dengan 1 juta pengguna, ini berarti 10-20 ribu instalasi hilang per satu bug. Hal ini sangat kritis untuk aplikasi di sektor keuangan dan medis.

Penyebab utama hilangnya koneksi

Jaringan tidak stabil — perangkat seluler terus-menerus beralih antara Wi-Fi dan jaringan seluler, memasuki zona tanpa jangkauan (metro, lift, ruang bawah tanah). Setiap peralihan menyebabkan hilangnya koneksi sementara yang harus ditangani oleh aplikasi dengan benar.

Time-out — jika server tidak merespons dalam waktu yang ditentukan (biasanya 10-30 detik), klien melempar SocketTimeoutException. Time-out yang lama tanpa umpan balik dianggap oleh pengguna sebagai macet. Disarankan untuk mengatur time-out tidak lebih dari 15 detik.

val client = OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
    .readTimeout(15, TimeUnit.SECONDS)
    .writeTimeout(15, TimeUnit.SECONDS)
    .retryOnConnectionFailure(true)
    .build()

Kondisi balapan (race condition) — terjadi ketika beberapa thread secara bersamaan membaca dan menulis data yang sama tanpa sinkronisasi. Misalnya, memuat data dari cache di thread UI secara paralel dengan pembaruan cache dari jaringan dapat menyebabkan menampilkan data yang usang atau tidak benar.

• Pengecualian yang tidak ditangani di callback atau coroutine menyebabkan crash aplikasi
• Tekanan memori — sistem mematikan aplikasi saat kekurangan memori untuk aplikasi latar depan
• Lifecycle race — operasi async selesai setelah Activity/Fragment dihancurkan
• Pemblokiran UI — menjalankan jaringan atau database di thread utama menyebabkan ANR setelah 5 detik

Arsitektur untuk aplikasi yang tangguh

Offline-first — pola arsitektur di mana penyimpanan lokal (Room, CoreData) adalah satu-satunya sumber kebenaran. Jaringan digunakan untuk sinkronisasi data di latar belakang. Pengguna selalu melihat data terkini dari cache lokal, bahkan saat tidak ada jaringan.

Repository pattern — titik masuk tunggal untuk data yang memutuskan apakah akan mengambil data dari jaringan atau cache. Repositori mengabstraksi sumber data dari ViewModel dan UI. Pada kesalahan jaringan, repositori secara otomatis beralih ke sumber lokal.

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUsers(): Result<List<User>> {
        return try {
            val remote = api.fetchUsers()
            dao.insertAll(remote)
            Result.success(remote)
        } catch (e: IOException) {
            val cached = dao.getAll()
            if (cached.isNotEmpty()) {
                Result.success(cached) // kembalikan cache pada kesalahan jaringan
            } else {
                Result.failure(e)
            }
        }
    }
}

Circuit Breaker — pola perlindungan server dari banjir permintaan saat tidak tersedia. Setelah N kesalahan berturut-turut, pemutus terbuka dan semua permintaan segera mengembalikan kesalahan tanpa mencoba koneksi. Setelah time-out tertentu, pemutus masuk ke status setengah terbuka untuk permintaan percobaan.

Bagaimana cara menangani kesalahan jaringan?

Exponential backoff — mekanisme retry standar. Setelah kegagalan pertama tunggu 1 detik, setelah kedua — 2 detik, lalu 4, 8, 16. Batasi jumlah percobaan maksimum (biasanya 3-5) agar tidak membebani server dan baterai.

Umpan balik pengguna — pada kesalahan jaringan tampilkan pesan yang dapat dipahami: "Tidak ada koneksi", "Server sementara tidak tersedia", "Periksa internet". Gunakan Snackbar atau Inline State View. Jangan pernah menampilkan kesalahan teknis (HTTP 500, SocketException) kepada pengguna.

ConnectivityManager — Android API untuk memantau jaringan. Izinkan aplikasi merespons perubahan: saat kehilangan jaringan tampilkan placeholder, saat pemulihan — perbarui data secara otomatis. Di iOS gunakan NWPathMonitor dari framework Network.

class NetworkMonitor(private val context: Context) {
    private val manager =
        context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager

    fun isOnline(): Boolean {
        val network = manager.activeNetwork ?: return false
        val caps = manager.getNetworkCapabilities(network) ?: return false
        return caps.hasCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
    }
}

Alat pemantauan dan pencatatan

Crashlytics (Firebase) — alat pelaporan crash standar untuk aplikasi seluler. Mengumpulkan stacktrace dari semua pengecualian yang tidak ditangani, versi OS, model perangkat, dan waktu crash. Memungkinkan pengelompokan kesalahan dan penugasan penanggung jawab perbaikan.

Sentry — alternatif untuk Crashlytics dengan dukungan pemantauan kinerja. Memungkinkan pelacakan transaksi tertentu (misalnya, "otentikasi pengguna") dan melihat di langkah mana kesalahan terjadi. Performance tracing membantu membedakan time-out jaringan dari bug dalam logika aplikasi.

Timber — pustaka pencatatan untuk Android dengan penambahan tag otomatis berdasarkan kelas. Di build debug, catat semua permintaan dan respons jaringan. Di build release — hanya kesalahan dan peringatan melalui Crashlytics.setCustomLog.

Menurut Firebase Summit 2023, aplikasi yang menerapkan Crashlytics + Performance Monitoring mengurangi waktu rata-rata deteksi dan perbaikan bug kritis dari 3 hari menjadi 4 jam. Disarankan untuk mengatur peringatan pada setiap crash dengan frekuensi lebih dari 0,1% pengguna aktif.