Sinkron latar belakang aplikasi mobile offline-first: konflik, retry, UX

Masalah: pengguna mengedit saat offline dan kenyataan berubah

Seseorang mulai mengerjakan tugas dengan koneksi bagus, lalu masuk lift, sudut gudang, atau terowongan kereta bawah tanah. Aplikasi tetap berjalan, jadi mereka terus bekerja. Mereka mengetuk Simpan, menambahkan catatan, mengubah status, mungkin bahkan membuat rekaman baru. Semua terlihat baik karena layar diperbarui segera.

Kemudian, koneksi kembali dan aplikasi mencoba mengejar di latar belakang. Di situlah sinkronisasi latar belakang bisa mengejutkan orang.

Jika aplikasi tidak hati-hati, aksi yang sama bisa dikirim dua kali (duplikasi), atau perubahan yang lebih baru dari server bisa menimpa apa yang baru saja dilakukan pengguna (edit hilang). Kadang aplikasi menampilkan status membingungkan seperti “Tersimpan” dan “Belum tersimpan” sekaligus, atau sebuah rekaman muncul, menghilang, lalu muncul kembali setelah sinkron.

Konflik sederhana: dua perubahan berbeda dibuat pada hal yang sama sebelum aplikasi sempat merekonsiliasinya. Misalnya, seorang agen support mengubah prioritas tiket menjadi Tinggi saat offline, sementara rekan tim yang online menutup tiket itu. Saat ponsel offline tersambung kembali, kedua perubahan tidak dapat diterapkan bersih tanpa aturan.

Tujuannya bukan membuat pengalaman offline sempurna. Tujuannya adalah membuatnya dapat diprediksi:

• Orang bisa terus bekerja tanpa takut kehilangan pekerjaan.
• Sinkron terjadi nanti tanpa duplikat misterius.
• Saat sesuatu butuh perhatian, aplikasi jelas menyatakan apa yang terjadi dan apa langkah selanjutnya.

Ini berlaku apakah Anda menulis kode di Kotlin/SwiftUI atau membangun aplikasi native dengan platform tanpa kode seperti AppMaster. Bagian tersulit bukan widget UI. Bagian tersulit adalah memutuskan bagaimana aplikasi berperilaku ketika dunia berubah sementara pengguna offline.

Model offline-first sederhana (tanpa jargon)

Aplikasi offline-first mengasumsikan ponsel akan kehilangan jaringan kadang-kadang, tapi aplikasi harus tetap terasa dapat dipakai. Layar harus dimuat dan tombol bekerja bahkan saat server tak dapat dijangkau.

Empat istilah menutupi sebagian besar kasus:

• Cache lokal: data yang disimpan di perangkat sehingga aplikasi bisa menampilkan sesuatu seketika.
• Antrean sinkron: daftar aksi yang dilakukan pengguna saat offline (atau saat jaringan tidak stabil).
• Kebenaran server: versi yang disimpan di backend yang akhirnya dibagi oleh semua orang.
• Konflik: saat perubahan yang diantrekan pengguna tidak lagi bisa diterapkan bersih karena versi server berubah.

Model mental yang berguna adalah memisahkan baca dari tulis.

Baca biasanya sederhana: tampilkan data terbaik yang tersedia (sering dari cache lokal), lalu perbarui diam-diam saat jaringan kembali.

Tulis berbeda. Jangan bergantung pada “menyimpan seluruh rekaman” sekaligus. Itu rusak begitu Anda offline.

Sebaliknya, catat apa yang dilakukan pengguna sebagai entri kecil dalam log perubahan. Misalnya: “set status ke Disetujui,” “tambah komentar X,” “ubah qty dari 2 ke 3.” Setiap entri masuk ke antrean sinkron dengan cap waktu dan ID. Sinkron latar belakang lalu mencoba mengirimkannya.

Pengguna terus bekerja sementara perubahan berpindah dari tertunda ke tersinkron.

Jika Anda menggunakan platform tanpa kode seperti AppMaster, Anda tetap menginginkan blok bangunan yang sama: baca yang di-cache untuk layar cepat, dan antrean aksi pengguna yang jelas yang bisa di-retry, digabung, atau ditandai saat terjadi konflik.

Tentukan apa yang benar-benar perlu didukung offline

