Life is pretty exciting for a .NET developer these days. There are so many cool things that can be done with applications today, including extending their reach. In this two-part series we'll look at the technology and tools used to add mobile accessibility to Web applications. One of the easiest ways to introduce this type of development is to look at an existing system and talk about its support for mobile devices. As an example we'll use Quilogy's system, which utilizes ASP.NET Mobile Controls, known as the Microsoft Mobile Internet Toolkit (MMIT) before VS.NET 2003.

Differences in Browsing Experience
When looking at how to design applications that will support mobile devices and PCs, you should consider the characteristics of the devices. These characteristics include display, input, connectivity, and data storage. The characteristics will place devices into three categories: mobile Web browsers, smart devices, and PC browsers. Consider Table 1.

The display capabilities of a device can be broken down into screen size (rows and columns) and color capability. Obviously, a device with higher resolution can show more information and have better viewing quality. A device that can additionally display multiple colors and images is a better choice but will cost more.

The input category has several functionalities. A pointing mechanism is usually implemented via a stylus, or mouse, or manually using keyboard directional keys. Character input is usually very slow, so applications are constrained to receiving information instead of entering information. Some devices do include a small keyboard or support a keyboard attachment. As is in the display category, the PC is the best scenario for this but not the most inexpensive mobile platform.

Connectivity and bandwidth are essential elements to any device that communicates. As the networks for these devices increase in speed, the functionality of mobile applications increases. While a PC connected via a NIC (network interface card) is the fastest, cellular companies are pushing their networks to attain 56KBs speeds and someday even higher.

Data storage allows a device to hold data and therefore not require a persistent connection to the Internet or local network. Synchronization to other traditional data sources is a related function. Mobile Web browsers do not support this functionality.

The mobile Web browser category has millions of devices "out on the road." There are several reasons for this, including the ability for voice communications (like a cell phone) and the ability to access e-mail (like a Blackberry). Another interesting twist is that the smart-client devices have built-in browser support so they have the capabilities of the mobile Web browser category. Considering the growth of the Pocket PC Phone and Smartphone, this category of devices is growing quickly.

These services, combined with inexpensive usage, mean that building applications that support mobile Web devices will allow a growing number of users to access company applications.

Our systems at Quilogy support four sets of clients: the vendors that we represent, the clients who are engaged with us (to see project management reports and training information), the public (marketing our services and recruiting), and our employees. Since there are many roles at Quilogy, the internal systems cover a lot of areas (resource scheduling, project management, financials, time entry, HR services and documents, CRM, etc.). Our systems have evolved over the years and encompass much more than this list. (We could easily write a small book about any of our modules.)

To satisfy these needs and provide access to our clients, we maintain a public site, at www.quilogy.com and we have an internal site that we call MyQ. MyQ is Quilogy's intranet system that integrates personal, customer, and financial data for Quilogy employees from data sources that include Microsoft Exchange, Microsoft SQL Server, and Great Plains. Both of these sites have been developed with Visual Studio .NET incorporating ASP.NET.

These applications not only work well, they are also essential to Quilogy's daily activities. There is just one problem. If they were just standard Web applications, they could be used only from a PC browser connected to the Internet. While it's nice to access MyQ from home as well as from the office, a percentage of our employees need access to this information while on the road. It may be a salesperson or project manger in some market traveling from client to client, or it may be an executive traveling from city to city.

For example, we like using notebook computers. We like the screen size, the keyboard, and the speed at which they operate. However, they are not as convenient to use as mobile devices to connect to the Internet at any time. This is due to the constraints of cost (hardware and monthly connection service), speed of remote connections like GPRS, limited battery life, and availability of connection services.

Being a technology company, we are gadget freaks, and so the range of devices carried by employees runs the gamut from cell phones, to Pocket PC Phones, to Blackberrys, to Palms, and others. But how would we support all of the markup languages, screen sizes, resolutions, and form factors used today? Quilogy's systems support these devices and we haven't implemented a standard that limits which devices an employee can use. Would you like to know our secret?

ASP.NET Mobile Controls
Quilogy is heavily invested in .NET, and thus we use ASP.NET to develop our Web sites. The ASP.NET Mobile Control technology is an extension of ASP.NET, and it allows any Web developer to become a mobile developer in a very short time by using the ASP.NET architecture to its fullest potential. Mobile Controls recognize the type of device making a request, and respond in the correct markup language. Currently, ASP.NET Mobile Controls supports HTML 3.2, cHMTL, WML, and XHTML, providing the ability to support over 200 devices. The current device list is at http://msdn.microsoft.com/vstudio/ device/mitdevices.asp, which includes tested emulators.

