Que estado de NetworkManager recibiu realmente o seu notificador?

O estado catro dispara unha notificación nunha API e significa outra cousa noutra, e o código non mostra ningunha diferenza. Cada valor de estado en NetworkManager pertence a unha enumeración con nome, e as enumeracións non coinciden en que significa un número dado. Por iso copiar un enteiro dun fragmento que funciona a outra función de retorno non é unha transferencia de comportamento; é unha coincidencia que espera a romperse. Atope primeiro o tipo e o número vólvese lexible.

Un número sen tipo é un rumor

Aquí importan dúas enumeracións. Unha describe unha conexión activa en xeral: descoñecido, activando, activado, desactivando, desactivado. A outra describe especificamente unha conexión VPN, e ten máis paradas no camiño, incluíndo a preparación, a configuración da conexión, a configuración de IP e unha solicitude de autenticación antes de que se active nada. A súa numeración comeza en cero en ambos os casos e despois diverxe, así que o valor que significa desactivado na enumeración xeral cae nalgún punto do medio da secuencia VPN. Ningunha das cabeceiras é incorrecta; responden a preguntas distintas.

Use a constante simbólica da cabeceira ou binding instalado en lugar dun literal. O nome sobrevive a unha renumeración; o enteiro non.

Vixíe unha conexión, non a máquina

Parta do UUID do perfil que lle interesa e do obxecto de conexión activa creado por esa activación. O estado dun dispositivo, ou o estado doutro túnel, non é un substituto, mesmo cando ambos cambian no mesmo momento. Manteña a identidade do obxecto xunto coa observación, para que un informe posterior poida dicir que perfil o produciu. A máquina ten moitos estados; o aviso trata dun deles.

Despois decida que debe significar o aviso. Unha conexión que nunca chegou á activación é un fallo de configuración, e unha sesión que estaba activa e logo desapareceu é unha perda. Merecen palabras distintas.

Diga que transición está a informar

Garde o estado anterior e compáreo co novo, en lugar de probar o valor novo de forma illada. Unha transición a un estado fallido e unha transición fóra dun estado activado son eventos distintos mesmo cando ambos rematan sen nada conectado. Rexistre a cadea de motivo ao lado, porque a miúdo é a única parte sobre a que un usuario pode actuar.

Unha desconexión intencionada non é unha falla. Se o aviso non pode distinguila, ensinará a xente a ignoralo.

Manteña vivo o observador

A sondaxe repetida non debe xerar outra alerta para un estado que non cambiou. Esa única regra elimina a maior parte do ruído que xeran estes notificadores.

Tamén trate o caso en que o xestor se reinicia ou o obxecto observado se substitúe. Un vixiante ligado a unha identidade obsoleta cala xusto no momento en que ocorre algo interesante, e o silencio parece saúde. Volva descubrir o obxecto actual tras un cambio na presenza do xestor, e rexistre cando ocorreu o redescubrimento. Doutro xeito, o rexistro mostra un túnel que simplemente deixou de informar.

Entregue o aviso onde está o usuario

Unha función de retorno privilexiada do sistema non herda o servizo de notificacións dunha sesión de escritorio. Unha mensaxe enviada desde un manexador a nivel de root pode desaparecer sen erro, o que produce un notificador que funciona cando se proba a man e nunca na práctica. Entregue na sesión que posúe o escritorio, ou deixe que o propio cliente do escritorio levante o aviso.

Prefera a notificación existente do cliente se xa cobre o caso, xa que dous notificadores para un evento é un problema de soporte e non unha redundancia. Manteña a hora do evento, o perfil e o motivo no rexistro de soporte, e deixe fóra os contrasinais e os perfís completos. Lembre o que é o aviso: un informe dun estado observado, non un mecanismo de aplicación, porque bloquear o tráfico mentres o túnel está ausente é unha política aparte coa súa propia implementación.