Istilah offline-first bisa terdengar seperti “semua bekerja tanpa koneksi,” tetapi janji itu sering membuat banyak aplikasi bermasalah. Pilih bagian yang benar-benar mendapat manfaat dari dukungan offline, dan biarkan sisanya jelas online-only.

Pikirkan dalam istilah intent pengguna: apa yang perlu dilakukan orang di basement, di pesawat, atau di gudang dengan sinyal fluktuatif? Default yang baik adalah mendukung aksi yang membuat atau memperbarui pekerjaan sehari-hari, dan memblokir aksi di mana “kebenaran terbaru” penting.

Set tindakan yang ramah-offline biasanya mencakup membuat dan mengedit rekaman inti (catatan, tugas, inspeksi, tiket), membuat draf komentar, dan melampirkan foto (disimpan lokal, diunggah nanti). Menghapus bisa bekerja juga, tetapi lebih aman sebagai soft delete dengan jendela undo sampai server mengonfirmasi.

Sekarang putuskan apa yang harus tetap real-time karena risikonya terlalu tinggi. Pembayaran, perubahan izin, persetujuan, dan apa pun yang melibatkan data sensitif biasanya harus memerlukan koneksi. Jika pengguna tidak bisa memastikan aksi valid tanpa memeriksa server, jangan izinkan offline. Tampilkan pesan “membutuhkan koneksi” yang jelas, bukan error misterius.

Tetapkan ekspektasi untuk kesegaran data. “Offline” bukan biner. Tentukan seberapa basi data boleh: menit, jam, atau “saat aplikasi dibuka lagi.” Taruh aturan itu di UI dengan kata-kata sederhana, misalnya “Terakhir diperbarui 2 jam lalu” dan “Menyinkron saat online.”

Terakhir, tandai data yang rentan konflik lebih awal. Hitung inventaris, tugas bersama, dan pesan tim sering jadi pemicu konflik karena banyak orang mengedit dengan cepat. Untuk itu, pertimbangkan membatasi edit offline ke draf, atau merekam perubahan sebagai event terpisah daripada menimpa satu nilai tunggal.

Jika Anda membangun di AppMaster, langkah keputusan ini membantu memodelkan data dan aturan bisnis sehingga aplikasi dapat menyimpan draf aman offline sembari menjaga aksi berisiko tetap online-only.

Rancang antrean sinkron: apa yang disimpan untuk setiap perubahan

Saat pengguna bekerja offline, jangan mencoba “mensinkronkan database.” Sinkronkan aksi pengguna. Antrean aksi yang jelas adalah tulang punggung sinkron latar belakang, dan ia tetap bisa dimengerti saat sesuatu salah.

Jaga aksi kecil dan manusiawi, selaras dengan apa yang sebenarnya dilakukan pengguna:

• Buat rekaman
• Perbarui field tertentu
• Ubah status (submit, approve, archive)
• Hapus (lebih baik soft delete sampai dikonfirmasi)

Aksi kecil lebih mudah debug. Jika dukungan perlu membantu pengguna, jauh lebih mudah membaca “Ubah status Draft -> Submitted” daripada memeriksa blob JSON besar.

Untuk setiap aksi yang diantrekan, simpan metadata yang cukup untuk memainkannya ulang dengan aman dan mendeteksi konflik:

• Identifier rekaman (dan ID lokal sementara untuk rekaman baru)
• Cap waktu aksi dan identifier perangkat
• Versi yang diharapkan (atau waktu terakhir yang diketahui) dari rekaman
• Payload (field spesifik yang diubah, plus nilai lama jika bisa)
• Kunci idempoten (id aksi unik sehingga retry tidak membuat duplikat)

Versi yang diharapkan inilah kunci penanganan konflik yang jujur. Jika versi server sudah bergerak, Anda bisa menjeda dan meminta keputusan alih-alih menimpa orang lain secara diam-diam.

Beberapa aksi harus diterapkan bersama karena pengguna melihatnya sebagai satu langkah. Misalnya, “Buat pesanan” plus “Tambah tiga item” harus berhasil atau gagal sebagai satu kesatuan. Simpan group ID (atau transaction ID) supaya mesin sinkron bisa mengirimnya bersama dan commit semua atau biarkan semua tertunda.

