Reliance on wireless access points for communication between traveling employees and company databases is growing. Long, irritating delays to completing a job due to seeking a strong enough internet connection in order to transmit and receive data can slow down human productivity. By adding a local write-through/offline cache to an application, employees can retain user control of the software and the application can follow through on server communication when in range of internet access without human supervision. Functions now available using Intel® Mobile Platform Software Development Kit 1.2 help to enable this method.

With the advent of wireless connections, more and more businesses are choosing to rely on “instant” communication between customers, employees and a remote database of information for daily operations. When your plumber has finished fixing your leaky sink, he opens up his laptop, enters his logged hours, and sends that information to the company database. But what happens if he can’t get connected? Or what if data is sent, but the connection gets dropped and he doesn’t receive a confirmation? An efficient and flexible application is necessary to smoothly handle the unpredictability of wireless access when information is being exchanged.

Utilizing Intel’s Mobile Platform SDK 1.2 application programming interface (API) and implementing an offline cache can adapt a program to handle fickle wireless connections, while allowing users to continue working with confidence.

Let’s look at an example of how an application with this functionality might work. Sally is a medical supply representative who goes out and sells to doctor’s offices in her west coast territory. Every time she makes a sale, she needs to send the purchase order information to her company’s database. Sally needs to get her order in as quickly as possible so that inventory is kept current.

If there are no wireless access points nearby, she may waste precious time trying to find a strong signal when she could be making another sale. With her application enhanced with the Smart Update plan outlined below, she requests the program to send in the sales data. The application notifies her that there is no internet connection at present, but it will send the data as soon as one becomes available. Sally gets in her car and drives to the next office. While on route, Sally passes through an area with a strong signal from a wireless access point. In seconds, her computer logs on and the program sends her information to headquarters. When Sally gets to the next office, her inventory quantities are updated and her application is ready to accept her next order.

Now let’s look at how to implement this.

Figure 1 shows the improved data workflows that better handle offline activity. To design a program that monitors internet connection and data sending on its own, a background thread is needed. The main function of this thread is to check for connection to the internet, and, when it is available, to send whatever data is ready. Separating these functions from the main application thread will allow that thread to continue handling user requests while data is sent and received on the background thread. First, the main thread saves the data into the cache structure.

Why should this be done before checking the connection? As mentioned in the introduction, the connection to the internet could be lost after the program sends the data. If the send is not successful, it will be necessary to send the data again.

Figure 1. Main Data Flow of the Smart Update Plan

The background thread will initially idle, waiting for data to be added to the cache. This method should be employed when the need for an internet connection is relatively rare; for instance, when the previously mentioned plumber needs to log his hours after every job. If a connection is required frequently, or most of the time, then the background thread can just as easily be set to monitor internet connection continuously. For this walk through a fairly rare connection is needed. When the cache is not empty, the background thread creates an instance of ConnectivityInstance and checks for a valid internet connection using IsConnected, an instance property. If there is an established connection, the method IsReachable() can be used to confirm the link is established and then the data is sent from the cache. Each transmission of data is checked for success. Failure to receive a confirmation from the database will prompt the background thread back into the loop waiting for a connection. After the successful confirmation of the transmission, the data is removed from the cache. Once the cache is empty the background thread closes the established connection and returns to waiting for new items in the cache. Just before the program closes down, the background thread is destroyed.

A key element in setting up a “network aware” application is to create an offline cache for the information that is being sent. This can be a simple hash table or a linked list that holds data until a database can be contacted. Because the data is written to the database as soon as possible and not only when it is evicted from the cache, the cache is a write-through cache. But this storage can operate as longer term storage when a network connection is not available. Storing data for longer periods brings up another issue. If a user requests a data point that has already been modified and is stored in the cache awaiting internet connection, then the cache should be searched before that request is added to the cache . If the data is available, then it can be retrieved locally regardless of network connectivity. A linked list can be used efficiently to ensure database updates are applied in the correct order and is easy to search for previously stored data.

The functions that are mentioned in the plan walk through are all from the Intel Mobile Platform SDK 1.2. This API is designed to handle the sometimes or occasionally connected state in mobile devices. Because this SDK is an open source project it is possible to see how the code is put together. A portion of the connectivity code is based on Microsoft’s Windows Socket 2 API. Intel has developed easy to implement objects and methods that can be quickly added to stand alone applications. In addition, code use examples are included for C++, C#, and Java. There is also a Programmer’s Guide in the Document folder which is very helpful to reference during the development process.

Alternatively, the Windows Socket 2 API alone can be utilized on its own. In order to use any of the Winsock 2 functions you will need to include either Winsock2.h or use the Ws2_32.dll, depending on what type of code you are developing. There are actually several functions you will likely need to use. Some of the more common ones are listed below:

Below is the pseudo-code for the functions that are proposed in this article. It details how this smart update could be accomplished by using three functions on the backgrou nd thread and two functions on the main thread. It follows the data flow diagram shown in Figure 1.

If the data to send is a request for a data point, check first to see if that data point is in the cache. If it is, then let the program know so another function can be called to retrieve the data point and return it to the user. The function SearchCacheForData Requested below is pretty straightforward:

The background thread functions are listed next. The first function is incorporated into the thread run function meaning the function which checks for stop, run, and reset events.

The last two functions handle the data sending and removing successfully sent data events.

There are many ideas and solutions for handling synchronization and updating of data by way of the internet. Google has introduced three modules collectively called Google Gears which provide solutions for this problem and several others revolving around web applications. The reader is encouraged to examine all possible ways and means to accomplish the answer best suited to their goals.

This solution doesn’t take into account all of the possible scenarios when dealing with communication between a mobile application and a remote server. It doesn’t try to handle a multiple internet connection situation, although as the number of access points increase, so will the possibility of having two or more connections from different sources. Another scenario that is not investigated is how the application handles data in the cache when the program is being shut down. In addition, there is no consideration of how the database would handle an update of the same data by more than one person at a time. That problem has more than one solution and is beyond the scope of this paper. Similarly, the successful negotiating of access to a network for wireless internet connections from inside the application is not addressed.

Many database applications use managed code, and for more detailed code samples of the Windows Socket 2 functions, read Network Awareness in Windows XP . That paper also goes more into detail about all the information you can obtain on each of the possible network connections you find when running the Winsock 2 DLL.

This article reviews an idea for making database information exchange easier for those who take their laptops with them on the go. Microsoft’s Network Location Awareness API has improved our ability to detect connection status inside running applications, whether they are wireless or wired. This ability has suggested the Smart Update plan, where data is sent when an internet connection is wo rking, and saved to a cache when the mobile device moves out of access range.

A “network aware” application can send the data in the cache as soon as another connection can be located and access granted. This saves time for the user as they don’t have to hang around trying to locate a strong enough signal to allow them to send data before they move on to another location. The mobile population is enabled when computers can relieve rather than cause frustration.

Judy M. Hartley is a Software Application Engineer in the Software and Solutions Group. She earned her B.S. in Computer Engineering at Virginia Tech in 2001. Right after graduation, she began working for Intel, moving almost 3000 miles to Chandler, Arizona. As a Product Development Engineer she worked on testing and production readiness of set-top box chips. Because she missed the rain, in 2005 she relocated to one of Intel’s northwest locations and turned her attention to software and software enabling.