Panduan navigasi SwiftUI langkah demi langkah ini membantu kamu memilih pola navigasi sebelum menulis baris kode pertama. Banyak aplikasi iOS berantakan karena alur perpindahan layar ditentukan sambil jalan, bukan karena desainnya buruk. Artikel ini membandingkan tiga pilihan utama dan menyusunnya dalam urutan kerja yang bisa langsung diterapkan.
Mulai dari model data, bukan dari tampilan
SwiftUI menurunkan navigasi dari state. Keputusan pertama adalah menentukan data apa yang mewakili sebuah layar, bukan memilih tampilan mana yang memakai NavigationLink. Jika setiap tujuan navigasi bisa dijelaskan sebagai nilai yang bisa disimpan (sebuah ID produk, enum langkah pendaftaran, atau struct filter), seluruh alur bisa direproduksi dari satu sumber kebenaran.
Buat tipe yang mewakili tujuan tersebut. Untuk aplikasi belanja, bentuknya bisa sesederhana ini:
enum Tujuan {
case detailProduk(id: String)
case keranjang
case pembayaran
}Dengan tipe ini, kamu tidak perlu menyimpan referensi ke view. Yang kamu simpan hanya deskripsi tujuan, dan SwiftUI yang membangun tampilannya. Pola ini juga memudahkan pemulihan state saat aplikasi dibuka ulang.
Membandingkan tiga pola navigasi
Ada tiga pola yang paling sering dipakai di aplikasi iOS modern. Ketiganya bisa hidup berdampingan, tetapi masing-masing punya kondisi ideal.
| Pola | Cocok untuk | Keterbatasan |
|---|---|---|
| NavigationStack | Alur bertingkat di iPhone, seperti daftar lalu detail | Kurang pas untuk tampilan lebar dengan dua panel |
| NavigationSplitView | iPad dan Mac dengan panel samping dan detail | Perlu penanganan tambahan saat layar menyempit |
| Sheet dan fullScreenCover | Alur pendek yang bisa dibatalkan, seperti formulir | Tidak punya riwayat mundur bertingkat |
Aturan praktisnya: gunakan NavigationStack untuk perpindahan yang ingin bisa dikembalikan satu per satu, NavigationSplitView ketika pengguna punya layar lebar, dan sheet untuk tugas terpisah yang tidak perlu masuk ke riwayat. Kalau kamu sudah nyaman mengatur state turunan, perbandingan pada cara mengelola state di SwiftUI akan membantu memutuskan di mana data navigasi sebaiknya disimpan.
Kapan NavigationSplitView lebih baik
Aplikasi yang berjalan di iPad dan Mac sebaiknya memulai dari NavigationSplitView. Pengguna di layar lebar mengharapkan daftar kategori tetap terlihat sementara detail berubah di sisi kanan. NavigationStack di layar selebar itu menyisakan ruang kosong dan memaksa pengguna menekan tombol kembali berkali-kali.
Sheet untuk tugas yang bisa dibatalkan
Formulir tambah alamat atau pemilih filter lebih tepat dibuka sebagai sheet. Pengguna mengerjakan satu tugas, lalu menutupnya. Kalau tugas itu punya langkah lanjutan, gunakan NavigationStack di dalam sheet, bukan menumpuk sheet baru.
Langkah implementasi dengan NavigationStack
Urutan berikut membantumu membangun alur dasar tanpa menambah utang teknis.
- Tentukan enum tujuan navigasi seperti contoh di atas.
- Simpan array path di level yang cukup tinggi, misalnya di view root atau di objek yang dibagikan ke seluruh layar.
- Bungkus tampilan utama dengan NavigationStack yang menerima binding ke array tersebut.
- Daftarkan setiap tujuan lewat modifier navigationDestination.
- Ganti semua NavigationLink berbasis boolean menjadi NavigationLink(value:).
- Uji perilaku tombol kembali dengan mengubah isi array secara manual.
Langkah kelima sering terlewat. NavigationLink yang menyimpan flag boolean sulit dilacak ketika ada lebih dari tiga layar, dan nilainya tidak bisa direkonstruksi saat aplikasi dipulihkan. Versi berbasis nilai membuat path bisa dicetak, disimpan, dan dipulihkan.
Jebakan yang paling sering muncul
NavigationStack mendukung path bertipe tunggal. Kalau kamu mencampur beberapa tipe tujuan dalam satu stack, kompilator akan menolak. Solusinya adalah satu enum yang mencakup semua tujuan, atau path bertipe NavigationPath bila tujuanmu benar-benar dinamis.
Jebakan kedua muncul saat objek yang dipakai sebagai tujuan navigasi berubah. Jika kamu mendaftarkan model lengkap alih-alih ID, dan model itu diperbarui di tempat lain, tampilan detail bisa menampilkan data yang sudah basi. Simpan ID, lalu ambil model terbaru di layar tujuan.
Jebakan ketiga berkaitan dengan work yang berjalan di latar belakang. Navigasi yang dijalankan dari callback jaringan harus dibungkus dalam perubahan state di main actor. Tanpa itu, path bisa berubah tetapi tampilan tidak ikut berpindah, dan kamu akan menghabiskan waktu mencari bug yang tidak ada.
Kalau sebuah alur sulit dijelaskan sebagai urutan nilai, biasanya masalahnya ada di model data, bukan di SwiftUI.
Menguji alur sebelum merilis
Navigasi yang baik bisa diuji tanpa membuka simulator. Karena path hanyalah array nilai, kamu bisa menulis uji yang memeriksa apakah menambahkan satu tujuan menghasilkan urutan yang diharapkan, dan apakah menghapus elemen terakhir mengembalikan pengguna ke layar sebelumnya. Uji semacam ini cepat dan tidak bergantung pada animasi.
Di perangkat, periksa tiga hal: perilaku tombol kembali setelah deep link, keadaan path saat aplikasi masuk ke latar belakang, dan apakah sheet bisa ditutup dengan gestur tarik ke bawah pada semua layar. Untuk aplikasi yang terhubung ke layanan jaringan, pemeriksaan koneksi juga layak masuk daftar uji, misalnya dengan membandingkan latensi seperti pada cara membandingkan ping ke berbagai server DNS agar kamu tahu endpoint mana yang lambat sebelum pengguna mengeluh.
Sebelum aplikasi dilepas ke pengguna, pastikan juga data akun lama tidak tertinggal di perangkat bersama. Panduan cara menghapus akun media sosial lama dengan aman berguna sebagai pengingat bahwa kebiasaan bersih-bersih akun ikut memengaruhi kepercayaan pengguna terhadap aplikasi yang kamu buat.
Ringkasan
Mulai dari enum tujuan, simpan path di satu tempat, lalu pilih pola sesuai lebar layar: NavigationStack untuk alur bertingkat, NavigationSplitView untuk iPad dan Mac, sheet untuk tugas singkat yang bisa dibatalkan. Daftarkan tujuan lewat navigationDestination, hindari NavigationLink berbasis boolean, dan simpan ID alih-alih model lengkap. Dengan urutan ini, alur navigasi bisa diuji, dipulihkan, dan dikembangkan tanpa menimbulkan lapisan tambahan yang sulit dilacak.
Pertanyaan yang Sering Diajukan
Apakah NavigationView masih boleh dipakai?
Untuk proyek baru, gunakan NavigationStack karena NavigationView tidak mendukung path berbasis nilai dan sudah tidak disarankan. Pada proyek lama, migrasi bisa dilakukan bertahap per layar, dimulai dari alur yang paling sering berubah.
Bagaimana cara menangani deep link dengan NavigationStack?
Ubah URL menjadi enum tujuan, lalu isi array path dengan urutan tujuan yang diperlukan. Karena path adalah state biasa, deep link dan navigasi manual memakai mekanisme yang sama, sehingga perilakunya konsisten.
Bisakah sheet memakai NavigationStack di dalamnya?
Bisa, dan itu pola yang lazim untuk alur bertahap di dalam formulir. Buat NavigationStack baru di dalam sheet dengan path terpisah, lalu tutup sheet setelah alur selesai. Jangan menumpuk sheet di atas sheet untuk langkah lanjutan.
More Stories