Apakah Anda membangun sendiri atau di AppMaster, tujuannya sama: setiap perubahan dicatat sekali, diputar ulang dengan aman, dan dapat dijelaskan ketika sesuatu tidak cocok.

Aturan resolusi konflik yang mudah dijelaskan kepada pengguna

Konflik adalah hal biasa. Tujuannya bukan membuatnya mustahil, melainkan membuatnya jarang, aman, dan mudah dijelaskan saat terjadi.

Tentukan momen saat konflik terjadi: aplikasi mengirim perubahan, dan server bilang, “Rekaman ini bukan versi yang Anda mulai edit.” Inilah mengapa versioning penting.

Simpan dua nilai dengan setiap rekaman:

• Versi server (versi saat ini di server)
• Versi yang diharapkan (versi yang ponsel kira sedang diedit)

Jika versi yang diharapkan cocok, terima update dan naikkan versi server. Jika tidak, terapkan aturan konflik Anda.

Pilih aturan per tipe data (jangan satu aturan untuk semua)

Data berbeda butuh aturan berbeda. Field status tidak sama dengan catatan panjang.

Aturan yang mudah dipahami pengguna:

• Last write wins: cocok untuk field risiko rendah seperti preferensi tampilan.
• Gabungkan field: terbaik saat field bersifat independen (status vs catatan).
• Tanya pengguna: terbaik untuk edit berisiko tinggi seperti harga, izin, atau total.
• Server menang dengan salinan: simpan nilai server, tapi simpan edit pengguna sebagai draf yang bisa dia terapkan ulang.

Di AppMaster, aturan ini mudah dipetakan ke logika visual: cek versi, bandingkan field, lalu pilih jalur.

Tentukan bagaimana penghapusan berperilaku (atau Anda akan kehilangan data)

Hapus adalah kasus rumit. Gunakan tombstone (penanda “dihapus”) daripada menghapus rekaman langsung. Lalu tentukan apa yang terjadi jika seseorang mengedit rekaman yang dihapus di tempat lain.

Aturan yang jelas: “Hapus menang, tapi bisa dikembalikan.” Contoh: seorang sales mengedit catatan pelanggan offline, sementara admin menghapus pelanggan itu. Saat sinkron, aplikasi menunjukkan “Pelanggan dihapus. Pulihkan untuk menerapkan catatan Anda?” Ini menghindari kehilangan diam-diam dan tetap memberi kontrol ke pengguna.

Retry dan status gagal: buat terduga

Saat sinkron gagal, kebanyakan pengguna tidak peduli kenapa. Mereka peduli apakah pekerjaan mereka aman dan apa yang akan terjadi selanjutnya. Model status yang dapat diprediksi mencegah panik dan tiket dukungan.

Mulai dengan model status yang kecil dan terlihat dan gunakan konsisten di seluruh layar:

• Queued: disimpan di perangkat, menunggu jaringan
• Syncing: sedang mengirim
• Sent: dikonfirmasi oleh server
• Failed: gagal dikirim, akan retry atau butuh perhatian
• Needs review: dikirim, tetapi server menolak atau menandainya

Retry harus hemat baterai dan data. Gunakan retry cepat di awal (untuk menangani pemutusan sinyal singkat), lalu perlambat. Backoff sederhana seperti 1 menit, 5 menit, 15 menit, lalu per jam mudah dipahami. Juga retry hanya ketika masuk akal (jangan terus mencoba mengirim perubahan yang invalid).

Perlakukan error secara berbeda, karena tindakan selanjutnya berbeda:

• Offline / tidak ada jaringan: tetap diantre, retry saat online
• Timeout / server tidak tersedia: tandai gagal, auto-retry dengan backoff
• Auth kadaluarsa: jeda sinkron dan minta pengguna masuk lagi
• Validasi gagal (input salah): butuh review, tunjukkan yang harus diperbaiki
• Konflik (rekaman berubah): butuh review, rujuk ke aturan konflik Anda

Idempoten adalah yang menjaga retry tetap aman. Setiap perubahan harus punya ID aksi unik (sering UUID) yang dikirim dengan permintaan. Jika aplikasi mengirim ulang perubahan yang sama, server harus mengenali ID itu dan mengembalikan hasil yang sama alih-alih membuat duplikat.

