Developing Smart Client Applications with the Offline Application Block

Submit New Article

February 28, 2007 12:46 PM PST


Introduction

By Douglas Reilly

Code libraries may be the key to developing intermittently connected applications. Find out how.

One of the hardest parts of building a mobile application that will be intermittently connected is properly reacting to changes in connectivity and “degrading gracefully” when the user is not connected to the network.

Developers for the Microsoft .NET* Framework can find help from the Microsoft Patterns and Practices group, which produces books and white papers on best practices, as well as Application Blocks—code libraries that address common development scenarios.

One of the most interesting Application Blocks for mobile developers is the Smart Client Offline Application Block* (SCOAB*), which includes most of the code required to support intermittently connected applications, including:

  • Detecting the presence or absence of network connectivity, allowing the application code to react accordingly
  • Caching data so that the application can continue to function even when a network connection is not available
  • Synchronizing client application state and data with the server when a network connection becomes available

Allowing an application to operate offline is not always appropriate. For instance, if you are creating a system for use inside a hospital, where patient admissions and discharges are very common, a device that is disconnected even for a couple of hours might become hopelessly out of date. On the other hand, a similar system for use by visiting nurses might be very appropriate as an offline application. Visiting nurses often see the same patient a number of times a week for long periods of time. Even if a new patient is to be seen, an offline device might reasonably be able to connect quickly enough to collect that single patient's information even over a cellular or dialup connection, and even if it could not, the information for the single patient can be reasonably entered by the nurse in the field.

Installing the Smart Client Offline Application Block

Installing the SCOAB is easy. You download a Windows* MSI file and install it by double-clicking on the file. After installation, there will be a number of new folders in your Program Files folder (in my case, all were under C:Program FilesMicrosoft Application Blocks for .NetOffline). In the QuickStarts folder under the Offline folder, you will find a number of quick start project folders a couple of levels down. I first opened and tested the ConnectionManagementQuickStart project, and it compiled and worked immediately. There are also links to the various examples in the Program menu, under Microsoft Application Blocks for .NET program group.

A number of other included projects did not immediately work, and when I checked references, I discovered some tie in to other Application Blocks, specifically the Exception Management Application Block, the Data Access Application Block and the Caching Application block. I installed those Application Blocks, and all examples compiled properly. At least one of the sample applications—the Insurance Claims example—requires creation of an MS SQL Server* (or MSDE*) database. The SQL create script is inc luded in the project folder.

The code provided in the SCOAB can be easily used as is or easily extended to suit your needs. On the other hand, Application Blocks are not complete applications, nor are they designed to be. In addition, the Application Blocks—SCOAB included—are not magic bullets that you can add to an existing application and make it an offline application. You should plan the application with the SCOAB in mind. When you install the SCOAB, it installs a number of Visual Studio* .NET Solutions. I first explored the Offline Application Block project. Figure 1 displays the structure of the Offline project in the Offline solution. There are a number of folders, such as Builders and ConnectionManagement, as well as a project below for OfflineProviders.

Figure 1. Structure of the Offline Application Block Project

Stepping Through the Examples

The easiest example to test is the ConnectionManagement quick start. This sample application allows you to simulate going on and off line. However, it only exercises the Connection management portion of the SCOAB. A more complete example is the Insurance Claims Client.

In the Insurance Claims example, rather than just testing for the presence of a network connection, you can actually see how changes to data are cached locally for transmission when the application can once again connect. The application allows you to download data to use locally while connected and then allows you to force the application offline, edit data and then reconnect and synchronize the changed data. Figure 2 shows the screen as an address is edited offline.

Figure 2. The Insurance Claims form while editing address offline

Given the current implementation of this example, if you were to exit the application before going online again, the changes would be lost. Again, it is important to remember that this is an implementation detail and not a limitation of the SCOAB. In the Insurance Claims example, the data on the “server” (the data that the application “downloads”) is in an XML file. There is nothing preventing a program using the SCOAB from storing the changes in an XML file or even a database in the file system local to the application.

Some of the files used to download data in this example are:

App.Config – Specifies configuration information for the application. This is an interesting file, in that it exposes a number of the details of how the system can be expanded. One thing that is obvious is the extensive use of the Provider model.

Controller.cs - Manages the interaction between the connection manager and the service agents. It registers itself to get notification of connection state change. It also creates an InsuranceClaimsClientServiceAgent and registers with it to initiate the transfer of work items.

InsuranceClaimsClientServiceAgent.cs - Initiates upload and download of the Work item information.

OnlineProxy.cs - Interacts with the remote service. In the Insurance Claims example, this is a Web Service.

I looked at the C# version. There are corresponding Visual Basic.Net files as well.

The Web Service used by this example exposes two Web methods, DownloadWorkItems(), which returns a DataSet, and UpdateWorkItem(), which expects a DataSet as a parameter. The UpdateWorkItem() method uses the Update method on a DataSet with the server-side rows, passing in the modified work items. This is a reasonably simple implementation, and again, in the real world, you would need to provide a more robust solution. The Web.Config file has an appSettings section that allows the connection string to be configured.

Exploring Ways to Expand the Smart Client Online Application Block

As previously mentioned, the SCOAB makes extensive use of the provider model. There are a number of providers that can be written to allow different behaviors.

The WinINetDetectionStrategy.cs file (highlighted in Figure 1) is an example of an area where the default behavior provided by the SCOAB might be adequate, or might not be. In any event, this bit of code in the application can be easily replaced with code of your choice. The WinINetDetectionStrategy class is a simple implementation of the IConnectionDetectionStrategy interface, and a class that implements that interface can be substituted for WinINetDetectionStrategy when you use the SCOAB. The default implementation provided detects only that there is any network connection (using InternetGetConnectedState() from wininet.dll). Other implementations might either detect a connection over a proprietary interface, or more likely, check not just for a network connection, but also to see if a particular server is available. The IConnectionDetectionStrategy interface defines a single property (read-only, PollInterval) and a single method (IsConnected(), which returns a bool indicating whether the implementation class thinks it is connected).

The Cache Block provides a number of Cache Storage Providers, including MSDE, In-memory and isolated storage and SQL Server as storage providers.

The Offline Block provides MSDE, In-memory, isolated storage and Message Queuing as queue storage providers. You could create a provider to queue requests to a different database or queue.

The Common Block provides the Data Protection API as its encryption provider. You could create a custom provider if the Data Protection API is not sufficient.

Conclusion

Microsoft Application Blocks are a great way to create an application that is extensible and flexible. They also serve as good examples of the use of the Provider model, which is increasingly important in Microsoft technologies.

What all Application Blocks, and the Smart Client Offline Application block in particular, do not do is provide a one-size-fits-all, plug it in and go component for adding functionality to your application. You cannot take existing code and add the SCOAB and suddenly have a mobile application. But if you are in the process of designing an application that will need to perform reasonably offline, the SCOAB is a good tool to allow you to create an application that perfectly meets your needs.

Additional References

For more information about all of the Application Blocks, go to http://www.microsoft.com/resources/practice s/code.mspx*.

Smart Client Offline Application Block can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyId=BD864EB5-56B3-43A5-A964-6F23566DF0AB&displaylang=en*.

A great article describing the provider model can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp02182004.asp*.

About the Author
Doug Reilly runs a small consulting business, developing mobile and Web applications (and sometimes mobile Web applications) for organizations in the healthcare field. He can be reached at doug@accessmicrosystems.net.