The Mobile Line of Business (LOB) Accelerator 2008 is an enterprise mobile application demonstrating how a hypothetical hardware distributor could use Windows Mobile devices to support the sale and distribution of hardware goods. It can be used not only as a functional example of best practices, but also as a foundation for your next Windows Mobile development project. Don Overlander provided a high-level overview of the new 2008 version of this example in the last issue of the magazine (June/July ‘08, page 62). As one of the members of the team that built the Accelerator, I would like to dig a little deeper into the underlying architecture and explain some things in greater detail.

Infrastructure architecture

The new infrastructure architecture is much more complex than the original Mobile LOB Accelerator (see Fig. 1). The original version used Merge Replication and talked to MapPoint. The new version is a multi-tiered solution that requires the end-users to have Windows Mobile devices (although both Windows Mobile Professional and Standard devices are supported from a single code base). The devices, while fully self-contained, need to occasionally interact with three services: Virtual Earth, sync services, and Direct Push e-mail via Microsoft Exchange 2007.

An IIS server runs a Web service for synchronizing data to SQL Server using the new ADO.Net for Devices. This replaces Merge Replication, although if you look through the code you can see where we upgraded Merge Replication using a sync client metaphor.

The Exchange server is an optional server component for pushing notification out to devices. The notification lets the device know that there is data available for synchronization. It uses e-mail and Exchange ActiveSync to transport the message. This eliminates the need to constantly poll the sync server, which saves resources and bandwidth from unnecessary synchronizations.

Client architecture

The client code is partitioned along lines similar to most applications. There is the User Experience Layer, Application Layer (services and entities), and a Data Services Layer (see Fig. 2).

When the team started working on this project, one of the goals was to show the power of this type of client architecture. The team worked hard to maintain the original interfaces between the UI and application logic, which allowed for totally re-factoring the data layer without recoding the UI. Similarly, moving from Merge Replication late in the project to Sync Services had little impact on the UI.

Solution architecture

As an enterprise application, the solution consists of multiple projects. A lot of these projects were done to allow for easy re-use by developers, including:

• ctlSignatureCapture: A UI control for capturing a signature during the delivery process.

• Launcher: An application used to speed up the user's experience of launching the application.

• Microsoft.Mobile: A set of classes for accessing data by the business layer.

• StoreAndFwdTransport: Classes used by Windows Communication Foundation to push notifications to the device to perform synchronization.

If you do not need the functionality, you do not need to reference or include these projects. For example, if you don't want to use the store and forward communication to push out notifications in your applications, leave out the StoreAndFwdTransport. Similarly, if your mobile application is small, you might not need to use Launcher.

The remaining projects are specific to the solution and include:

• HardwareDistributor: The actual mobile client that supports all the roles within the organization that require the client.