Contoh: seorang teknisi menyimpan pekerjaan selesai saat offline, lalu masuk lift. Aplikasi mengirim update, time out, dan retry nanti. Dengan ID aksi, pengiriman kedua tidak berbahaya. Tanpa itu, Anda mungkin membuat event “selesai” duplikat.

Di AppMaster, perlakukan status dan aturan ini sebagai field dan logika utama dalam proses sinkron Anda, sehingga aplikasi Kotlin dan SwiftUI berperilaku sama di mana pun.

UX perubahan tertunda: apa yang pengguna lihat dan bisa lakukan

Orang harus merasa aman menggunakan aplikasi offline. UX “perubahan tertunda” yang baik tenang dan dapat diprediksi: mengakui pekerjaan tersimpan di perangkat, dan membuat langkah selanjutnya jelas.

Indikator halus bekerja lebih baik daripada banner peringatan. Misalnya, tampilkan ikon kecil “Menyinkron” di header, atau label tenang “3 tertunda” pada layar tempat edit terjadi. Gunakan warna mencolok hanya untuk bahaya nyata (seperti “tidak bisa unggah karena Anda logout”).

Berikan satu tempat agar pengguna memahami apa yang terjadi. Outbox sederhana atau layar Perubahan tertunda bisa mencantumkan item dengan bahasa biasa seperti “Komentar ditambahkan ke Tiket 104” atau “Foto profil diperbarui.” Transparansi itu mencegah panik dan mengurangi tiket dukungan.

Apa yang bisa dilakukan pengguna

Kebanyakan orang hanya perlu beberapa aksi, dan harus konsisten di seluruh aplikasi:

• Retry sekarang
• Edit lagi (membuat perubahan baru)
• Buang perubahan lokal
• Salin detail (berguna saat melaporkan masalah)

Jaga label status sederhana: Pending, Syncing, Failed. Saat sesuatu gagal, jelaskan seperti orang: “Gagal mengunggah. Tidak ada internet.” atau “Ditolak karena rekaman ini diubah orang lain.” Hindari kode error.

Jangan blokir seluruh aplikasi

Hanya blokir aksi yang benar-benar membutuhkan koneksi, seperti “Bayar dengan Stripe” atau “Undang pengguna baru.” Semua lainnya harus tetap bekerja, termasuk melihat data terbaru dan membuat draf baru.

Alur realistis: teknisi lapangan mengedit laporan kerja di basement. Aplikasi menampilkan “1 tertunda” dan membiarkan mereka terus bekerja. Nanti berubah menjadi “Menyinkron,” lalu hilang otomatis. Jika gagal, laporan kerja tetap tersedia, ditandai “Gagal,” dengan satu tombol “Retry sekarang.”

Jika Anda membangun di AppMaster, modelkan status ini sebagai bagian dari setiap rekaman (pending, failed, synced) supaya UI bisa merefleksikannya di mana-mana tanpa layar kasus khusus.

Auth, izin, dan keamanan saat offline

Mode offline mengubah model keamanan Anda. Pengguna bisa melakukan aksi tanpa koneksi, tetapi server tetap sumber kebenaran. Anggap setiap perubahan yang diantre sebagai “diminta,” bukan “disetujui.”

Kadaluarsa login saat offline

Token kedaluwarsa. Saat itu terjadi offline, biarkan pengguna tetap membuat edit dan simpan sebagai tertunda. Jangan pura-pura aksi yang memerlukan konfirmasi server sudah selesai. Tandai mereka sebagai tertunda sampai refresh auth berhasil.

Saat aplikasi online lagi, coba silent refresh dulu. Jika harus meminta pengguna masuk kembali, lakukan sekali, lalu lanjutkan sinkron otomatis.

Setelah re-login, validasi ulang setiap item yang diantre sebelum mengirimnya. Identitas pengguna mungkin berubah (perangkat bersama), dan edit lama tidak boleh tersinkron di bawah akun yang salah.

Perubahan izin dan aksi terlarang

Izin bisa berubah saat pengguna offline. Edit yang diizinkan kemarin mungkin dilarang hari ini. Tangani ini secara eksplisit:

