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
When using config files to configure WiFi settings, simply adding a handler to NetworkConnected as currently described is not enough.
In this case, you might want to register the NetworkConnected event in the Initialize() method to start any network related tasks once the device joins your network.
The event may fire before hooking up the handler. To ensure the application isn't needlessly blocked, users need to do something like:
var wifi = Device.NetworkAdapters.Primary<IWiFiNetworkAdapter>();
while (!wifi.IsConnected)
{
await Task.Delay(100);
}
This could live in Initialize() or Run() depending on the customer's use case.
The text was updated successfully, but these errors were encountered:
Just to check, what was the situation here? Were you relying on the auto-connect system in config?
Not sure if it's worth the Task and async/await overhead, but I've used this helper method before to keep the code clean when using the wifi.Connect(...) method directly. You could probably rig it up to rely on config connecting instead, though.
If it was written in a way that assumes .Connect is called elsewhere or config is used to connect, then you could delay the await until you absolutely needed to have network access to continue.
varwifi= Device.NetworkAdapters.Primary<IWiFiNetworkAdapter>();// Do whatever other initialization work you can before your first network call is required.
...
await wifi.WaitForNetworkConnection(...);
Since connecting to wifi isn't a fast process on a good day, it's probably worth firing it off and then only awaiting in your app when it's needed.
Unfortunately, this doesn't handle wifi drops and reconnects at all. So, maybe neither solution is sufficient. 🤷
When using config files to configure WiFi settings, simply adding a handler to
NetworkConnected
as currently described is not enough.The event may fire before hooking up the handler. To ensure the application isn't needlessly blocked, users need to do something like:
This could live in
Initialize()
orRun()
depending on the customer's use case.The text was updated successfully, but these errors were encountered: