Creating Mobilized Software Solutions

Submit New Article

November 1, 2009 8:00 PM PST


by Devu Pandit and Justin Huntsman


Introduction

The Mobilized Software Initiative (MSI) is a network-based application architecture that allows an end-user to continue working regardless of the state of his or her connection. An occasionally connected application should be able to detect when a connection is lost or becomes unreliable. In these situations, the application should transparently switch into an offline mode that allows the users as much functionality as is reasonably possible. Users should be able to keep working without interruption as they move in and out of network range, and as the quality of their connection improves and degrades.


Architectural Decisions

Although the goal for all occasionally connected applications is the same – to provide an experience that lets users continue working even when a connection fails – the methodologies to accomplish this goal can vary significantly. This paper presents some of these methodologies, using an Intel reference application called Mobile Reference Application as an example.

Designed around the scenario of a real-estate agency, Mobile Reference Application allows real estate agents to upload and download property information between servers and mobile client devices. Mobile Reference Application requires the following software on a developer machine:

  • Internet Information Server*
  • Microsoft Visual Studio .NET* 2003
  • Microsoft SQL Server*
  • Web Service Enhancements for Microsoft .NET* 1.0 (SP1)
  • Windows* Media Player 9 Series
  • DirectX* 9.0a Software Development Kit

 

It should be noted that the methods presented in this paper aren’t necessarily the only ways to create an MSI application. Indeed, depending on the business requirements, technologies used, and even developer preference, there are many ways to create an MSI application.

Before an MSI application can be effectively designed, several important questions need to be answered:

  • How will the application determine whether it is online or offline?
  • When a connection is lost, what features of the client application can still be usable? What features cannot work without a connection to the server?
  • When a connection is resumed, does the client application need to be synchronized with the server? How should this synchronization be performed?
  • If the connection is lost and the mobile PC is running out of power, how can the user’s data be saved?
  • When a connection becomes unreliable or suffers from reduced bandwidth, is it possible to decrease data transfer by using a compression method or by limiting the use of graphics and multimedia files?

 

Different development teams will arrive at different answers, which is as it should be. There is no ‘one size fits all’ answer.


Detecting a Connection

One of the key elements of developing an occasionally connected application is the ability to switch seamlessly back and forth between online and offline modes. To facilitate this goal, one may find it useful to create a function that detects whether a connecti on is currently available. For example, Mobile Reference Application uses a Ping Web service, which the client calls periodically. This call is performed in the background so as not to interrupt the user.

The server exposes a function called Ping. Clients will call this function to determine if a connection can be established to the Web server. If the call is successful, the client application knows that it is online. If, however, the call fails, the application knows that the connection is down. The application can then switch to an offline mode. A Ping method was used because it verifies a number of things. First, it ensures that the client has a network connection. Second, and more importantly, it ensures that the destination Web service can be reached when the client application needs to send and retrieve data. If the Ping method can be called, then it is highly likely that the synchronization methods can also be called.

The code for the Ping method is as follows:

[WebMethod]

public void Ping()

{

}

 

Although simple, the Ping Web method provides a very fast, very efficient way to determine if a connection can be established to the Web server.


Asynchronous Communication

Another key aspect of developing an occasionally connected application is the necessity of allowing asynchronous communication. There are two primary reasons for this requirement. First, if the application performs all communication with the server synchronously and the connection is slow, the application will appear to hang until the request is complete. Depending on the amount of data being transferred, network bandwidth, and even server load, this can take anywhere from several milliseconds to several minutes.

Using asynchronous communication, this problem can be avoided by allowing the client application to perform other tasks while waiting for the communication with the server to complete. A second reason to use asynchronous communication is that the connection might be lost and may not be reestablished for some time. In this case, one will want to queue communication for a later time.

Fortunately, the .NET Framework* provides built-in support for calling asynchronous Web services. For every Web method that exists, Visual Studio .NET* automatically creates Begin and End methods. For example, if a Web service exposes a CalculateTotal Web method, there will also be corresponding BeginCalculateTotal and EndCalculateTotal Web methods.

As explained previously, the Mobile Reference Application server exposes a Ping Web method. To call Ping asynchronously, Mobile Reference Application uses the BeginPing and EndPing methods. When calling the BeginPing method, a callback routine must be passed in. A callback is a type-safe function pointer that designates what routine to invoke when the call to a particular method is complete.

private void tmrPing_Tick(object sender, System.EventArgs e)

{

System.AsyncCallback myCallback = new

AsyncCallback(PingCallback);

pingWebService.BeginPing(myCallback, Connectivity.Online);

}

 

AsyncCallback is a multicast delegate that is used to reference the callback method invoked when the asynchronous operation is completed. The callback routine completes the asynchronous operation by calling the EndPing method:

private void PingCallback(IAsyncResult e)

{

try

{

pingWebService.EndPing(e);

Connectivity.Online = true;

}

catch

{

Connectivity.Online = false;

}

finally

{

this.Invoke(new SetPingStatusDelegate(SetPingStatus),

new object[] {Connectivity.Online, e.AsyncState});

}

}

 

One should also note the use of Connectivity.Online. This is a boolean value that is used to keep track of whether the application is currently online or offline. Also note that all the code inside the callback method is enclosed with an exception handling block. Just because the callback was invoked, it does not mean that the Web service call was successful. The callback will be invoked when the Web method returns successfully, or if the call times out. The only way to determine if the call completed successfully is with a call to EndPing. If the Web method failed and timed out, then this call will throw an exception.


Synchronizing Data

Mobile Reference Application allows real estate agents to add and modify house listings. All changes are cached to the client-side database running on the mobile PC. If Mobile Reference Application is online, those changes are immediately uploaded to the server. However, if the application is offline, Mobile Reference Application must wait until the connection can be reestablished before uploading changes. This process is called synchronization.

To perform data synchronization, Mobile Reference Application has a SetPingStatus routine. SetPingStatus accepts two parameters. The first parameter, online, is a boolean variable that indicates whether the application is currently online. The second parameter is called previousState. This is also a boolean variable, and it indicates whether the application was online the last time that the Ping Web method was called.

The two variables used in the SetPingStatus routine determine whether the connection had been previously severed and has now been reestablished. Simply check the values for online and previousState.

private void SetPingStatus(bool online, bool previousState)

{

if (online == true)



{

statusBar1.Panels[1].Text = "Online";

Application.DoEvents();

if (previousState == false)

{

DataAccess._dataAccess.SyncUp();

}

}

else

statusBar1.Panels[1].Text = "Offline";

}

 

If online is true and previousState is false, the application knows that the connection has just been reestablished. The database may have pending changes that need to be uploaded. The application determines which records need to be uploaded by examining each record's status and date-time stamp field. The status and date-time stamp field are set every time a record is changed on the client-side database. This makes it easy to determine which records need to be uploaded and which ones do not.


Summary

Mobile Software Initiatives (MSI) is a new model for developing client/server or n-tier applications. As the latest advances in mobile PC technology become more prevalent, an ever-increasing number of users are choosing to use their laptops as their primary computers. Even those that prefer desktop computers want to remain productive on the go. Therefore, the primary goal of MSI is to allow users to remain productive without an active connection to the server.

Several techniques were discussed that are useful in creating occasionally connected applications, including determining whether the application is online, asynchronous communication with Web services, and data synchronization. There are many techniques a developer can use when implementing a MSI solution. This paper provides a starting foundation for creating MSI mobile applications.


Additional Resources

Articles

 

Developer Centers

 

Other Resources