• Periksa ulang izin server-side untuk setiap aksi yang diantre
• Jika dilarang, hentikan item itu dan tunjukkan alasan jelas
• Simpan edit lokal pengguna agar mereka bisa menyalinnya atau meminta akses
• Hindari retry berulang untuk error “forbidden”

Contoh: seorang agen support mengedit catatan pelanggan offline di pesawat. Semalam, perannya dihapus. Saat sinkron berjalan, server menolak update. Aplikasi harus menunjukkan “Tidak bisa mengunggah: Anda tidak lagi memiliki akses” dan menyimpan catatan sebagai draf lokal.

Data sensitif yang disimpan offline

Simpan seminimal mungkin untuk merender layar dan memutar ulang antrean. Enkripsi penyimpanan offline, hindari caching rahasia, dan tetapkan aturan jelas untuk logout (misalnya: hapus data lokal, atau simpan draf hanya setelah persetujuan eksplisit pengguna). Jika Anda membangun dengan AppMaster, mulai dari modul autentikasinya dan rancang antrean sehingga selalu menunggu sesi valid sebelum mengirim perubahan.

Perangkap umum yang menyebabkan kehilangan kerja atau rekaman duplikat

Sebagian besar bug offline bukan yang rumit. Mereka berasal dari beberapa keputusan kecil yang terasa aman saat Anda menguji dengan Wi‑Fi sempurna, lalu merusak kerja nyata kemudian.

Satu kegagalan umum adalah overwrite diam-diam. Jika aplikasi mengunggah versi lama dan server menerimanya tanpa cek, Anda bisa menghapus edit yang lebih baru dan tidak ada yang sadar sampai terlambat. Sinkronkan dengan nomor versi (atau cap waktu last updated) dan tolak menimpa saat server sudah maju, sehingga pengguna mendapat pilihan jelas.

Perangkap lain adalah badai retry. Saat ponsel mendapat kembali koneksi lemah, aplikasi bisa membombardir backend setiap beberapa detik, menguras baterai dan membuat penulisan duplikat. Retry harus tenang: perlambat setelah setiap kegagalan dan tambahkan sedikit randomness supaya ribuan perangkat tidak retry bersamaan.

Kesalahan yang paling sering menyebabkan kehilangan kerja atau duplikasi:

• Menganggap setiap kegagalan seperti “network”: pisahkan error permanen (data invalid, izin hilang) dari sementara (timeout).
• Menyembunyikan kegagalan sinkron: jika orang tidak melihat apa yang gagal, mereka mengulang tugas dan membuat dua rekaman.
• Mengirim perubahan yang sama dua kali tanpa proteksi: selalu lampirkan request ID unik supaya server bisa mengenali dan mengabaikan duplikat.
• Menggabungkan otomatis field teks tanpa memberi tahu siapa pun: jika Anda menggabungkan edit, biarkan pengguna meninjau hasil ketika penting.
• Membuat rekaman offline tanpa ID stabil: gunakan ID lokal sementara dan peta ke ID server setelah upload, supaya edit berikutnya tidak membuat salinan kedua.

Contoh cepat: teknisi lapangan membuat “Kunjungan Situs” baru offline, lalu mengeditnya dua kali sebelum tersambung. Jika panggilan create di-retry dan membuat dua rekaman server, edit selanjutnya mungkin menempel pada yang salah. ID stabil dan deduplikasi server mencegah ini.

Jika Anda membangun ini dengan AppMaster, aturannya tidak berubah. Bedanya adalah di mana Anda mengimplementasikannya: di logika sinkron, model data, dan layar yang menampilkan “gagal” vs “terkirim.”

Skenario contoh: dua orang mengedit rekaman yang sama

Seorang teknisi lapangan, Maya, memperbarui tiket “Pekerjaan #1842” di basement tanpa sinyal. Dia mengubah status dari “In progress” ke “Completed” dan menambahkan catatan: “Ganti katup, tes OK.” Aplikasi menyimpan seketika dan menampilkannya sebagai tertunda.

Di atas, rekannya Leo online dan mengedit tiket yang sama pada waktu bersamaan. Dia mengubah waktu jadwal dan menetapkan pekerjaan ke teknisi lain, karena pelanggan menelepon update.

Saat Maya mendapat sinyal, sinkron latar belakang mulai diam-diam. Inilah yang terjadi dalam alur yang dapat diprediksi dan ramah pengguna:

