Trình thông báo của bạn thực sự nhận được trạng thái nào của NetworkManager?

Trạng thái bốn kích hoạt một thông báo trên một API và mang nghĩa khác trên API khác, còn mã không hề cho thấy sự khác biệt nào. Mọi giá trị trạng thái trong NetworkManager thuộc về một phép liệt kê có tên, và các phép liệt kê không đồng ý về ý nghĩa của một con số nhất định. Vì vậy sao chép một số nguyên từ đoạn mã đang chạy sang một callback khác không phải là chuyển giao hành vi; đó là một sự trùng hợp đang chờ vỡ. Hãy tìm kiểu trước, và con số trở nên đọc được.

Một con số không kiểu chỉ là tin đồn

Hai phép liệt kê quan trọng ở đây. Một phép mô tả kết nối đang hoạt động nói chung: không rõ, đang kích hoạt, đã kích hoạt, đang hủy kích hoạt, đã hủy kích hoạt. Phép kia mô tả riêng kết nối VPN, và nó có nhiều điểm dừng hơn trên đường, bao gồm chuẩn bị, thiết lập kết nối, cấu hình IP và một yêu cầu xác thực trước khi bất cứ thứ gì được kích hoạt. Cách đánh số của chúng đều bắt đầu từ không rồi rẽ nhánh, nên giá trị mang nghĩa đã hủy kích hoạt trong phép liệt kê chung rơi vào đâu đó giữa chuỗi VPN. Không tiêu đề nào sai; chúng trả lời những câu hỏi khác nhau.

Dùng hằng số tượng trưng từ tiêu đề hoặc binding đã cài thay vì một giá trị trực tiếp. Cái tên sống sót qua việc đánh số lại; số nguyên thì không.

Theo dõi một kết nối, không phải cả máy

Bắt đầu từ UUID hồ sơ mà bạn quan tâm và đối tượng kết nối đang hoạt động do lần kích hoạt đó tạo ra. Trạng thái của một thiết bị, hay trạng thái của một đường hầm khác, không phải vật thay thế, kể cả khi cả hai cùng thay đổi trong một khoảnh khắc. Giữ danh tính của đối tượng đi cùng quan sát, để báo cáo sau này có thể nói hồ sơ nào đã sinh ra nó. Máy có nhiều trạng thái; thông báo chỉ nói về một trong số đó.

Sau đó quyết định thông báo nên mang nghĩa gì. Một kết nối chưa bao giờ tới được kích hoạt là lỗi thiết lập, và một phiên đang hoạt động rồi biến mất là mất mát. Hai điều đó xứng đáng những từ khác nhau.

Nói rõ bạn đang báo cáo chuyển đổi nào

Lưu trạng thái trước và so sánh với trạng thái mới, thay vì kiểm tra giá trị mới một cách tách rời. Chuyển vào một trạng thái hỏng và chuyển ra khỏi một trạng thái đã kích hoạt là hai sự kiện khác nhau kể cả khi cả hai kết thúc mà không có gì kết nối. Ghi lại chuỗi lý do bên cạnh, vì nó thường là phần duy nhất người dùng có thể hành động.

Ngắt kết nối có chủ đích không phải lỗi. Nếu thông báo không phân biệt được, nó sẽ dạy người ta bỏ qua nó.

Giữ cho trình quan sát còn sống

Việc thăm dò lặp lại không được tạo thêm cảnh báo cho một trạng thái không thay đổi. Chỉ một quy tắc đó loại bỏ phần lớn tiếng ồn mà những trình thông báo này sinh ra.

Cũng xử lý trường hợp trình quản lý khởi động lại hoặc đối tượng được quan sát bị thay thế. Một trình quan sát gắn với danh tính cũ sẽ im lặng đúng vào lúc có điều gì đó thú vị xảy ra, và sự im lặng trông giống như khỏe mạnh. Hãy phát hiện lại đối tượng hiện tại sau khi sự hiện diện của trình quản lý thay đổi, và ghi lại thời điểm phát hiện lại. Nếu không, nhật ký sẽ cho thấy một đường hầm chỉ đơn giản là ngừng báo cáo.

Gửi thông báo đến nơi người dùng đang ở

Một callback hệ thống có đặc quyền không kế thừa dịch vụ thông báo của một phiên máy tính để bàn. Một thông điệp gửi từ trình xử lý ở mức root có thể biến mất mà không báo lỗi, tạo ra một trình thông báo hoạt động khi kiểm tra thủ công và không bao giờ hoạt động trong thực tế. Hãy gửi vào phiên sở hữu máy tính để bàn, hoặc để ứng dụng khách của chính máy tính để bàn đưa thông báo lên.

Ưu tiên thông báo sẵn có của ứng dụng khách nếu nó đã bao quát trường hợp này, vì hai trình thông báo cho một sự kiện là vấn đề hỗ trợ chứ không phải dư thừa. Giữ thời gian sự kiện, hồ sơ và lý do trong bản ghi hỗ trợ, và để mật khẩu cùng hồ sơ đầy đủ ra ngoài. Hãy nhớ thông báo là gì: một báo cáo về trạng thái được quan sát, không phải cơ chế cưỡng chế, vì chặn lưu lượng khi đường hầm vắng mặt là một chính sách riêng với cách triển khai riêng.