Melyik NetworkManager-állapotot kapta meg valójában az értesítője?

A négyes állapot az egyik API-n értesítést vált ki, a másikon valami mást jelent, és a kód semmilyen különbséget nem mutat. A NetworkManager minden állapotértéke egy nevesített felsoroláshoz tartozik, és a felsorolások nem értenek egyet abban, mit jelent egy adott szám. Ezért egy egész szám átmásolása egy működő részletből egy másik visszahívásba nem viselkedésátadás; ez egy véletlen, amely arra vár, hogy eltörjön. Először a típust keresse meg, és a szám olvashatóvá válik.

A típus nélküli szám csak pletyka

Két felsorolás számít itt. Az egyik egy aktív kapcsolatot ír le általában: ismeretlen, aktiváló, aktivált, deaktiváló, deaktivált. A másik kifejezetten egy VPN-kapcsolatot ír le, és több megállója van az úton, köztük az előkészítés, a kapcsolat beállítása, az IP-konfiguráció és egy hitelesítési kérés, mielőtt bármi aktiválódna. A számozásuk mindkét esetben nullától indul, majd szétválik, így az az érték, amely az általános felsorolásban deaktiváltat jelent, valahol a VPN-sorozat közepén landol. Egyik fejléc sem hibás; különböző kérdésekre válaszolnak.

A telepített fejlécből vagy kötésből származó szimbolikus konstanst használjon literál helyett. A név túléli az újraszámozást; az egész szám nem.

Egy kapcsolatot figyeljen, ne a gépet

Azt a profil-UUID-t válassza kiindulópontnak, amely érdekli, és az aktiválás által létrehozott aktív kapcsolat objektumát. Egy eszköz állapota vagy egy másik alagút állapota nem helyettesítő, még akkor sem, ha mindkettő ugyanabban a pillanatban változik. Tartsa az objektum identitását a megfigyelés mellett, hogy egy későbbi jelentés megmondhassa, melyik profil állította elő. A gépnek sok állapota van; az értesítés egyikükről szól.

Ezután döntse el, mit kell jelentenie az értesítésnek. Az a kapcsolat, amely soha nem érte el az aktiválást, beállítási hiba, és az a munkamenet, amely aktív volt, majd eltűnt, veszteség. Ezek különböző szavakat érdemelnek.

Mondja meg, milyen átmenetet jelent

Tárolja az előző állapotot, és hasonlítsa össze az újjal, ahelyett hogy az új értéket elszigetelten vizsgálná. A hibás állapotba való átmenet és az aktivált állapotból való kilépés különböző események, még akkor is, ha mindkettő semmi csatlakoztatottal végződik. Jegyezze fel mellé az ok karakterláncát, mert gyakran ez az egyetlen rész, amelyre a felhasználó cselekedhet.

A szándékos leválasztás nem hiba. Ha az értesítés nem tud különbséget tenni, megtanítja az embereket, hogy figyelmen kívül hagyják.

Tartsa életben a megfigyelőt

Az ismételt lekérdezés nem emelhet újabb riasztást egy meg nem változott állapotra. Ez az egyetlen szabály eltávolítja a zaj nagy részét, amelyet ezek az értesítők keltenek.

Kezelje azt az esetet is, amikor a kezelő újraindul, vagy a megfigyelt objektum lecserélődik. Az elavult identitáshoz kötött figyelő pontosan akkor hallgat el, amikor valami érdekes történik, a csend pedig egészségnek látszik. Fedezze fel újra az aktuális objektumot a kezelő jelenlétének változása után, és jegyezze fel, mikor történt az újrafelfedezés. Különben a napló egy alagutat mutat, amely egyszerűen abbahagyta a jelentést.

Juttassa el az értesítést oda, ahol a felhasználó van

Egy kiváltságos rendszer-visszahívás nem örökli egy asztali munkamenet értesítési szolgáltatását. A root szintű kezelőből küldött üzenet hiba nélkül eltűnhet, ami olyan értesítőt eredményez, amely kézi teszteléskor működik, a gyakorlatban soha. Juttassa el az asztalt birtokló munkamenetbe, vagy hagyja, hogy az asztal saját kliense emelje az értesítést.

Előnyben részesítse a kliens meglévő értesítését, ha már lefedi az esetet, mivel két értesítő egy eseményhez támogatási probléma, nem redundancia. Tartsa meg az esemény idejét, a profilt és az okot a támogatási rekordban, a jelszavakat és a teljes profilokat pedig hagyja azon kívül. Emlékezzen, mi az értesítés: egy megfigyelt állapot jelentése, nem kikényszerítő mechanizmus, mert a forgalom blokkolása az alagút hiányában külön szabályzat a saját megvalósításával.