1. Perubahan Maya masih di antrean sinkron (ID pekerjaan, field yang diubah, cap waktu, dan versi rekaman yang terakhir dia lihat).
2. Aplikasi mencoba mengunggah. Server menjawab: “Pekerjaan ini telah diperbarui sejak versi Anda” (konflik).
3. Aturan konflik Anda berjalan: status dan catatan bisa digabung, tetapi perubahan penugasan dimenangkan jika dibuat lebih baru di server.
4. Server menerima hasil gabungan: status = “Completed” (dari Maya), catatan ditambahkan (dari Maya), teknisi yang ditugaskan = pilihan Leo (dari Leo).
5. Pekerjaan muncul kembali di aplikasi Maya dengan banner jelas: “Tersinkron dengan pembaruan. Penugasan berubah saat Anda offline.” Aksi kecil “Tinjau” menunjukkan apa yang berubah.

Sekarang tambahkan satu momen kegagalan: token login Maya kedaluwarsa saat dia offline. Upaya sinkron pertama gagal dengan “Perlu masuk.” Aplikasi menyimpan edit-nya, menandainya sebagai “Jeda,” dan menampilkan satu prompt sederhana. Setelah dia masuk lagi, sinkron dilanjutkan otomatis tanpa mengetik ulang apa pun.

Jika ada masalah validasi (misalnya, status “Completed” membutuhkan foto), aplikasi tidak boleh menebak. Tandai item sebagai “Perlu perhatian,” katakan persis apa yang harus ditambahkan, lalu biarkan dia kirim ulang.

Platform seperti AppMaster membantu karena Anda bisa merancang antrean, aturan konflik, dan UX status tertunda secara visual, sambil tetap menghasilkan aplikasi native Kotlin dan SwiftUI nyata.

Checklist cepat dan langkah berikutnya

Anggap sinkronisasi offline sebagai fitur ujung-ke-ujung yang bisa Anda uji, bukan kumpulan perbaikan. Tujuannya sederhana: pengguna tidak pernah bertanya apakah pekerjaannya tersimpan, dan aplikasi tidak membuat duplikat mengejutkan.

Checklist singkat untuk memastikan fondasi kuat:

• Antrean sinkron disimpan di perangkat, dan setiap perubahan punya ID lokal stabil plus ID server saat tersedia.
• Status jelas ada (queued, syncing, sent, failed, needs review) dan digunakan konsisten.
• Permintaan idempoten (aman untuk retry), dan setiap operasi menyertakan kunci idempoten.
• Rekaman memiliki versioning (updatedAt, nomor revisi, atau ETag) sehingga konflik bisa dideteksi.
• Aturan konflik ditulis dengan bahasa sederhana (apa yang menang, apa yang digabung, kapan menanyakan pengguna).

Setelah itu siap, verifikasi pengalaman sama kuatnya dengan model data. Pengguna harus bisa melihat apa yang tertunda, memahami apa yang gagal, dan mengambil tindakan tanpa takut kehilangan pekerjaan.

Uji dengan skenario yang cocok dengan kehidupan nyata:

• Mode pesawat: buat, perbarui, hapus, lalu sambungkan kembali.
• Jaringan fluktuatif: putus di tengah sinkron dan pastikan retry tidak menduplikasi.
• Aplikasi dibunuh: tutup paksa saat mengirim, buka lagi, konfirmasi antrean pulih.
• Perbedaan waktu: waktu perangkat salah, konfirmasi deteksi konflik tetap bekerja.
• Ketukan ganda: pengguna tekan Simpan dua kali, pastikan jadi satu perubahan server.

Prototipe alur penuh sebelum memoles UI. Bangun satu layar, satu tipe rekaman, dan satu kasus konflik (dua edit pada field yang sama). Tambahkan area status sinkron sederhana, tombol Retry untuk kegagalan, dan satu layar konflik yang jelas. Saat itu bekerja, ulangi untuk layar lain.

Jika Anda membangun tanpa coding, AppMaster (appmaster.io) dapat menghasilkan aplikasi native Kotlin dan SwiftUI bersamaan dengan backend, sehingga Anda bisa fokus pada antrean, pengecekan versi, dan status yang terlihat pengguna daripada menyambungkan semuanya sendiri.