Background Task Processing di Flutter dengan WorkManager: Sinkronisasi Data Secara Periodik

Background task processing adalah salah satu tantangan terbesar dalam pengembangan aplikasi mobile modern. Sistem operasi seperti Android memiliki mekanisme agresif untuk menghentikan proses aplikasi saat berada di latar belakang demi menghemat baterai dan resource. WorkManager dari Android Jetpack hadir sebagai solusi resmi yang menjamin eksekusi task tetap berjalan meskipun aplikasi ditutup atau perangkat di-restart. Di Flutter, package workmanager membawa kemampuan ini ke ekosistem Dart, memungkinkan kita menjadwalkan task periodik secara deklaratif dan terintegrasi dengan platform native.

Mengapa Background Task Diperlukan di Aplikasi Mobile Modern

Aplikasi mobile modern tidak bisa hanya mengandalkan eksekusi saat pengguna aktif. Beberapa skenario membutuhkan proses latar belakang: menyimpan draft laporan otomatis, mengunggah log error ke server, atau menarik data cuaca terbaru setiap jam. Tanpa background task, pengguna harus membuka aplikasi secara manual setiap kali ingin data terbaru — pengalaman yang tidak ideal dan menyebabkan data tidak sinkron antar perangkat.

Di ekosistem Android, terdapat beberapa pendekatan untuk menangani tugas latar belakang. Foreground service cocok untuk task yang membutuhkan notifikasi persisten seperti pemutar musik atau tracking lokasi. Alarm manager berguna untuk task berbasis waktu yang presisi seperti alarm pengingat. Namun WorkManager menawarkan keunggulan unik: task tetap dijadwalkan ulang secara otomatis setelah perangkat di-restart, mendukung constraint seperti koneksi internet atau status charging, dan mengelola siklus hidup task secara terjamin meskipun aplikasi di-terminate oleh sistem. WorkManager juga mematuhi kebijakan Doze Mode dan App Standby Android, sehingga tidak akan di-blokir oleh sistem seperti pendekatan lain yang lebih lama.

Package workmanager di Flutter juga mengabstraksi perbedaan platform dengan API seragam untuk Android dan iOS. Meskipun implementasi di balik layar menggunakan mekanisme native masing-masing — WorkManager di Android dan BGTaskScheduler di iOS — kita cukup menulis satu kode Dart yang bekerja di keduanya.

Arsitektur WorkManager: Task, Worker, dan Constraints

WorkManager memiliki tiga komponen inti. WorkRequest mendefinisikan bagaimana dan kapan task dijalankan — mencakup interval, constraint, dan kebijakan penjadwalan. Worker berisi logika bisnis yang akan dieksekusi. WorkManager instance bertanggung jawab menjadwalkan dan mengelola siklus hidup WorkRequest, termasuk menangani kegagalan, restart perangkat, dan konflik penjadwalan.

Gambar: Alur kerja WorkManager — aplikasi mendaftarkan task, WorkManager memvalidasi constraint dan menyimpannya di Room Database, Scheduler memilih executor yang sesuai, WorkerFactory menginstansiasi Worker, lalu Worker menjalankan logika bisnis. — Sumber: [Droidly](https://droidly.io/concept_workmanager.html)

Terdapat dua jenis WorkRequest: OneTimeWorkRequest untuk task sekali jalan (misalnya mengunggah data saat tombol sync ditekan), dan PeriodicWorkRequest untuk task berulang. Untuk sinkronisasi data, kita menggunakan PeriodicWorkRequest dengan interval minimal 15 menit — batasan Android untuk mengoptimalkan baterai. Interval ini berarti task dijalankan dalam jendela waktu 15 menit, bukan tepat setiap 15 menit. Sistem dapat menunda eksekusi berdasarkan kondisi perangkat seperti Doze Mode.

WorkRequest juga mendukung Constraints — kondisi tambahan yang harus dipenuhi sebelum task dijalankan. Misalnya, task hanya berjalan saat perangkat terhubung ke internet (NetworkType.connected), saat di-charge (requiresCharging: true), atau saat baterai tidak lemah (requiresBatteryNotLow: true). Kombinasi constraint ini memungkinkan strategi sinkronisasi yang cerdas dan tidak mengganggu pengalaman pengguna.

import 'package:workmanager/workmanager.dart';

const String syncTaskName = 'periodicDataSync';

@pragma('vm:entry-point')
void callbackDispatcher() {
  Workmanager().executeTask((task, inputData) async {
    switch (task) {
      case syncTaskName:
        await performDataSync();
        break;
    }
    return Future.value(true);
  });
}

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Workmanager().initialize(callbackDispatcher);

  await Workmanager().registerPeriodicTask(
    syncTaskName,
    syncTaskName,
    frequency: Duration(minutes: 15),
    constraints: Constraints(
      networkType: NetworkType.connected,
      requiresCharging: false,
      requiresBatteryNotLow: true,
    ),
    existingWorkPolicy: ExistingWorkPolicy.replace,
    backoffPolicy: BackoffPolicy.linear,
    backoffPolicyDelay: Duration(seconds: 10),
  );

  runApp(MyApp());
}

