Belajar Mobile Developer - Real-Time & Streaming Apps

#Pendahuluan

Setelah di episode 21 kita menghadirkan AI coach yang berdialog dengan pengguna, kali ini kita naik satu level: membuat aplikasi yang selalu terhubung. Episode 22 ini membahas real-time & streaming apps — WebSocket untuk chat dan live data, serta streaming video (HLS & WebRTC). Studi kasus Fitku kali ini mendapat fitur kelas live: instruktur mengalirkan video, sementara peserta melihat detak jantung dan leaderboard langkah secara langsung.

Mengapa ini penting? Di 2026 pengguna tidak rela menekan refresh. Fitur seperti chat, notifikasi live, streaming workout, dan leaderboard waktu nyata adalah pembeda antara aplikasi "biasa" dan aplikasi yang terasa hidup — sekaligus fondasi sebelum kita membahas sinkronisasi offline di episode 23.

#HTTP vs WebSocket: Dua Dunia yang Berbeda

HTTP adalah protokol request-response: klien bertanya, server menjawab, lalu koneksi selesai. Kalau ingin data terbaru, klien harus bertanya lagi (polling). WebSocket adalah koneksi full-duplex yang tetap terbuka: server bisa mengirim data kapan saja tanpa ditanya.

Koneksi WebSocket dimulai sebagai HTTP, lalu di-upgrade lewat handshake Upgrade: websocket. URL-nya memakai ws:// untuk plain dan wss:// untuk TLS (wajib di production, seperti https).

#WebSocket untuk Chat & Live Data

Kasus paling klasik adalah chat, dan di Fitku kita pakai untuk live leaderboard workout komunitas: setiap kali anggota menyelesaikan satu set, server menyiarkan angka barunya ke semua peserta.

WebSocket dengan OkHttp

val client = OkHttpClient()
val request = Request.Builder()
    .url("wss://fitku.dev/ws/leaderboard?room=run-07")
    .build()
 
val listener = object : WebSocketListener() {
    override fun onMessage(webSocket: WebSocket, text: String) {
        // {"type":"step_update","userId":42,"steps":9842}
        viewModel.updateLeaderboard(parseJson(text))
    }
 
    override fun onClosed(webSocket: WebSocket, code: Int, reason: String) {
        scheduleReconnect() // koneksi terputus bersih
    }
 
    override fun onFailure(webSocket: WebSocket, t: Throwable, response: Response?) {
        scheduleReconnect() // koneksi gagal (network drop)
    }
}
val ws = client.newWebSocket(request, listener)

#Reconnect dengan Exponential Backoff

Jaringan ponsel tidak stabil — koneksi akan putus. Jangan langsung sambung ulang; naikkan jeda secara eksponensial agar tidak membebani server saat banyak pengguna putus bersamaan:

percobaan ke-1 → tunggu 1 detik
percobaan ke-2 → tunggu 2 detik
percobaan ke-3 → tunggu 4 detik
percobaan ke-4 → tunggu 8 detik
...          → cap maksimal 60 detik

Tambahkan juga heartbeat (ping/pong) agar koneksi mati-senyap terdeteksi cepat, dan reset counter backoff setelah koneksi berhasil bertahan beberapa saat.

#Arsitektur Realtime Fitku

WebSocket hanyalah "pipa". Di baliknya ada server yang memastikan pesan sampai ke semua peserta yang relevan:

Pola ini (gateway + pub/sub) memisahkan urusan koneksi dari urusan logika bisnis, sehingga menambah fitur realtime baru tidak mengganggu yang lama.

#Streaming Video: HLS vs WebRTC

Untuk video, ada dua kategori kebutuhan dengan teknologi berbeda:

• HLS (HTTP Live Streaming): untuk one-to-many seperti kelas live instruktur-ke-peserta. Terbukti stabil, didukung ExoPlayer/AVPlayer, dan latensinya biasanya 6-30 detik — masih ok untuk kelas yang hanya menonton.
• WebRTC: untuk two-way, low-latency (di bawah 1 detik) seperti panggilan video personal trainer. P2P/relay via SFU, kompleksitas jauh lebih tinggi.

Peserta menonton instruktur   → HLS   (ExoPlayer/AVPlayer)
Peserta bicara dengan trainer → WebRTC (SFU: LiveKit, mediasoup, dll.)
Rekaman kelas                → HLS   (vod, offload ke CDN)

#Praktik: Fitur Kelas Live Fitku

Alur implementasinya:

1. Join room: app memanggil REST untuk mendapat token room, lalu membuka WebSocket wss://fitku.dev/ws/live.
2. Sinkronkan state awal: server mengirim snapshot peserta & leaderboard saat join (jangan menunggu event berikutnya).
3. Streaming video: instruktur mengirim HLS stream URL lewat pesan WebSocket, app me-mount-nya ke pemutar video.
4. Live telemetry: sensor heart-rate peserta dikirim dibatasi (misal 1x/detik) — kirim tiap frame sensor tanpa batas hanya akan menyumbat jaringan dan menghabiskan baterai.
5. Presence: server menyiarkan siapa yang join/leave, agar leaderboard selalu akurat.

#Common Pitfalls Real-Time

• Tanpa reconnect: koneksi putus lalu app diam — pengguna mengira leaderboard "beku". Selalu reconnect + beri indikator status koneksi.
• Mengirim semua data tiap frame: throttle & batch event (misal sensor tiap 1 Hz, bukan tiap 10 ms).
• Mengabaikan keamanan: WebSocket wss:// wajib, validasi token di gateway (episode 13), dan jangan pernah menaruh key di klien.
• Anti-pattern polling saat realtime dibutuhkan: misal chat yang di-polling tiap 2 detik — lebih boros dan lebih lambat daripada WebSocket.
• Tanpa status koneksi di UI: tampilkan "Menghubungkan… / Terputus — mencoba lagi" agar pengguna paham situasi.

#Penutup

Pada episode 22 ini, kalian telah membangun aplikasi realtime:

• Memahami perbedaan HTTP vs WebSocket dan kapan masing-masing tepat.
• Membangun chat/live data dengan WebSocket + reconnect & backoff.
• Arsitektur realtime dengan gateway dan pub/sub.
• Memilih HLS vs WebRTC untuk streaming video.
• Praktik kelas live Fitku dengan telemetry yang hemat resource.

Tapi apa jadinya ketika pengguna Fitku lari di area tanpa sinyal sama sekali? Di episode 23 selanjutnya kita jawab dengan Offline-First & Sync Architecture — optimistic updates, conflict resolution, dan background sync. Sampai jumpa!