As with desktop and standard Web applications, Visual Studio .NET is the IDE for ASP.NET Mobile Controls and therefore the developer will perform the same development tasks for Mobile Control pages as for traditional Web pages. For example, the developer will have a familiar designer, code behind model, data access techniques, event architecture, etc. If someone were to look at the code, it might be challenging to guess if the code supports a Web Form (ASP.NET) or a Mobile Web Form (ASP.NET Mobile Controls).

ASP.NET Mobile Controls is also smart about supporting a myriad of devices. Not only will it respond in the correct markup language, it will also understand how a device is capable of working with a certain control. For example, one of its features is pagination, which is the ability to automatically break up a form or control into sizes and renderings that can be easily navigated on the device. Another capability allows controls to render themselves differently based on the device. For example, the way a Pocket PC displays a ListBox is very different from how a typical cell phone (i.e., a WAP device) would render. The image control also can behave differently based on the device and includes an ability to have a lesser (lower resolution, different size, different format) image and alternative text. Mobile Controls is smart about these situations so that developers can work with a single set of code and controls.

Another bonus of this technology is the issue of additional hardware, software, and cost. If you are hosting ASP.NET applications written with VS.NET 2003, you have all that you need. If you are developing with ASP.NET v1, then you require MMIT, which is a separate download from MSDN. For best results we recommend upgrading to 2003 and applying the latest device updates, which are available from MSDN's Mobile Control site (see resources at end of article).

Application Architecture
The list of products needed to support Quilogy's environment is short but comprehensive. We are using Windows 2000 Advanced Server, Active Directory, SQL Server 2000, Exchange Server, MS CRM, Great Plains eEnterprise, and Windows Media server.

For each of our business processes that is using some type of automation, we had to make a traditional decision about whether to build or buy. We have cases where we built functionality from scratch, bought products because they provided functionality, and combined custom functionality with a product offering.

One of the benefits of building this system using ASP.NET and ASP.NET Mobile Controls is that we and our clients can access important functions at any time and from anywhere, needing only an Internet connection. We also made a decision to separate business logic from the presentation tier, and place it in the middle tier, creating a loosely coupled architecture. Although a simple point, creating "business objects" allows other presentation platforms to be developed without creating entirely new applications. In years past, n-tier design was done for pure maintainability of code, but now the existence of other presentation platforms is a real design issue. Our CTO has now built a VoiceXML tier that accesses these same business objects.

When specific functionality is identified as being needed for the mobile device browsers, we create a second form that is a smaller version of an existing large Web page. We have already mentioned that mobile Web devices are constrained for data entry, so these pages typically serve for the retrieval of data. (We advise consulting your local human factors expert when doing these types of designs.)

The result is that we have two Web pages that access the same "business object." The large Web page (the standard Web page) will service the PC browser. A small page, built with ASP.NET Mobile Controls, will service the mobile devices.

Figure 1 illustrates this idea. Notice that the three categories of devices mentioned earlier are on the left, accessing the two Web pages in the presentation tier, and the Web pages are using the same business logic, which has the ability to access back-end data sources.

In this scenario, the "business object" can be a lot of different things. The list of possibilities gets longer every day, but typical examples might include .NET classes, XML Web services, COM+, BizTalk, or even a stored procedure in SQL Server.

Comparing a Large Page to a Small Page
Let's look at how we designed our Web site for both large and small browsers. If you were to look at our main page at www.quilogy.com, it is very different when viewed on different devices. Looking at Figure 2, you can see that the PC version has many features, including navigation, information, and color. However, if you access this site from your cell phone, it appears quite different, as shown in Figure 3. The main menu is not as exciting, but the navigation is similar. And even though the URL is the same, these are two different Web pages. This is accomplished in our main page, by ASP.NET Mobile Controls code that directs mobile Web browsers to our ASP.NET Mobile Controls pages. Note: This ASP.NET Mobile Controls page is being rendered by the Ericcson R380 emulator.

Let's look at MyQ, our intranet site. It also has large-page and small-page versions. The large-page version shown in Figure 4 is organized and yet contains lots of information, including streaming video, links and menus, and images. Figures 5 and 6 show emulators displaying our Mobile MyQ main page. The first is a Pocket PC emulator, and the second is the Ericsson emulator. These devices have different menus due to their different capabilities.

Conclusion
ASP.NET Mobile Controls is a great way to give your users access to important information from many mobile devices using one set of code. This is not "bleeding-edge" technology, as demonstrated by Quilogy's implementation. We further attempted to show that this is an extension of Visual Studio .NET and ASP.NET development and thus provides for reuse of business logic developed for your existing Web applications. We would recommend that you look at the resources provided in order to further explore ASP.NET Mobile Controls' value to your company.

In the second article in this series, we'll examine wireless financials and more ASP.NET Mobile Controls. Then, in the coming months, we will look at the mobile application landscape and drill down into the mobile technologies provided by .NET. We look forward to your feedback on what you are doing, where you are going, and what you see out there as opportunities and roadblocks.

Resources

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5
• Figure 6
• Figure 7