Perhatikan bahwa callbackDispatcher didekorasi dengan @pragma('vm:entry-point') agar Flutter engine tetap mengenali fungsi ini sebagai entry point terpisah saat aplikasi berjalan di background. ExistingWorkPolicy.replace memastikan jadwal task lama diganti dengan yang baru ketika registerPeriodicTask dipanggil kembali. Parameter backoffPolicy memungkinkan kita mengontrol strategi percobaan ulang: BackoffPolicy.linear memberikan jeda tetap, sementara BackoffPolicy.exponential meningkatkan jeda secara eksponensial untuk menghindari banjir request saat error berkelanjutan.

Gambar: Siklus lengkap sinkronisasi periodik — dari pendaftaran task, pengecekan constraint (network, baterai), eksekusi worker yang membaca data dari local storage dan mengirim ke server, hingga penanganan sukses (notifikasi) dan gagal (retry dengan exponential backoff). — Sumber: [Droidly](https://droidly.io/concept_workmanager.html)

Implementasi Sinkronisasi Data ke Backend secara Periodik

Setelah Worker terdaftar, langkah berikutnya adalah mengisi logika sinkronisasi yang sebenarnya. Worker kita perlu membaca data yang belum tersinkronisasi dari local storage, mengirimnya ke REST API, dan mengembalikan hasil berupa sukses atau gagal. Berikut adalah implementasi lengkap dengan error handling dan notifikasi:

@pragma('vm:entry-point')
void callbackDispatcher() {
  Workmanager().executeTask((task, inputData) async {
    switch (task) {
      case syncTaskName:
        try {
          final localData = await LocalStorage().getPendingData();

          if (localData.isEmpty) {
            return true;
          }

          final response = await http.post(
            Uri.parse('https://api.example.com/sync'),
            headers: {'Content-Type': 'application/json'},
            body: jsonEncode({'data': localData, 'batch_id': uuid.v4()}),
          );

          if (response.statusCode == 200) {
            await LocalStorage().markAsSynced(localData);
            await NotificationService().showSuccessNotification(
              'Sinkronisasi berhasil: ${localData.length} item',
            );
            return true;
          }

          if (response.statusCode >= 500) {
            return false;
          }

          return true;
        } catch (e) {
          if (e is SocketException || e is TimeoutException) {
            return false;
          }
          return true;
        }
    }
    return true;
  });
}

Fokus pada flow di atas: Worker membaca data yang belum tersinkronisasi dari local storage. Jika tidak ada data, Worker mengembalikan true (dianggap sukses — tidak ada pekerjaan). Jika ada data, Worker mengirim POST request ke endpoint API dengan batch ID unik untuk mencegah duplikasi di sisi server. Ketika response sukses (200), data di local storage ditandai sebagai tersinkronisasi dan notifikasi dikirim ke pengguna.

WorkManager secara otomatis menerapkan backoff dan retry ketika Worker mengembalikan false. Backoff default menggunakan eksponensial dengan delay awal 30 detik, sehingga percobaan ulang semakin jarang seiring waktu. Strategi ini mencegah banjir request ke server saat error sementara seperti network timeout. Error seperti SocketException dan TimeoutException memicu retry, sementara error lain seperti parsing error langsung dianggap final — menghindari retry yang tidak berguna.

Notifikasi lokal penting untuk memberikan feedback ke pengguna: saat sukses, jumlah item yang berhasil dikirim ditampilkan; saat gagal, notifikasi memberi tahu bahwa sistem akan mencoba ulang secara otomatis. Transparansi semacam ini membangun kepercayaan pengguna terhadap aplikasi kita.

Mengelola Konflik Data saat Sinkronisasi

Sinkronisasi periodik membawa tantangan: bagaimana jika data berubah di lokal antara satu periode dengan periode berikutnya? Konflik data adalah realitas yang harus ditangani. Tanpa strategi resolusi yang tepat, data pengguna bisa hilang atau tertimpa secara tidak sengaja.

Pendekatan yang paling umum adalah Last-Write-Wins menggunakan timestamp. Setiap data yang dikirim dari perangkat menyertakan timestamp perubahan terakhir, dan server membandingkannya dengan versi yang sudah ada.

Gambar: Mekanisme Last-Write-Wins — dua perangkat mengirim data dengan timestamp berbeda, server membandingkan timestamp dan memilih data dengan nilai timestamp tertinggi sebagai pemenang, sementara data lama ditimpa (silent data loss). — Sumber: [OneUptime](https://oneuptime.com/blog/post/2026-01-30-last-write-wins/view)

Berikut implementasi conflict resolution yang lebih komprehensif:

class SyncPayload {
  final String id;
  final Map<String, dynamic> data;
  final DateTime lastModified;
  final String deviceId;

  SyncPayload({
    required this.id,
    required this.data,
    required this.lastModified,
    required this.deviceId,
  });

  Map<String, dynamic> toJson() => {
    'id': id,
    'data': data,
    'last_modified': lastModified.toIso8601String(),
    'device_id': deviceId,
  };
}

Future<bool> syncWithConflictResolution() async {
  final pendingItems = await LocalStorage().getPendingData();

  for (final item in pendingItems) {
    final payload = SyncPayload(
      id: item.id,
      data: item.data,
      lastModified: item.updatedAt,
      deviceId: deviceId,
    );

    final response = await http.post(
      Uri.parse('https://api.example.com/sync'),
      body: jsonEncode(payload.toJson()),
    );

    if (response.statusCode == 409) {
      final serverData = jsonDecode(response.body);
      final serverTimestamp = DateTime.parse(serverData['last_modified']);

      if (serverTimestamp.isAfter(payload.lastModified)) {
        await LocalStorage().updateWithServerVersion(serverData['data']);
      } else {
        await http.put(
          Uri.parse('https://api.example.com/sync/${item.id}'),
          body: jsonEncode(payload.toJson()),
        );
      }
      continue;
    }

    if (response.statusCode == 200) {
      await LocalStorage().markAsSynced([item]);
    }
  }
  return true;
}

Endpoint API sebaiknya dirancang secara idempotent, artinya pengiriman data yang sama beberapa kali tidak akan merusak state di server. Idempotency dijamin dengan menggunakan lastModified timestamp sebagai referensi: jika timestamp yang dikirim lebih lama dari data server, request diabaikan. Dalam implementasi di atas, ketika konflik terdeteksi (status 409), perangkat membandingkan timestamp: jika server memiliki data lebih baru, perangkat memperbarui data lokalnya; jika data lokal lebih baru, perangkat mengirim ulang melalui PUT request.

WorkManager juga mendukung InputMerger untuk menggabungkan data dari beberapa task periodik berurutan. Fitur ini berguna jika aplikasi memiliki beberapa jenis sinkronisasi dengan interval berbeda — InputMerger memastikan tidak ada data yang hilang saat task diganti sebelum sempat dieksekusi.

Monitoring, Testing, dan Best Practices

WorkManager menyediakan API query untuk memantau status task. Kita bisa mengecek status task berjalan menggunakan tag yang ditetapkan saat registrasi:

Future<WorkStatus> checkSyncStatus() async {
  final workStatus = await Workmanager().getScheduledWork();

  for (final work in workStatus) {
    if (work.contains(syncTaskName)) {
      final workInfo = await Workmanager().getWorkById(work);
      return _mapToStatus(workInfo);
    }
  }

  return WorkStatus.unscheduled;
}

WorkStatus _mapToStatus(String? workInfo) {
  switch (workInfo) {
    case 'running':
      return WorkStatus.running;
    case 'enqueued':
      return WorkStatus.enqueued;
    case 'success':
      return WorkStatus.success;
    case 'failure':
      return WorkStatus.failed;
    case 'cancelled':
      return WorkStatus.cancelled;
    default:
      return WorkStatus.unscheduled;
  }
}

enum WorkStatus { running, enqueued, success, failed, cancelled, unscheduled }

API query ini memungkinkan kita menampilkan indikator status di UI — misalnya ikon sync berputar saat task berjalan, atau centang hijau saat sinkronisasi berhasil. Untuk debugging, Android Debug Bridge menyediakan flags khusus untuk WorkManager:

# Mengaktifkan logging verbose untuk WorkManager
adb shell setprop log.tag.WorkManager VERBOSE

# Membatalkan semua task WorkManager untuk debugging
adb shell am broadcast -a "androidx.work.action.DEBUG" -p com.yourapp.package

Beberapa best practices penting: interval 15 menit adalah batasan Android yang tidak bisa dihindari — sistem akan mengabaikan durasi lebih pendek. Gunakan tag deskriptif untuk mengelompokkan task, misalnya 'sync_data', 'upload_logs', 'refresh_cache'. Hindari blocking operation panjang di main isolate — meskipun Worker berjalan di isolate terpisah, prosesornya tetap dibatasi sistem untuk menghemat baterai. Untuk task lebih dari 10 menit, pertimbangkan ForegroundService yang memiliki prioritas lebih tinggi.

Testing worker secara unit dapat dilakukan dengan mensimulasikan kondisi koneksi dan data local storage menggunakan dependency injection. Pendekatan ini memudahkan kita mengganti implementasi data source dengan mock untuk skenario sukses, gagal, dan konflik, memastikan logika sinkronisasi berjalan benar di berbagai kondisi edge case.

Sinkronisasi data periodik dengan WorkManager adalah fondasi penting untuk aplikasi Flutter yang membutuhkan konsistensi data antara perangkat dan server. Ingin menguasai arsitektur background processing, state management, dan deployment Flutter ke Play Store? Bergabunglah dengan Mobile Development Bootcamp di Rumah Coding — kurikulum berbasis proyek nyata untuk membangun aplikasi Flutter production-grade.