Modul penutup jalur ini diawali oleh satu keputusan yang menentukan seluruh isinya, yaitu aplikasi apa yang dibangun sebagai proyek akhir. Topik ini menetapkan kriteria pemilihannya, membandingkan tiga kandidat secara ringkas, menetapkan aplikasi catatan sebagai pilihannya beserta alasannya, lalu membatasi lingkup minimum beserta hal yang sengaja dikeluarkan. Setelah topik ini, setiap keputusan teknis dalam modul penutup ini memiliki pijakan yang jelas.
Kriteria pemilihan proyek akhir#
Proyek akhir yang baik bukan aplikasi terbesar, melainkan aplikasi yang memaksa seluruh konsep jalur ini bekerja bersamaan. Empat kriteria berikut digunakan untuk menilai setiap kandidat, dan satu kandidat dianggap layak hanya apabila memenuhi keempatnya.
- Autentikasi. Aplikasi memiliki pintu masuk yang memeriksa identitas pengguna, sehingga materi permintaan HTTP dan penanganan responsnya terpakai pada kasus yang nyata.
- Data yang berubah. Isi aplikasi bertambah dan berubah selama aplikasi digunakan, sehingga pengelolaan state, pembaruan tampilan, dan penyimpanan ikut teruji. Aplikasi yang datanya statis tidak pernah mempraktikkan bagian tersebut.
- Toleransi offline. Aplikasi tetap berguna ketika jaringan hilang, misalnya data terakhir masih tampil dan perubahan baru tetap tersimpan. Kriteria ini menuntut keputusan tentang sumber data dan urutan pemuatannya.
- Lingkup realistis. Fitur inti selesai dalam hitungan hari kerja, bukan minggu, sehingga proyek benar-benar tuntas beserta pengujinya.
Kriteria autentikasi dan toleransi offline sengaja dijadikan syarat karena keduanya jarang muncul pada latihan pendek, padahal hampir semua aplikasi sehari-hari memiliki keduanya. Data yang berubah menjadi syarat agar state tingkat aplikasi, yaitu materi package Provider, dipraktikkan pada data yang benar-benar berubah. Lingkup realistis menjaga modul penutup ini berhenti pada aplikasi yang selesai, bukan pada kerangka setengah jadi.
Membandingkan tiga kandidat#
Tiga kandidat yang netral dan non-komersial dinilai menggunakan kriteria yang sama, yaitu aplikasi catatan, pelacak kebiasaan, dan pembukuan jadwal piket. Tabel berikut merangkum perbandingannya per kriteria.
| Kriteria | Aplikasi catatan | Pelacak kebiasaan | Pembukuan jadwal piket |
|---|---|---|---|
| Autentikasi | wajar, catatan bersifat pribadi | jarang dibutuhkan pada penggunaan tunggal | perlu, tetapi menuntut peran banyak pengguna |
| Data yang berubah | sering, setiap catatan baru mengubah daftar | cukup, satu tanda per hari | jarang, satu kali per minggu |
| Toleransi offline | wajib, catatan dibuka di mana saja | berguna, tetapi datanya kecil | berguna, tetapi jadwal dibaca sesekali |
| Lingkup realistis | beberapa layar dan dua tempat penyimpanan | perlu grafik agar bernilai | relasi jadwal dan orang memperluas lingkup |
Aplikasi catatan memenuhi keempat kriteria tanpa satu pun fitur yang dipaksakan. Autentikasi masuk akal karena catatan milik satu pengguna. Datanya berubah setiap kali catatan baru ditulis, ketiadaan jaringan justru merupakan momen ketika catatan dibutuhkan, dan model datanya kecil dengan hanya beberapa kolom seperti judul, isi, dan waktu pengubahannya.
Dua kandidat lainnya gugur karena alasan yang berbeda. Pelacak kebiasaan memiliki nilai utama pada statistik dan grafik streak, yaitu rangkaian hari berturut-turut kebiasaan dijalankan, dan bagian itulah yang memperluas lingkup melampaui materi jalur ini, sedangkan autentikasinya terasa ditempelkan pada aplikasi satu pengguna. Pembukuan jadwal piket menyimpan data yang jarang berubah dan menuntut relasi antarpengguna beserta aturan gilir piket, sehingga model datanya berkembang melampaui waktu yang tersedia.
Lingkup minimum yang layak#
Lingkup minimum adalah daftar fitur terpendek yang masih menghasilkan aplikasi utuh dan menguji seluruh materi jalur. Tabel berikut menyandingkan setiap kebutuhan dengan fitur yang dipilih serta konsep jalur yang dirangkainya.
| Kebutuhan | Fitur yang dipilih | Konsep jalur yang dirangkai |
|---|---|---|
| menyimpan catatan milik satu pengguna | autentikasi sederhana dengan nama pengguna dan sandi | permintaan HTTP, Future, penanganan error |
| melihat isi yang sudah ada | layar daftar catatan | ListView, FutureBuilder, Provider |
| menambah dan memperbaiki isi | layar ubah dengan form | Form, validator, TextEditingController |
| tetap terbaca tanpa jaringan | simpan lokal pada perangkat | shared_preferences, jsonEncode |
| perangkat lain melihat perubahan | sinkronisasi ke API | permintaan POST, model dengan toJson |
Lima fitur ini menjadi ukuran tuntasnya proyek. Setiap fitur menguji satu kelompok konsep dan tidak ada fitur pengisi, yaitu fitur yang hanya memperpanjang daftar tanpa materi baru. Apabila satu fitur sudah berjalan dan teruji, proyek berpindah ke fitur berikutnya, dan urutannya mengikuti urutan baris pada tabel di atas.
Yang sengaja di luar lingkup#
Batasan lingkup hanya bermakna apabila hal yang dikeluarkan dinyatakan secara eksplisit. Tiga hal berikut sengaja tidak dibangun pada proyek ini.
- Notifikasi pengingat, karena menuntut integrasi platform yang berada di luar materi inti jalur.
- Kolaborasi banyak pengguna pada satu catatan, karena memunculkan persoalan konflik data dan izin akses yang layak menjadi proyek tersendiri.
- Tema kustom pilihan pengguna, karena theming sudah dibahas sebagai penyempurnaan tampilan dan tidak mengubah perilaku inti aplikasi.
Pernyataan batasan ini bukan penilaian bahwa fitur-fitur tersebut tidak bernilai. Ketiganya justru lazim ditemukan pada aplikasi sehari-hari, tetapi memasukkannya sekarang mengaburkan titik tuntas proyek akhir. Daftar ini sekaligus menjadi catatan kerja lanjutan yang realistis setelah jalur ini selesai.
Ringkasan#
- Empat kriteria pemilihan proyek akhir adalah autentikasi, data yang berubah, toleransi offline, dan lingkup realistis.
- Aplikasi catatan terpilih dari tiga kandidat karena memenuhi keempat kriteria tanpa fitur yang dipaksakan, sedangkan pelacak kebiasaan meluas ke statistik dan pembukuan jadwal piket meluas ke relasi antarpengguna.
- Lingkup minimumnya adalah daftar catatan, tambah dan ubah, autentikasi sederhana, simpan lokal, serta sinkronisasi ke API.
- Notifikasi, kolaborasi, dan tema kustom pengguna dinyatakan di luar lingkup agar proyek benar-benar selesai dan teruji.
Referensi#
- Architecting Flutter apps — Flutter — Panduan resmi menyusun arsitektur aplikasi Flutter, termasuk pemisahan lapisan data dan tampilan yang menjadi dasar lingkup proyek ini.
- Flutter learning pathway — Flutter — Rangkaian codelab resmi yang menjadi ukuran realistis untuk besaran sebuah proyek awal.