Handling Network Transitions Transparently

Handling Network Transitions Transparently

On mobile PCs, applications encounter changes in network connectivity. Users can easily move from one location to another, yet may not be able to establish connectivity at the new location. Even in a single location, network connections can fluctuate: a network connection may become unavailable while the application is running, or even while a network operation is in progress.

Maintain awareness of connectivity status so that your application can respond reasonably and transparently to transitions in network connectivity. For example:

• If a network resource becomes disconnected, an application can defer data transfers and provide appropriate user feedback.
• When the user establishes a new network connection, an application can resume pending transfers if sufficient bandwidth exists, and then transfer information that may be needed later.
• An application can cache data locally so that files that are being used are protected from network interruptions, and then synchronize the cache when connectivity is present.

Monitoring for connectivity changes

You can monitor for connectivity changes by using interfaces in the Network Profile service. You can implement the event handlers for these interfaces in one or more background threads, to allow uninterrupted operation of the user interface. To monitor for connectivity changes, use these interfaces:

• INotifyNetworkEvents signals when a network is added, deleted, connected, or disconnected, as well as when changes occur to the network properties (for example, the interface or description).

• INotifyNetworkInterfaceEvents signals when an interface is connected or disconnected, as well as when the connectivity of an interface changes.

  Note  Both the INotifyNetworkEvents and INotifyNetworkInterfaceEvents interfaces appear in EventHandler.h.

Typically, one background thread hosts the event sinks for INotifyNetworkEvents and INotifyNetworkInterfaceEvents. Your event handlers can use the network ID to call INetworkListManager::GetNetwork. Use the INetwork interface returned from that call so that you can obtain information about the affected network, including name, description, and Internet connectivity.

Responding appropriately to connectivity interruptions

Plan ahead for interruptions in connectivity. Your application should enable the user to focus on immediate tasks without breaking the user's concentration with notifications about connectivity problems. Consider these questions, along with suggested workarounds:

• Which connectivity issues directly affect the user's current task? Determine which issues are most likely to demand the user's immediate attention. If you cannot download data and display the updated information, try to substitute placeholders or cached data.
• Can your application handle connectivity problems without notifying the user? If a resource is unavailable due to an intermittent connection problem, wait for the connection to be restored, and then resume the process that was interrupted. You can cache the data locally if necessary.
• Can your application automatically take advantage of new connections to improve the user experience? Switch to a different connection if a better one is available.

Communicating about connectivity issues

To limit user distraction, communicate appropriately about any connectivity problems. Consider these questions when you determine whether and how to alert users to connectivity issues:

• Does the event affect a network operation in progress? If not, you probably don't need to notify the user. If networking activities are a primary focus of your application, and the event is likely to affect future activities, report the status change by using a status bar indicator as shown in Using Status Indicators below.
• Did the user explicitly initiate the operation that was interrupted? If so, alert the user. If there is an obvious workaround (for example, if you can save the data locally), you may not need to prompt the user. You can inform the user of the interruption at the same time that you inform the user about what has been done to work around the interruption. If necessary, indicate what steps the user must take to ensure that the operation is completed.If the interrupted operation was not initiated by the user's direct action, can you delay notification and resume the operation later? Try to find a way to avoid interrupting the user's focus on the operation they set out to accomplish.
• Has the user already been notified about the interruption? A network may experience fluctuations in service. When possible, do not notify the user multiple times. In particular, avoid modal dialog boxes that interrupt the user's work in your application or in other applications.
• Are there network operations still pending when the user exits your application? If so, how will this affect the user? Consider showing a modal dialog box if the user tries to exit the application when critical data must still be exchanged over the network.

Defer reporting connectivity issues when possible, rather than interrupt the user's work. For example, defer reporting when a connectivity change can be handled without immediate consequence to the user, or when there is no action for the user to take and the application can continue the pending actions after connectivity is resumed.

Being offline is not necessarily an error state. If you use a network-centric application, such as a chat client, network connectivity is critical. But even in that case, a temporary loss of network connectivity probably does not warrant a modal dialog box. For more information, see "Dialog Boxes" and "Error Messages" in Top Guidelines Violations.

Using status indicators

Consider the following questions to determine whether a status indicator is necessary.

• If network operations are an integral part of your users' task scenarios, can you provide some type of indicator on the application frame about the availability of necessary resources?
• If network bandwidth is variable and low-bandwidth connectivity is likely to inconvenience your users because of extended transfer times, can you provide an indication of available bandwidth?

The following screen shot shows connectivity status in the status bar in Microsoft Office Outlook 2003.

For more information, see Status Bars.

Send comments about this topic to Microsoft

Build date: 12/5/2008