Part of an application's agility comes from its ability to work properly under any circumstance. In today's mobile age, someone could be using an application on a laptop in a disconnected environment, bring the laptop to a coffee shop and connect wirelessly, and then bring the laptop home and connect to a wired LAN. A truly agile application needs to be able to work when the network is connected and when it is disconnected.
The first part of working in both connected and disconnected modes is making sure that your application makes a local cache of offline activity that can then be uploaded to the web service after the connection is restored. The format and storage medium of this offline cache will be up to you and will largely depend on the specifics of your application, so that won't be covered in detail here.
In order for your application to begin uploading data to the web service when a connection is restored, your application needs to know when a connection has been restored.
The new System.Net.NetworkInformation namespace provides developers with a handy utility class called NetworkChange. This class hosts events that are used to notify applications when changes in network status occur.
The first event is NetworkAvailabilityChanged. This event reports when there is a change in network availability. The network is considered "Available" when there is at least one network interface device that is considered "Up." If all network interfaces are down or otherwise having trouble, the network is not available.
This might seem like the ideal way to detect whether your user has network access to the web service. Unfortunately, this isn't entirely true. Here's the rub: If the user has multiple network interfaces, such as Wireless (Wi-Fi) access, a LAN card, a 1394 IEEE card (FireWire), or a VPN (Virtual Private Network) interface device, this can complicate things. What happens is that one of these devices will lose access, but other devices may remain "up," yet none are connected to a "real" network. In this case, the NetworkAvailabilityChanged event arguments will still report that the network is available, yet the client application cannot communicate with the web service.
To provide true connection detection, your code also needs to respond to the NetworkAddressChanged event, which is called whenever a network address is changed. Network addresses change when a device acquires a DHCP address (connect) and when a device disconnects or becomes disabled.
Listing 38.1 shows the source code for a form that sends messages to a list box when addresses change and when network availability changes. With this application running, experiment by turning off Wi-Fi hardware switches, disabling interfaces, enabling interfaces, and plugging and unplugging physical LAN cables. Make note of when the address change event is called compared to when the network availability event is called. For maximum effect, try this on a machine with a wireless card, a LAN card, and another network device like a VPN or a FireWire device.
Listing 38.1. Monitoring Network Status
The code in the preceding listing uses the presence of at least one gateway address as a litmus test to guess whether a real network connection is present after the address change. It also makes handy use of anonymous methods to use the Invoke() method to forward the GUI-modifying code to the main UI thread. Figure 38.3 shows what happened when this program ran. The author had turned off his wireless card and then turned it back on, and then disabled every adapter on his machine, which finally produced a network availability event. Then he turned them all back on, which completed the test with a valid gateway.
Figure 38.3. Monitoring network availability and address changed events.