The Compact Framework and SDP in Context

As noted in the previous sections, the Compact Framework is targeted at a subset of the mobility platforms currently supported by Microsoft. In a nutshell, you can (and in our estimation should) consider architecting and building your applications using the Compact Framework and SDP when the following are true:

• You are developing or architecting business applications as opposed to system software.

• You are developing code that will execute on the device, as opposed to applications developed with the ASP.NET Mobile Controls.

• Your applications must run in disconnected, connected, or occasionally connected modes.

• You are targeting the Pocket PC 2000, 2002 or embedded Windows CE .NET platforms.

In addition, and as you'll learn by reading this book, the Compact Framework and SDP offer a highly productive development environment. This is primarily the case because, like its desktop cousin, the Framework, the Compact Framework offers a managed execution environment that includes a variety of services from object management to garbage collection to runtime security, freeing developers from having to perform these time-consuming, but ultimately unproductive, tasks.

Also, as we'll discuss in the next chapter, the Compact Framework includes a core set of framework classes that provide reusable code to handle file I/O, XML processing, and local and remote database interaction and even to incorporate XML Web Services into your applications.

However, because the Compact Framework is a managed environment, each device that executes applications written using the Compact Framework must have the framework installed. As of this writing, there are no devices shipping that include the Compact Framework as a standard component in RAM or in ROM; however, look for future devices (Pocket PC 2003, for example) running Windows CE .NET to include the runtime.

Many developers new to developing for mobility are at first confused by the differences between the Compact Framework and ASP.NET Mobile Controls. For those readers, and to explain why there is scant Mobile Controls coverage in this book, the following section goes into some detail as to the purpose of the Mobile Controls and the kinds of solutions for which they are appropriate.

The Role of the ASP.NET Mobile Controls

It is appropriate at this point to compare and contrast the Compact Framework with the ASP.NET Mobile Controls. The key points of similarity and difference can be summarized as follows:

• The ASP.NET Mobile Controls are a server-side technology, whereas the Compact Framework is a client-side technology. This means that code written using Mobile Controls must execute on a server, not directly on the device, by producing markup language that is interpreted by the device using a browser or parser. Code written for the Compact Framework executes directly on the device using just-in-time (JIT) compilation and native execution. This concept is illustrated in Figure 1-3.

  Figure 1-3. Comparing ASP.NET Mobile Controls and the Compact Framework.

  

• The ASP.NET Mobile Controls are based on ASP.NET and use the ASP.NET HTTP runtime to handle and process requests via a set of ASP.NET server controls specially designed for small form factor devices. This means that Mobile Controls require an ASP.NET Web server (Internet Information Server [IIS] 5.0 or 6.0). The device issues requests that are processed on the Web server by the controls, producing markup language.

• Both ASP.NET Mobile Controls and the Compact Framework are based on the desktop Framework and VS .NET. In the case of Mobile Controls, developers use VS .NET to write ASP.NET code using the ASP.NET Mobile Controls. The server-side code is JIT-compiled and executed on the Web server by the common language runtime. In the case of the Compact Framework, the code is written using SDP and subsequently downloaded to the device for JIT-ing and execution using a compact version of the common language runtime.

• The ASP.NET Mobile Controls are more flexible in that they can dynamically produce various markup language, depending on the requesting device that is dynamically detected, including WML, cHTML, HTML, and XHTML. This means that Mobile Controls can support a broader range of devices (over 200 at last count), including wireless Web phones, Pocket PCs, and virtually any device that supports HTTP and HTML. The ASP.NET Mobile Controls also include the ability to add device-specific customizations, so that as new devices come online, their feature set can be identified.

• Because code written for the Compact Framework is downloaded to the device, the Compact Framework supports connected, occasionally connected, and disconnected scenarios. ASP.NET Mobile Controls support only the former because an HTTP connection is required to request an ASP.NET page that uses the Mobile Controls. Basically, this means that Mobile Controls are targeted for building Web sites for a broad variety of connected devices and, at the same time, not having to rewrite the vast majority of code to deal with differences between those devices.

Because of these basic differences in the kinds of applications, we decided it would not be appropriate to include the ASP.NET Mobile Controls in the discussions in this book. In addition, there are a number of good books on Mobile Controls (formerly MMIT) already in print and forthcoming that should provide you with adequate information to make architectural decisions. See the "Related Reading" section at the end of the chapter for a few suggestions.

The lack of coverage of Mobile Controls should not, however, be interpreted as a lack of enthusiasm for the technology. There is a large class of applications for which ASP.NET Mobile Controls are perfectly suited, for example, those developed by our own employer, Quilogy.

Quilogy Uses MMIT to Streamline Internal Processes Quilogy (www.quilogy.com), a 300-person IT consulting and services firm headquartered in St. Charles, Missouri, had been using wireless technology since 1999, when it deployed its first internal application using custom ASP pages that produced appropriate markup languages such as WML. Even before the release of the Mobile Internet Toolkit in 2002, Quilogy had started to rewrite its wireless applications using the beta version of the product built on top of the Framework and ASP.NET. With its release, Quilogy Wireless was born, and it now supports many of the functions of Quilogy's award-winning Intranet portal, myQ. Quilogy Wireless on ASP.NET Mobile Controls allows Quilogy's geographically dispersed workforce (300 employees spread across 15 geographical locations) to get an integrated view of company information that is customized to their location and job role using a PIN-based logon. Some of its functionality includes viewing and responding to action items (such as approving expense reports and performing timesheet entry), accessing Microsoft Exchange e-mail and calendaring, viewing company financial information directly from the Great Plains office, viewing customer demographics, locating other employees, viewing company news, viewing recruiting and headcount information. As a result, Quilogy's sales force, managers, and many of its consultants use Quilogy Wireless on wireless Web phones, Pocket PC phones, Palms, Blackberries, and other devices. This allows sales consultants to get the latest information on customers and management to respond to changing financial situations and employee activities in a timely fashion. For a more in-depth look at Quilogy's use of MMIT, see the article "A Quilogy MMIT Case Study" at http://atomic.quilogy.com/default.aspx?storyid=mmit1. Quilogy also offers its customers wireless access to their own Exchange server or through its hosting service.