Occasionally Connected Scenarios

Applies to: Windows Phone 7

Published: August 2011

Author: Nick Randolph

WROX Tech Editors for Windows Phone 7 Articles

Wrox Windows Phone 7 Books

This topic contains the following sections.

Being connected is something that you are all still coming to terms with. Pervasive Internet on our phones is no longer a dream for the future; it’s here today—well, at least in some areas. The reality is that even in areas where there is a relatively strong signal, it is still possible to get interference or poor reception. This means that if you have an application that is heavily reliant on the Internet, it is likely to create a poor user experience. Users have to wait as pages load data, they have to wait when they sign in, and they have to wait to go from one page to another.

Had the application developer taken a different approach when building the application, the user might rarely have to wait. The premise is to build the application with aggressive caching and even pre-caching of data to ensure that the user is seldom waiting for data to download. Users perceive the user experience to be responsive and quick to navigate around in. Any data that users interact with loads immediately and any changes are saved instantaneously, allowing users to continue doing what’s important to them. The application kicks off a background thread, and any outstanding synchronization tasks are completed.

Central to the capability to remove the reliance on having a network available is the capability to detect when the phone has connectivity. If the application can detect whether there is a network available, it can synchronize automatically in the background, eliminating the need for manual user intervention.

Network Availability

To detect whether a network is available, the NetworkInterface class exposes a static GetIsNetworkAvailable method that returns a Boolean value indicating whether the phone is connected to a network. However, just because the phone is connected to a network does not mean that the phone can connect to any and all websites and services.

bool networkIsAvailable = NetworkInterface.GetIsNetworkAvailable();

Assume for a minute that there is currently no network available to the phone. In this scenario, the user is busy using the application and your code is collecting all information necessary to ensure that it can synchronize when the network comes back online. To do this efficiently, when the device connects to a network, the application can register for the NetworkAddressChanged event. This would prompt the background thread to come alive and attempt to deliver any of the pending messages.

NetworkChange.NetworkAddressChanged += NetworkChange_NetworkAddressChanged;
private void NetworkChange_NetworkAddressChanged(object sender, EventArgs e){
    bool networkIsAvailable = NetworkInterface.GetIsNetworkAvailable();

If you’re planning to use this property or this event in your application, you should be aware of some inconsistencies between how a real device behaves and how the emulator behaves.

Service Availability

If you can detect that a network is available, the next step is to determine whether the service you’re going to be connecting to is available. This usually involves calling a simple service or downloading a small file from the server.

You might hear some debate about whether any value comes from verifying that the service is available. Because you have to write error-handling logic around any calls you make to the remote service anyhow, you can simply attempt to make the service call. If the call fails, it might be that the service is unreachable or that the parameters of the call resulted in it throwing an exception. At this point, you need to write some logic that schedules the call to be retried, or dropped if it is really a poison pill (that is, a message that repeatedly fails, causing all messages behind it to be blocked).

NetworkInterfaceType Property

The last point worth noting is that your application can detect what network interface type the device is connected to. This primarily falls into three buckets: LAN, WiFi, and 3G. When the phone is connected via a USB cable and Zune to the desktop, the system reports that the current network interface type is LAN. The other two are as you would expect, depending on which network the phone is connected to.

This is important because if you have large quantities of data to copy to and from the device, it makes sense to do this on the cheapest and quickest network. This quite often ends up being via the LAN connection. To detect which network interface type the device is currently connected to, you can query the NetworkInterfaceType property as shown in the following code snippet:

var nic = NetworkInterface.NetworkInterfaceType;
switch (nic)  { 
    case NetworkInterfaceType.MobileBroadbandCdma:// CDMA
   case NetworkInterfaceType.MobileBroadbandGsm:  // GSM 
    case NetworkInterfaceType.Wireless80211: // Wi-Fi 
    case NetworkInterfaceType.Ethernet:    //Ethernet
    case NetworkInterfaceType.None: // None 

Based on the resulting network interface type, you can determine whether to synchronize all or some of the data. Large downloads should be postponed until the user has connected to a cheaper, faster network.

One area that requires some careful consideration is how you plan for varying network availability. So far, you’ve seen how you can download content and save it to isolated storage. In essence, this exemplifies the basics of caching. However, the challenge lies in knowing when to update this information. Furthermore, as data is changed on the device, you need to allow for those changes to be sent back to the server. This might include having to provide an interface through which conflicts can be resolved.

Data that you use within your application typically falls into three categories. The first category is content—for example, lookup values, constants, and so on that your application needs to download at least once, if not periodically. No change tracking is done on the client, and each time the entire set of data is downloaded from the server. Of course, you can add some code that determines how often and when these downloads occur.

The second category comprises of scenarios when your application needs to upload data only. For example, if you’re recording defects or tacking orders, after the transaction has completed it can be dispatched from the device and is no longer required to be kept on the device.

The final category is for scenarios where data is synchronized in both directions. This is the most complex scenario because it requires handling of potential synchronization conflicts. For example, User A has the latest information on her phone. She makes some changes to the data, while at the same time, User B has been accessing the same system but through his web interface. Now when User A goes to commit her changes, it results in a synchronization conflict.

Many different approaches are possible, but whichever way you go, remember that synchronization conflicts can effectively be resolved only by a person reviewing the conflict and working out which is the correct value.

In this article, you have learned all about consuming and storing data on the Windows Phone platform. You have seen how you can connect to remote web services and consume data from OData providers. With data on the device, you saw how to connect the data to controls via data binding, including the capability to receive data back from the user via two-way data binding. This provides you with a good foundation for building applications that make the most of the rich and powerful development platform that is Windows Phone.

Previous Article: Saving Data to the Web

Continue on to the Next Article: Beginning 2D Game Development