Welchen NetworkManager-Zustand hat Ihr Notifier tatsächlich bekommen?

Zustand vier löst in einer API eine Benachrichtigung aus und bedeutet in einer anderen etwas anderes, und der Code zeigt überhaupt keinen Unterschied. Jeder Zustandswert in NetworkManager gehört zu einer benannten Aufzählung, und die Aufzählungen sind sich nicht einig, was eine gegebene Zahl bedeutet. Eine Ganzzahl aus einem funktionierenden Ausschnitt in einen anderen Callback zu kopieren ist daher keine Übertragung von Verhalten; es ist ein Zufall, der darauf wartet, zu brechen. Finden Sie zuerst den Typ, dann wird die Zahl lesbar.

Eine Zahl ohne Typ ist ein Gerücht

Zwei Aufzählungen sind hier wichtig. Die eine beschreibt eine aktive Verbindung allgemein: unbekannt, aktivierend, aktiviert, deaktivierend, deaktiviert. Die andere beschreibt speziell eine VPN-Verbindung, und sie hat mehr Haltepunkte auf dem Weg, darunter Vorbereitung, Verbindungsaufbau, IP-Konfiguration und eine Authentifizierungsanfrage, bevor irgendetwas aktiviert wird. Ihre Nummerierung beginnt in beiden Fällen bei null und läuft dann auseinander, sodass der Wert, der in der allgemeinen Aufzählung deaktiviert bedeutet, irgendwo in der Mitte der VPN-Sequenz landet. Keine der Header ist falsch; sie beantworten verschiedene Fragen.

Verwenden Sie die symbolische Konstante aus dem installierten Header oder Binding statt eines Literals. Der Name übersteht eine Neunummerierung; die Ganzzahl nicht.

Beobachten Sie eine Verbindung, nicht die Maschine

Beginnen Sie mit der Profil-UUID, die Sie interessiert, und dem Objekt der aktiven Verbindung, das diese Aktivierung erzeugt hat. Ein Gerätezustand oder der Zustand eines anderen Tunnels ist kein Ersatz, selbst wenn sich beide im selben Moment ändern. Behalten Sie die Identität des Objekts bei der Beobachtung, damit ein späterer Bericht sagen kann, welches Profil sie erzeugt hat. Die Maschine hat viele Zustände; die Benachrichtigung betrifft einen davon.

Entscheiden Sie dann, was die Benachrichtigung bedeuten soll. Eine Verbindung, die nie die Aktivierung erreicht hat, ist ein Einrichtungsfehler, und eine Sitzung, die aktiv war und dann verschwand, ist ein Verlust. Diese verdienen unterschiedliche Worte.

Sagen Sie, welchen Übergang Sie melden

Speichern Sie den vorherigen Zustand und vergleichen Sie ihn mit dem neuen, statt den neuen Wert isoliert zu prüfen. Ein Übergang in einen fehlgeschlagenen Zustand und ein Übergang aus einem aktivierten Zustand sind verschiedene Ereignisse, auch wenn beide mit nichts Verbundenem enden. Notieren Sie die Begründungszeichenfolge daneben, denn oft ist sie der einzige Teil, auf den ein Benutzer reagieren kann.

Ein absichtliches Trennen ist kein Fehler. Wenn die Benachrichtigung den Unterschied nicht erkennen kann, wird sie Menschen dazu erziehen, sie zu ignorieren.

Halten Sie den Beobachter am Leben

Wiederholtes Abfragen darf keinen weiteren Alarm für einen Zustand auslösen, der sich nicht geändert hat. Diese eine Regel beseitigt den größten Teil des Rauschens, das diese Notifier erzeugen.

Behandeln Sie auch den Fall, dass der Manager neu startet oder das beobachtete Objekt ersetzt wird. Ein Beobachter, der an eine veraltete Identität gebunden ist, verstummt genau in dem Moment, in dem etwas Interessantes passiert, und Stille sieht aus wie Gesundheit. Entdecken Sie das aktuelle Objekt nach einer Änderung der Präsenz des Managers neu, und halten Sie fest, wann die Neuerkennung geschah. Andernfalls zeigt das Protokoll einen Tunnel, der einfach aufhörte zu berichten.

Liefern Sie die Benachrichtigung dorthin, wo der Benutzer ist

Ein privilegierter System-Callback erbt nicht den Benachrichtigungsdienst einer Desktop-Sitzung. Eine Nachricht, die von einem Handler auf Root-Ebene gesendet wird, kann ohne Fehler verschwinden, was einen Notifier ergibt, der bei manueller Prüfung funktioniert und in der Praxis nie. Liefern Sie in die Sitzung, die den Desktop besitzt, oder lassen Sie den eigenen Client des Desktops die Benachrichtigung auslösen.

Bevorzugen Sie die vorhandene Benachrichtigung des Clients, wenn sie den Fall bereits abdeckt, denn zwei Notifier für ein Ereignis sind ein Supportproblem und keine Redundanz. Halten Sie Ereigniszeit, Profil und Grund im Support-Datensatz fest, und lassen Sie Passwörter und vollständige Profile draußen. Denken Sie daran, was die Benachrichtigung ist: ein Bericht über einen beobachteten Zustand, kein Durchsetzungsmechanismus, denn das Blockieren von Verkehr bei fehlendem Tunnel ist eine eigene Richtlinie mit eigener Umsetzung.