Status NetworkManager mana yang sebenarnya diterima pemberitahu Anda?

Status empat memicu notifikasi pada satu API dan berarti hal lain pada API lain, dan kode tidak menunjukkan perbedaan sama sekali. Setiap nilai status di NetworkManager termasuk dalam enumerasi bernama, dan enumerasi-enumerasi itu tidak sepakat tentang arti suatu bilangan. Karena itu menyalin bilangan bulat dari potongan yang berfungsi ke callback lain bukanlah pemindahan perilaku; itu kebetulan yang menunggu untuk rusak. Temukan tipenya lebih dulu, dan bilangan itu menjadi terbaca.

Bilangan tanpa tipe hanyalah desas-desus

Ada dua enumerasi yang penting di sini. Satu menjelaskan koneksi aktif secara umum: tidak dikenal, mengaktifkan, aktif, menonaktifkan, nonaktif. Yang lain menjelaskan koneksi VPN secara khusus, dan ia punya lebih banyak perhentian di jalan, termasuk persiapan, penyiapan koneksi, konfigurasi IP, dan permintaan autentikasi sebelum apa pun diaktifkan. Penomoran keduanya dimulai dari nol dalam kedua kasus lalu menyimpang, sehingga nilai yang berarti nonaktif dalam enumerasi umum mendarat di suatu tempat di tengah urutan VPN. Tidak ada header yang salah; keduanya menjawab pertanyaan yang berbeda.

Gunakan konstanta simbolis dari header atau binding yang terpasang alih-alih literal. Nama bertahan dari penomoran ulang; bilangan bulatnya tidak.

Awasi satu koneksi, bukan mesinnya

Mulailah dari UUID profil yang Anda pedulikan dan objek koneksi aktif yang dibuat oleh aktivasi itu. Status perangkat, atau status tunnel lain, bukanlah pengganti, bahkan ketika keduanya berubah pada saat yang sama. Simpan identitas objek bersama pengamatan, agar laporan berikutnya dapat menyebutkan profil mana yang menghasilkannya. Mesin punya banyak status; notifikasi ini tentang salah satunya.

Lalu putuskan apa arti notifikasi itu seharusnya. Koneksi yang tidak pernah mencapai aktivasi adalah kegagalan penyiapan, dan sesi yang tadinya aktif lalu menghilang adalah kehilangan. Keduanya layak mendapat kata yang berbeda.

Katakan transisi mana yang Anda laporkan

Simpan status sebelumnya dan bandingkan dengan yang baru, alih-alih menguji nilai baru secara terpisah. Transisi ke status gagal dan transisi keluar dari status aktif adalah peristiwa berbeda meskipun keduanya berakhir tanpa apa pun terhubung. Catat string alasan di sampingnya, karena sering kali itulah satu-satunya bagian yang bisa ditindaklanjuti pengguna.

Pemutusan yang disengaja bukanlah kesalahan. Jika notifikasi tidak dapat membedakannya, ia akan melatih orang untuk mengabaikannya.

Jaga pengamat tetap hidup

Polling berulang tidak boleh memunculkan peringatan lain untuk status yang tidak berubah. Aturan tunggal itu menghilangkan sebagian besar kebisingan yang dihasilkan pemberitahu ini.

Tangani juga kasus ketika manajer dimulai ulang atau objek yang diamati diganti. Pengamat yang terikat pada identitas basi menjadi diam tepat pada saat sesuatu yang menarik terjadi, dan diam terlihat seperti kesehatan. Temukan kembali objek saat ini setelah perubahan keberadaan manajer, dan catat kapan penemuan ulang itu terjadi. Jika tidak, log menunjukkan tunnel yang sekadar berhenti melapor.

Antarkan notifikasi ke tempat pengguna berada

Callback sistem yang berhak istimewa tidak mewarisi layanan notifikasi sesi desktop. Pesan yang dikirim dari penangan tingkat root dapat hilang tanpa kesalahan, yang menghasilkan pemberitahu yang berfungsi saat diuji dengan tangan dan tidak pernah dalam praktik. Antarkan ke sesi yang memiliki desktop, atau biarkan klien desktop itu sendiri yang memunculkan notifikasi.

Utamakan notifikasi klien yang sudah ada jika sudah mencakup kasus ini, karena dua pemberitahu untuk satu peristiwa adalah masalah dukungan, bukan redundansi. Simpan waktu peristiwa, profil, dan alasan dalam catatan dukungan, dan jauhkan kata sandi serta profil lengkap dari catatan itu. Ingat apa itu notifikasi: laporan tentang status yang diamati, bukan mekanisme penegakan, karena memblokir lalu lintas saat tunnel tidak ada adalah kebijakan terpisah dengan implementasinya sendiri.