You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add a new tool to check the health of the local WiFi network. This includes both a UI and a HealthMetricProvider implementation. We should be able to leverage Android's WiFiInfo and related code to get the data.
This tool gets the values for first whether WiFi is connected, and if it is the ssid, bssid (the specific access point, useful to see if a single AP is overloaded), and signalStrength (based on rssi) of the connected network.
The UI simply displays all these values.
The HealthMetricProvider always provides the same connected boolean, and if connected the ssid, bssid, and signalStrength as the UI.
Its 'healthy boolean is somewhat configurable:
if the device is not connected to WiFi it is always unhealthy
If the ssid does not match an optional configuration value of "expectedSSID", it is unhealthy (covers enterprise scenarios where the customer wants to validate the devices are on the correct WiFi with the other peers).
If the signalStrength is below an optional configured minimum value.
Open questions - should we scale the rssi into a 0-1 scale to match how Apple does it so that these can more easily be compared across platforms? Sync with development of getditto/DittoSwiftTools#148
The text was updated successfully, but these errors were encountered:
We may not be able to scale signalStrength to match what Apple does, if we're not confident we can create a truly comparable metric, just use raw rssi instead
Add a new tool to check the health of the local WiFi network. This includes both a UI and a
HealthMetricProvider
implementation. We should be able to leverage Android's WiFiInfo and related code to get the data.This tool gets the values for first whether WiFi is connected, and if it is the
ssid
,bssid
(the specific access point, useful to see if a single AP is overloaded), andsignalStrength
(based on rssi) of the connected network.The UI simply displays all these values.
The
HealthMetricProvider
always provides the sameconnected
boolean, and if connected thessid
,bssid
, andsignalStrength
as the UI.Its
'healthy
boolean is somewhat configurable:ssid
does not match an optional configuration value of "expectedSSID", it is unhealthy (covers enterprise scenarios where the customer wants to validate the devices are on the correct WiFi with the other peers).signalStrength
is below an optional configured minimum value.Open questions - should we scale the
rssi
into a 0-1 scale to match how Apple does it so that these can more easily be compared across platforms? Sync with development of getditto/DittoSwiftTools#148The text was updated successfully, but these errors were encountered: