BAST System — Digitalisasi Bantuan Pemerintah (Flutter)

Overview

BAST (Berita Acara Serah Terima) System adalah aplikasi mobile berbasis Flutter yang mendigitalisasi seluruh rantai proses bantuan pemerintah di lingkup perikanan. Aplikasi ini mencakup:

- CPCL (Catatan Pemeriksaan Calon Lokasi): Formulir inspeksi lapangan multi-langkah yang dinamis dengan config-driven wizard engine - Procurement & Delivery: Manajemen pengadaan, tracking pengiriman real-time, dan update status logistik - Handover/BAST: Pembuatan dan manajemen dokumen berita acara serah terima secara digital - Inspection Reports: Laporan inspeksi barang dan quality control - Role-Based Access: Antarmuka terpisah untuk Internal Team (Surveyor/PPK) dan Vendor - Offline Capability: Caching lokal dengan Hive untuk area dengan sinyal terbatas - OTA Update: Distribusi update langsung via Firebase Remote Config + GitHub Releases

Aplikasi ini sudah digunakan dalam proses bisnis nyata pemerintah untuk digitalisasi bantuan perikanan.

Tech & Libraries

Teknologi dan library yang dipakai atau disentuh di project ini:

Problem

Proses bantuan pemerintah di bidang perikanan sebelumnya masih bersifat manual dan paper-based. Beberapa masalah utama:

1. Data survei lapangan (CPCL) tersebar di dokumen fisik, sulit dilacak dan divertifikasi
2. Proses pengadaan dan pengiriman barang bantuan tidak terpantau secara real-time
3. Dokumen serah terima aset (BAST) masih berupa kertas yang rawan rusak/hilang
4. Tidak ada pemisahan akses yang jelas antara tim internal (Surveyor/PPK) dan vendor eksternal
5. Area survei sering berada di lokasi dengan sinyal terbatas, menyulitkan input data online

Dibutuhkan aplikasi mobile yang bisa bekerja offline, memiliki role-based access, dan mendigitalisasi seluruh alur dari survei hingga serah terima.

My Role & Ownership

Flutter Developer: implementasi fitur CPCL wizard, delivery tracking, handover/BAST, inspection reports, dashboard analytic, dan OTA update system.

Technical Approach

Technical Approach:

Aplikasi dibangun dengan Flutter menggunakan Clean Architecture feature-first — setiap fitur (Auth, CPCL, Delivery, Handover, Inspection, dll) memiliki struktur BLoC, data, domain, dan UI sendiri.

Stack utama: - Flutter + Dart untuk cross-platform mobile (Android/iOS) - BLoC/Cubit untuk state management dengan separation of concerns yang jelas - GoRouter untuk declarative routing dengan role-based navigation guard - Dio untuk networking dengan interceptor pattern (logging, auth, error handling) - Hive untuk local database dan offline caching - GetIt untuk service locator / dependency injection - Firebase Cloud Messaging untuk push notification - Firebase Remote Config untuk OTA update mechanism - Geolocator + FlutterMap untuk deteksi lokasi dan peta

Flow implementasi:

1. Auth: Login → OTP Verification → Role Check → Route Guard → Dashboard sesuai role
2. CPCL: List CPCL → Wizard Form (multi-step config-driven) → Detail → Submit
3. Delivery: Procurement List → Delivery Tracking → Update Status → Upload Bukti
4. Handover: List BAST → Detail → Create BAST → Generate Dokumen

Setiap layer presentation menggunakan BLoC pattern: Event → Bloc → State → UI rebuild.

Architecture Notes

Struktur sistem mengikuti Clean Architecture dengan feature-first directory:

1. Core Layer — shared utilities, configs, theme, router, network client (Dio), services (notification, geolocator, storage)
2. Presentation/Features — setiap fitur memiliki struktur: - bloc/: State management (Cubit/Bloc) - data/: Data sources (remote API + local Hive), models, repositories - domain/: Entities, use cases, repository interfaces - ui/: Pages dan widgets

Data flow: - Remote: Dio Client → API Service → Remote DataSource → Repository → Bloc → UI - Local: Hive Box → Local DataSource → Repository → Bloc → UI - Offline: Data di-cache ke Hive saat online, dibaca dari Hive saat offline

Routing: - GoRouter dengan ShellRoute untuk bottom navigation - Route guard berdasarkan role (Internal vs Vendor) - Redirect ke login jika token expired

State management: - BLoC untuk fitur kompleks (CPCL wizard, delivery tracking) - Cubit untuk fitur sederhana (auth, profile)

Trade-offs

Keputusan arsitektur kunci:

1. Feature-first vs Layer-first — Feature-first dipilih agar setiap fitur bisa dikembangkan secara independen oleh anggota tim berbeda. Konsekuensinya: ada duplikasi kode antar fitur, tapi isolasi lebih baik.

1. BLoC vs Riverpod/Provider — BLoC dipilih karena pattern-nya yang strict (Event → State) cocok untuk aplikasi government dengan flow yang kompleks dan perlu traceability. Konsekuensinya: boilerplate lebih banyak dibanding Riverpod.

1. Hive vs SQLite — Hive dipilih untuk offline caching karena zero dependency native, super cepat (NoSQL), dan API yang sederhana. Trade-off: tidak support query kompleks seperti SQLite.

1. Config-Driven Form Wizard — Engine form CPCL dibuat dinamis berbasis konfigurasi JSON, bukan hardcode per step. Memungkinkan perubahan form tanpa rebuild aplikasi. Konsekuensinya: kompleksitas engine lebih tinggi di awal.

1. GoRouter vs Navigator 2.0 — GoRouter dipilih karena declarative, support deep linking, dan lebih mudah untuk role-based route guard.

Implementation Highlights

• Config-driven form wizard engine untuk CPCL multi-step inspection
• Role-based routing dengan GoRouter (Internal vs Vendor)
• Offline-first architecture dengan Hive caching
• OTA update mechanism via Firebase Remote Config + GitHub Releases
• Integrasi Firebase Cloud Messaging untuk push notification
• Geolocation + FlutterMap untuk deteksi lokasi lapangan
• Clean Architecture feature-first dengan BLoC state management
• Dio interceptor pattern untuk auth, logging, dan error handling

Results

• Aplikasi Flutter production untuk digitalisasi bantuan pemerintah di bidang perikanan — dari survei lapangan (CPCL), pengadaan, logistik, hingga serah terima aset (BAST) dengan offline capability dan role-based access.
• Aplikasi production yang digunakan dalam proses bisnis nyata pemerintah untuk digitalisasi bantuan perikanan
• Berhasil mendigitalisasi alur dari survei lapangan (CPCL) hingga serah terima aset (BAST)
• Config-driven form wizard yang memungkinkan perubahan form tanpa rebuild aplikasi
• Role-based access dengan antarmuka terpisah untuk internal team dan vendor
• Offline-first architecture dengan Hive caching untuk area dengan sinyal terbatas
• OTA update mechanism via Firebase Remote Config + GitHub Releases untuk distribusi langsung ke user
• Aplikasi production untuk proses bisnis pemerintah
• Multi-step config-driven form wizard
• Role-based access (Internal + Vendor)
• Offline capability dengan Hive caching
• OTA update tanpa Play Store