L’estat quatre dispara una notificació en una API i significa una altra cosa en una altra, i el codi no mostra cap diferència. Cada valor d’estat a NetworkManager pertany a una enumeració amb nom, i les enumeracions no coincideixen sobre què significa un nombre donat. Per tant, copiar un enter d’un fragment que funciona a una altra funció de retorn no és una transferència de comportament; és una coincidència que espera a trencar-se. Trobeu primer el tipus i el nombre esdevé llegible.

Un nombre sense tipus és un rumor

Aquí importen dues enumeracions. Una descriu una connexió activa en general: desconegut, activant, activat, desactivant, desactivat. L’altra descriu específicament una connexió VPN i té més parades pel camí, com ara la preparació, la configuració de la connexió, la configuració d’IP i una sol·licitud d’autenticació abans que res s’activi. La seva numeració comença a zero en tots dos casos i després divergeix, de manera que el valor que significa desactivat a l’enumeració general cau en algun lloc al mig de la seqüència VPN. Cap de les capçaleres no és incorrecta; responen a preguntes diferents.

Utilitzeu la constant simbòlica de la capçalera o l’enllaç instal·lat en lloc d’un literal. El nom sobreviu a una renumeració; l’enter no.

Vigileu una connexió, no la màquina

Partiu de l’UUID del perfil que us interessa i de l’objecte de connexió activa creat per aquesta activació. L’estat d’un dispositiu, o l’estat d’un altre túnel, no és un substitut, fins i tot quan tots dos canvien en el mateix moment. Mantingueu la identitat de l’objecte amb l’observació, perquè un informe posterior pugui dir quin perfil l’ha produït. La màquina té molts estats; la notificació tracta d’un d’ells.

Després decidiu què ha de significar la notificació. Una connexió que mai no va arribar a l’activació és un error de configuració, i una sessió que estava activa i després va desaparèixer és una pèrdua. Aquestes mereixen paraules diferents.

Digueu quina transició informeu

Emmagatzemeu l’estat anterior i compareu-lo amb el nou, en lloc de provar el valor nou aïlladament. Una transició cap a un estat fallit i una transició fora d’un estat activat són esdeveniments diferents fins i tot quan tots dos acaben sense res connectat. Enregistreu la cadena de motiu al costat, perquè sovint és l’única part sobre la qual un usuari pot actuar.

Una desconnexió intencionada no és una fallada. Si la notificació no pot distingir-ho, ensenyarà la gent a ignorar-la.

Mantingueu viu l’observador

L’enquesta repetida no ha de generar una altra alerta per a un estat que no ha canviat. Aquesta única regla elimina la major part del soroll que generen aquests notificadors.

Gestioneu també el cas en què el gestor es reinicia o l’objecte observat se substitueix. Un vigilant lligat a una identitat obsoleta calla exactament en el moment que passa alguna cosa interessant, i el silenci sembla salut. Torneu a descobrir l’objecte actual després d’un canvi en la presència del gestor, i enregistreu quan va passar el redescobriment. En cas contrari, el registre mostra un túnel que simplement va deixar d’informar.

Lliureu la notificació on és l’usuari

Una funció de retorn privilegiada del sistema no hereta el servei de notificacions d’una sessió d’escriptori. Un missatge enviat des d’un gestor a nivell d’arrel pot desaparèixer sense error, cosa que produeix un notificador que funciona quan es prova a mà i mai a la pràctica. Lliureu-lo a la sessió que posseeix l’escriptori, o deixeu que el propi client de l’escriptori aixequi la notificació.

Preferiu la notificació existent del client si ja cobreix el cas, ja que dos notificadors per a un esdeveniment és un problema de suport i no pas una redundància. Mantingueu l’hora de l’esdeveniment, el perfil i el motiu al registre de suport, i deixeu-ne fora les contrasenyes i els perfils complets. Recordeu què és la notificació: un informe d’un estat observat, no un mecanisme d’aplicació, perquè bloquejar el trànsit mentre el túnel és absent és una política separada amb la seva pròpia implementació.

Articles relacionats