Kva for ein NetworkManager-tilstand fekk varslaren din eigentleg?

Tilstand fire utløyser eit varsel på éin API og tyder noko anna på ein annan, og koden viser ingen skilnad i det heile. Kvar tilstandsverdi i NetworkManager høyrer til ei namngjeven opplisting, og opplistingane er ikkje samde om kva eit gjeve tal tyder. Å kopiere eit heiltal frå ein fungerande snutt til ein annan tilbakekalling er derfor ikkje ei overføring av åtferd; det er eit samantreff som ventar på å bryte saman. Finn typen først, så vert talet leseleg.

Eit tal utan type er berre eit rykte

To opplistingar er viktige her. Den eine skildrar ei aktiv tilkopling generelt: ukjend, aktiverande, aktivert, deaktiverande, deaktivert. Den andre skildrar særskilt ei VPN-tilkopling, og ho har fleire stopp undervegs, mellom anna førebuing, oppsett av tilkoplinga, IP-konfigurasjon og ein autentiseringsførespurnad før noko vert aktivert. Nummereringa deira startar på null i begge tilfelle og går deretter frå kvarandre, så verdien som tyder deaktivert i den generelle opplistinga hamnar ein stad midt i VPN-sekvensen. Ingen av overskriftene er feil; dei svarar på ulike spørsmål.

Bruk den symbolske konstanten frå den installerte overskrifta eller bindinga i staden for eit literalt tal. Namnet overlever ei omnummerering; heiltalet gjer det ikkje.

Følg med på éi tilkopling, ikkje maskina

Start frå profil-UUID-en du bryr deg om, og det aktive tilkoplingsobjektet som den aktiveringa oppretta. Ein einetilstand, eller tilstanden til ein annan tunnel, er ikkje ei erstatning, sjølv når begge endrar seg i same augneblink. Hald identiteten til objektet saman med observasjonen, slik at ein seinare rapport kan seie kva profil som produserte han. Maskina har mange tilstandar; varselet handlar om éin av dei.

Avgjer deretter kva varselet skal tyde. Ei tilkopling som aldri nådde aktivering, er ein oppsettsfeil, og ei økt som var aktiv og deretter forsvann, er eit tap. Desse fortener ulike ord.

Sei kva for ein overgang du rapporterer

Lagre den førre tilstanden og samanlikn han med den nye, i staden for å teste den nye verdien isolert. Ein overgang til ein feila tilstand og ein overgang ut av ein aktivert tilstand er ulike hendingar sjølv når begge endar med ingenting tilkopla. Noter årsaksstrengen ved sida av, fordi han ofte er den einaste delen ein brukar kan handle på.

Ei medviten fråkopling er ikkje ein feil. Viss varselet ikkje kan sjå skilnaden, vil det lære folk å ignorere det.

Hald observatøren i live

Gjentatt avstemming må ikkje reise endå ei åtvaring for ein tilstand som ikkje er endra. Den eine regelen fjernar det meste av støyen desse varslarane lagar.

Handter òg tilfellet der behandlaren startar på nytt eller det observerte objektet vert erstatta. Ein overvakar bunden til ein utdatert identitet vert stille nøyaktig i det augneblinken noko interessant skjer, og stillheit ser ut som helse. Gjenoppdag det gjeldande objektet etter ei endring i tilstadeværet til behandlaren, og noter når gjenoppdaginga skjedde. Elles viser loggen ein tunnel som berre slutta å rapportere.

Lever varselet der brukaren er

Ein privilegert systemtilbakekalling arvar ikkje varseltenesta til ei skrivebordsøkt. Ei melding send frå ein behandlar på root-nivå kan forsvinne utan feil, noko som gjev ein varslar som fungerer når han vert testa for hand og aldri i praksis. Lever i økta som eig skrivebordet, eller la skrivebordet sin eigen klient reise varselet.

Føretrekk det eksisterande varselet til klienten viss det alt dekkjer tilfellet, sidan to varslarar for éi hending er eit støtteproblem snarare enn redundans. Hald hendingstida, profilen og årsaka i støttenotatet, og hald passord og fullstendige profilar utanfor. Hugs kva varselet er: ein rapport om ein observert tilstand, ikkje ein handhevingsmekanisme, fordi å blokkere trafikk medan tunnelen manglar er ein eigen politikk med si eiga implementering.