اعلان‌دهندهٔ شما در واقع کدام وضعیت NetworkManager را گرفت؟
همان عدد صحیح در یک شمارش یعنی غیرفعال و در دیگری یعنی میانهٔ راه‌اندازی. پیش از کپی کردن یک شرط، نوع وضعیت را با شیء مطابقت دهید.
وضعیت چهار در یک API اعلان ایجاد می‌کند و در دیگری معنای دیگری دارد، و کد هیچ تفاوتی نشان نمی‌دهد. هر مقدار وضعیت در NetworkManager به یک شمارش نام‌دار تعلق دارد، و شمارش‌ها در این که یک عدد معین چه معنایی دارد هم‌داستان نیستند. بنابراین کپی کردن یک عدد صحیح از قطعه‌ای کارآمد به یک callback متفاوت انتقال رفتار نیست؛ تصادفی است که در انتظار شکستن است. اول نوع را پیدا کنید، آنگاه عدد خوانا می‌شود.
عدد بدون نوع فقط شایعه است
دو شمارش اینجا اهمیت دارند. یکی یک اتصال فعال را به‌طور کلی توصیف می‌کند: ناشناخته، در حال فعال‌سازی، فعال، در حال غیرفعال‌سازی، غیرفعال. دیگری به‌طور خاص یک اتصال VPN را توصیف می‌کند و ایستگاه‌های بیشتری در مسیر دارد، از جمله آماده‌سازی، راه‌اندازی اتصال، پیکربندی IP و درخواست احراز هویت پیش از آنکه چیزی فعال شود. شماره‌گذاری آن‌ها در هر دو حالت از صفر شروع می‌شود و سپس واگرا می‌شود، پس مقداری که در شمارش عمومی یعنی غیرفعال، جایی در میانهٔ دنبالهٔ VPN فرود می‌آید. هیچ‌کدام از سرصفحه‌ها غلط نیست؛ آن‌ها به پرسش‌های متفاوتی پاسخ می‌دهند.
از ثابت نمادین موجود در سرصفحه یا binding نصب‌شده به‌جای یک مقدار حرفی استفاده کنید. نام از شماره‌گذاری مجدد جان سالم به در می‌برد؛ عدد صحیح نه.
یک اتصال را بپایید، نه ماشین را
از UUID پروفایلی که برایتان مهم است و شیء اتصال فعالی که آن فعال‌سازی ساخته است شروع کنید. وضعیت یک دستگاه، یا وضعیت تونل دیگر، جانشین نیست، حتی وقتی هر دو در یک لحظه تغییر می‌کنند. هویت شیء را همراه با مشاهده نگه دارید، تا گزارش بعدی بتواند بگوید کدام پروفایل آن را تولید کرده است. ماشین وضعیت‌های زیادی دارد؛ اعلان درباره یکی از آن‌هاست.
سپس تصمیم بگیرید اعلان باید چه معنایی داشته باشد. اتصالی که هرگز به فعال‌سازی نرسید یک شکست در راه‌اندازی است، و نشستی که فعال بود و سپس ناپدید شد یک از دست رفتن است. این‌ها واژه‌های متفاوتی می‌طلبند.
بگویید کدام گذار را گزارش می‌کنید
وضعیت پیشین را ذخیره کنید و آن را با وضعیت جدید بسنجید، به‌جای آزمودن مقدار جدید به‌تنهایی. گذار به یک وضعیت ناموفق و گذار از یک وضعیت فعال رویدادهای متفاوتی هستند، حتی وقتی هر دو بدون هیچ اتصالی پایان می‌یابند. رشتهٔ دلیل را کنارش ثبت کنید، چون غالباً تنها بخشی است که کاربر می‌تواند روی آن اقدام کند.
قطع اتصال عمدی یک خطا نیست. اگر اعلان نتواند تفاوت را تشخیص دهد، به مردم می‌آموزد که آن را نادیده بگیرند.
ناظر را زنده نگه دارید
نظرسنجی مکرر نباید برای وضعیتی که تغییر نکرده هشدار دیگری ایجاد کند. همین یک قاعده بیشتر سر و صدایی را که این اعلان‌دهنده‌ها تولید می‌کنند حذف می‌کند.
همچنین حالتی را که مدیر راه‌اندازی مجدد می‌شود یا شیء مشاهده‌شده جایگزین می‌شود مدیریت کنید. ناظری که به هویتی کهنه گره خورده است دقیقاً در لحظه‌ای که چیز جالبی رخ می‌دهد ساکت می‌شود، و سکوت شبیه سلامت است. پس از تغییری در حضور مدیر، شیء جاری را دوباره کشف کنید و ثبت کنید که کشف دوباره چه زمانی رخ داد. وگرنه گزارش تونلی را نشان می‌دهد که صرفاً گزارش‌دهی را متوقف کرده است.
اعلان را جایی برسانید که کاربر هست
یک callback سیستمی ممتاز، سرویس اعلان یک نشست میزکار را به ارث نمی‌برد. پیامی که از یک گرداننده در سطح root فرستاده شود می‌تواند بدون خطا ناپدید شود، که اعلان‌دهنده‌ای می‌سازد که هنگام آزمایش دستی کار می‌کند و هرگز در عمل. به نشستی که میزکار را در اختیار دارد تحویل دهید، یا بگذارید کلاینت خود میزکار اعلان را بلند کند.
اگر اعلان موجود کلاینت از قبل این حالت را پوشش می‌دهد، آن را ترجیح دهید، چون دو اعلان‌دهنده برای یک رویداد یک مشکل پشتیبانی است نه افزونگی. زمان رویداد، پروفایل و دلیل را در سابقهٔ پشتیبانی نگه دارید، و گذرواژه‌ها و پروفایل‌های کامل را بیرون از آن بگذارید. یادتان باشد اعلان چیست: گزارشی از یک وضعیت مشاهده‌شده، نه سازوکار اجرا، چون مسدود کردن ترافیک در نبود تونل سیاستی جداگانه با پیاده‌سازی خودش است.