Mobile CoDe.NET: Microsoft Mobility 101

Mobile CoDe.NET: Microsoft Mobility 101

obility is one of those fields which everybody knows is a definite part of our future, in 5 to 10 years or so. Think again.

Amber steps out of her client’s office, enters her car, pulls out her mobile phone and dials the number to her main office. She’s calling Martin?her internal sales representative to inform him that she finally closed a deal with her client. She needs him to place an internal order at the warehouse. There are many items on that order, including 500 units of product X, configuration A. After a quick query in the central inventory management system, Martin informs her that there are only 250 units left of that configuration, but there are more than plenty for her order if the client would be willing to switch to configuration B. Amber now needs to call her client back and save the deal. The client will be very disappointed, the whole thing will have to be negotiated over the phone, and Amber will probably have to cut her margins or else she’ll lose everything.

This scenario represents one of many that pain enterprises today. The client had several products to choose from and several configurations were available for each product. Amber couldn’t have checked for the availability of each product before her meeting, and even if she had, it was possible that another salesperson within the company might have closed a sale the same day for the same product configuration. Had Amber been able to check the inventory status of that product configuration during the client meeting using some remote access, she might have had the option to push for a different option in order to save the deal.

A mobile sales software solution connected to the central inventory management system could have avoided this situation and saved Amber’s deal. Using a wireless connection to the Internet, she could have logged on her corporate extranet via a mobile application running on her Pocket PC or Smartphone to check for product availability. She could have placed the order online then and there, thus saving her the call to the internal sales employee.

Mobile applications are just one more form of business software you have to learn to design and write. Not tomorrow… today! They open a new realm of possibilities for mobile workers and allow a new level of automation between people, businesses, and processes.

Third-party software packages are usually a good start since they are broadly available and cost a lot less than their desktop equivalents. But if you need software applications that are more specifically tailored to your enterprise needs, you’ll need to either build them yourself or have an external firm build them for you.

In this regular column I will explore how you can leverage enterprise mobility and Microsoft .NET to build new types of applications that maximize the productivity of your users and reach out to new users as well. While future issues will address specific topics and present in-depth technical samples and usage scenarios, think of this first foray as your Microsoft Mobility 101 crash course.

What Is Mobility? What Is It Good For?
Mobility?from the perspective of the IT world?is a broad term that binds together many concepts related to using computer devices while on the move. The first concept that typically jumps to mind is the notion of wireless connectivity. While wireless access to the Internet and your corporate intranet is often implied, it is not mandatory. Mobile applications are nothing new; it’s just that most of them were designed to operate offline with a local set of data that you synchronize with a central store whenever you reconnect the mobile device to the corporate network. The reason why mobility suddenly becomes so interesting stems from the emergence of new wireless corporate networking standards like 802.11b and the adoption of new standards by national telecom carriers for wireless data access on the road, such as GPRS or 1xRTT. More on those later.

The second concept usually associated with mobility necessarily involves various mobile devices. Those devices come in many shapes and form factors, including palm-sized organizers, clamshell-style pocket computers, Internet-enabled phones, and a whole plethora of other devices, from the pervasive iPaq to the more obscure TDS Ranger. Over the last few years, we have been witness to a massive explosion of “smart” next-generation devices, which led to an even greater enthusiasm for the world of mobility.

Those devices nonetheless come with a bad prejudice as being nothing more than overpriced useless toys meant for stuffy executives who seek bragging rights over their counterparts. Especially following the alarming implosion of the dot bomb in late 2000, our fledgling industry is coming of age and wariness has set in. While ridiculous ideas were an easy sell in 1999, solid no-nonsense ideas based on mobility are having a hard time leaving a mark in 2003.

It is true that most of these devices can seem pricey when merely evaluated as they stand out-of-the-box. You can get an electronic organizer or personal data assistant (PDA) for less than $100, so why spend $500 and more on an iPaq or a Toshiba e740? E-mail capabilities are a nice add-on but you also need extra hardware like a wireless Internet card and a data access plan with a carrier to fully use them. Read: more costs. Pocket Word and Pocket Excel are useful when you’re in a jam but they are pale shadows of their full-featured Windows siblings. So why would you buy such a device, let alone equip dozens of your employees or co-workers with them?

There is a common prejudice that states Microsoft typically gets things right on the third release, and while Windows CE has seen multiple major revisions between versions 1.0 and 3.0, version 3.0 did put Windows CE on the map for good.

The answer lies in the simple fact that while these devices may be pocket-sized they nevertheless remain full-fledged computers. And just like you couldn’t expect a simple computer-and-operating-system combo to be economically sound right out of the box, the same applies to mobile devices. The vanilla package isn’t good enough. You need to add flavor. You need to add software.

Third-party software packages are usually a good start since they are broadly available and cost a lot less than their desktop equivalents. One of the premier Internet Web sites for mobile device software shopping is Handango ( But if you need software applications that are more specifically tailored to your enterprise needs, you’ll need to either build them yourself or have an external firm build them for you.

The good news is that developing mobile applications?or mobile development as it is known?is a lot easier than it used to be. Up until the mid-nineties, mobile development was only one step higher than device driver programming. Nowadays?thanks to the proliferation of mobile operating systems?mobile developers can work at a higher level and focus more on the business problem and less on the low-level plumbing. In short, mobile development has finally caught up with traditional Windows or Web programming.

Let’s begin by exploring the basics of mobile development in the Microsoft world.

Microsoft Mobile Platforms
You will need a mobile platform before you can think about developing mobile applications. In order to use third-party or custom-built applications from the field, workers need a mobile device and mobile devices require a mobile operating system. Running a Windows XP-based enterprise application client on a disconnected notebook can seem like a good idea, but you should wonder if this is the best form factor for your usage scenario. What if you need to work while standing up with no table or counter for the notebook to rest on? What if you work in an environment harsher or dirtier than a corporate office like a construction site, a factory, or the great outdoors while you conduct field surveys? What if your mobile user requires a lighter form factor than you can tuck into a suit jacket or holster on a belt? The first lesson in mobility 101 I always teach is that you need to pick the right device for the job, otherwise you’ll end-up trying to fit a square peg in a round hole. The device itself can make a difference based on the hardware options, extensibility features, ports, and capabilities it sports. But the single most important decision you need to make before you can choose a device is about software. Devices run various inceptions of some mobile operating systems (OS) or another, and just like the desktop or server world, you’ll need to swear your allegiance to a mobile OS before moving on.

Microsoft has several options when it comes to choosing a mobile operating system. You will need to choose a form factor first since device operating systems are almost always embedded directly in the device itself. You can’t walk into a computer store and buy Windows CE off the shelf as you would Age of Mythology or Windows XP Home Edition. Microsoft licenses Windows CE to device manufacturers (device OEMs) like HP, Toshiba, and Dell, who in turn embed the OS on a chip or a Flash ROM in the device. You then buy the device in a store, ready to use and pre-configured with the mobile OS and default settings.

Let’s review the main operating systems available from Microsoft for mobility purposes.

Microsoft Windows CE
In 1996, Microsoft scaled down their Windows NT core operating system and announced a modular version for a broad range of communications, entertainment, and mobile computing devices. Windows CE was born. With a multithreaded 32-bit kernel and an open architecture optimized for real-time, Windows CE has the power to drive serious applications in any kind of device. Thanks to a scalable model, Windows CE can not only scale up to power feature-rich devices and appliances, but also scale down to less than 1 MB to provide basic?yet relatively powerful?system services in very compact devices. Upwards and downwards scalability may seem to be the main strength; however, the key innovation in Windows CE lies in its modular aspect. This modularity enables device manufacturers to “pick & choose” which components of the OS they want, thus streamlining their device by excluding superfluous modules and libraries that would add little value or drive up the cost of the hardware.

Now in version 4.2, Windows CE has been rebranded with the new Windows CE .NET moniker.

It is a well-known fact that Windows is a pretty hefty OS. With its thousands of modules, libraries, and DLLs, Windows provides developers with a deeply integrated and vastly wide array of rich application services, from the low-level 32-bit kernel to the high-level ADO data access library. This is how Windows developers can rapidly and efficiently build advanced applications with little low-level programming. But Windows is far too heavy and feature-rich to be squeezed in a limited form factor like a mobile device where significant constraints exist, such as processor, memory, storage, I/O ports, or battery life.

See also  Comparing different methods of testing your Infrastructure-as-Code

Besides, not every device needs all the features and parts in Windows. The classic “desktop” with icons, a taskbar, and a Start button may be familiar and ubiquitous on a desktop PC, but it is optional in Windows CE. Some devices?like the Auto PC, for example?opt for a more optimized menu-driven display and companion technologies such as voice recognition to capture user input. Or they might have no display at all where everything is “read” back to the user through a text-to-speech engine. This is but one example and OEMs have several customization options in Windows CE.

Windows CE provides a standard option for device manufacturers who would traditionally have designed and implemented their own proprietary environment, just like you might have seen in older devices in the 80’s and early 90’s such as HP scientific calculators or Sharp and Casio electronic organizers. Standardization promotes openness, which in turn brings variety and a wider choice for consumers.

OEMs use the Platform Builder included with every version of Windows CE to assemble and configure their custom version of the OS. Using the Platform Builder, a hardware manufacturer could start from a default platform configuration or build a custom configuration by going through several steps. Default configurations are very varied in the latest version of Windows CE and include smart phones, Internet appliances, set-top boxes, tiny kernel, PDA, and many more. I won’t dig too deep in the Platform Builder since, as a business applications developer, you probably will never have to use it as you’ll be relying on existing devices rather than design your own.

Windows CE 3.0 easily stands as the most common inception of the OS in that it is found in a majority of the most popular Windows CE-based devices today. There is a common prejudice that states Microsoft typically gets things right on the third release, and while Windows CE has seen multiple major revisions between versions 1.0 and 3.0, version 3.0 did put Windows CE on the map for good.

Now in version 4.2, Windows CE has been rebranded with the new Windows CE .NET moniker. The reason why most devices are still not running Windows CE .NET (even though version 4.0 was first released in January 2002) is you can’t buy Windows CE .NET from Microsoft directly as an end-user or download an update from Microsoft’s Web site. OEMs have to license the new version from Microsoft, adapt it to their devices, customize it based on the hardware features, and then test it extensively before publishing a new Flash ROM image. Only then will they make the new image available on the market through upgrade packs or direct download, and it won’t be free.

In future installments of this column, I will discuss Windows CE .NET more and more since this will be the primary target OS for many of my technical samples. For now, to obtain more information on Windows CE .NET, you can visit the Microsoft Windows Embedded Web site at

Pocket PC 2002
The term “Pocket PC” is like a Q-Tip or a Kleenex in that the name of a company’s specific product became the mainstream name for the product category itself. Granted, a Pocket PC sounds a bit more generic, but what is often implied is that a Pocket PC is a PDA running the Microsoft Pocket PC 2002 platform.

Microsoft Pocket PC 2002 is not an OS in itself but rather a specification based on the Windows CE 3.0 OS with additional shell extensions. Because of the modular nature of Windows CE, most pre-version 3.0 devices on the market ended-up running a whole slew of variant configurations of the OS. The end result made it very difficult for software makers and ISVs to support all these devices since they never knew if some component or another would be present. Microsoft decided to pick a standard set of Windows CE components themselves and publish them with a set of hardware guidelines as part of a specification. Many such specifications were released such as the Palm-sized PC or the H/PC Pro, but the most popular by far is the Pocket PC.

Think of Microsoft Smartphone devices as digital Internet phones with PDA-features whereas a Pocket PC Phone Edition device is a PDA with digital Internet phone features.

The Pocket PC specification is now in its second release, preceded by the original Pocket PC specification, now known as the Pocket PC 2000 specification, to differentiate it from newer inceptions. The primary competitor of the Pocket PC is of course the Palm OS?, which is the mobile operating system running on devices like the PalmPilot?, the Handspring? Treo or Sony’s Cli??. There are several times more Palm OS devices on the market today than there are Pocket PCs since Palm devices are cheaper. The main reason behind this takes root in the very light nature of the Palm OS, which can fit in only a few megabytes, in contrast to the Pocket PC 2002, which can require from 16 to 24 megabytes of ROM. Windows CE?and therefore Pocket PC?is much bigger than the Palm OS because it provides many more system services to developers. Consumers may prefer Palm devices because of their lower price tags, but as a developer you’ll be much happier in the Windows camp thanks to the many rich development services that are open to you. In any case, the lack of advanced services in the Palm OS is taking its toll on Palm and other competitors, and they are losing ground since more and more businesses are discovering the justification for the higher costs of devices powered by Windows when building mobile business solutions.

The following list gives you an idea of the hardware requirements for the Pocket PC 2002 specification:

  • Support Intel Strong-ARM processor family.
  • 240×320 one quarter VGA tactile LCD display.
  • At least 32 MB of RAM and 16 MB of Flash ROM for the operating system itself.
  • No built-in keyboard. Support for a software keyboard is built-in the shell extensions.
  • An Infrared port (IrDA).
  • A port for USB synchronization with a PC.
  • At least one expansion slot (Compact Flash, Secure Digital, PC card).

With such rigid requirements comes compatibility across devices, but also a lack of distinction between them. Some OEMs have managed to differentiate their devices from the pack with key features like the iPaq’s support for expansion sleeves or the Toshiba e740’s two built-in slots and wireless support. Other manufacturers are creating more specialized devices based on the same Pocket PC specification, such as industrial devices or “ruggedized” devices. The well-known consumer and corporate devices may be well suited for office workers, managers, and sales personnel, but if you hand an iPaq to a mechanic or field surveyor, the device probably won’t last very long. And even if your non-corporate user tried to be careful, what happens if it rains, oil spills on the device, or the environment is very dusty? This is why many companies, led primarily by Symbol Technologies ( and Intermec (, have been providing the market with specialized mobile devices for all kinds of harsh usage or environments.

OEMs that currently offer Pocket PC devices include Acer, Audiovox, Dell, Fujitsu/Siemens, HP, Intermec, NEC, Symbol Technologies, Toshiba, Viewsonic, and others.

Microsoft recently announced at its Mobility Developer Conference 2003 in New Orleans the next generation of Pocket PCs. Code-named “Ozone,” the new Pocket PC 2003 specification leverages Windows CE .NET 4.2 and will support many flavors, including an entry level Pocket PC and a keyboarded version. I don’t want to dig too deep into uncertain and variable directions, so I’ll focus on existing technologies for now. Don’t worry; I plan to keep you up-to-date regarding future developments in the Windows CE world in upcoming issues of CoDe Magazine.

Handheld PC 2000
Microsoft introduced yet another specification called Handheld PC 2000 for small clamshell-style devices, or micro-notebooks if you prefer. Preceded by the H/PC Pro, these devices may have been the first form factor on which Windows CE saw the light of day in 1996 and 1997 but their popularity dwindled because of their higher price and bulk. Featuring a wider screen and an integrated keyboard, these devices can double as light-duty laptop replacements.

With a bright 640×240 LCD color display, two PC card and Compact Flash slots and an integrated 56.6K modem, the most popular device in this category today is the Jornada 728. Other devices in this family include the Fujitsu PenCentra 200, the Intermec 6651 Pen Tablet (with a built-in camera), the NEC MobilePro 790 & 880, and a few others.

The lack of recent support for these devices, the increase in Pocket PC popularity, and the small number of Handheld PC 2000 devices have all contributed to a smaller future in this area. Unless Microsoft revamps the spec with Windows CE .NET 4.2, I suggest that you limit application projects for this form factor to niche and specialized scenario where there is no viable alternative.

Pocket PC 2002 Phone Edition
Microsoft Pocket PC 2002 Phone Edition is also a Windows CE specification, or more specifically, it is a variant of the Pocket PC 2002 spec for PDAs with built-in digital phone features and wireless connectivity to the Internet via carrier networks. Aside from the embedded wireless radio for GSM/GPRS access, these devices include a version of the OS prepackaged with a software phone dialer and additional tools and utilities related to telephony and wireless configuration.

T-Mobile was the first to introduce a Pocket PC 2002 Phone Edition device in the US market. Other companies that either announced or released devices based on this spec include Audiovox, PC-EPhone, Siemens, and Toshiba. Microsoft says the Phone Edition will be upgraded to Windows CE .NET along with the Pocket PC 2003. No dates for any version or variant of the Pocket PC 2003 have been announced.

Microsoft Smartphone 2002
Smartphones are the next generation of phone devices combining digital phone handset and wireless Internet connectivity with some PDA-style and mobile computer features. Eager to establish dominance in the world of mobility, Microsoft released another specification based on Windows CE 3.0 dubbed Microsoft Smartphone 2002. The term “Smartphone” isn’t exclusive to Microsoft since other Smartphone operating systems exist, such as the Symbian OS.

eVC allows you to build mobile applications for any Windows CE-based device, and it is the only option available today for Microsoft Smartphone 2002 development.

Think of Microsoft Smartphone devices as digital Internet phones with PDA-features whereas a Pocket PC Phone Edition device is a PDA with digital Internet phone features. These Smartphones may not be as powerful as traditional Pocket PCs, but they certainly lead the pack in the field of Internet phones. Features built-in the spec include an 65,000 color display, a Pocket IE HTML browser that supports graphics, Pocket Outlook, MSN Messenger, Windows Media Player for MP3/WMA/WMV playback, an integrated voice recorder and microphone, a speakerphone, built-in GSM/GPRS wireless radio with configuration utilities, and much more.

See also  Comparing different methods of testing your Infrastructure-as-Code

Currently, the Orange SPV is the only commercially available Microsoft Smartphone device, is sold in the UK through the carrier Orange and is manufactured by HTC. A Compal-manufactured device will soon be introduced in the US by Everlink Wireless. The manufacturers who have so far announced they would support Microsoft Smartphone 2002 include Compal, HTC, and Samsung.

Microsoft also announced a new specification will be introduced in the near future to upgrade the Microsoft Smartphone 2002 spec to Windows CE .NET 4.2. No dates have been released.

Field Guide to Microsoft .NET Mobility Technologies
It’s time we set aside operating systems and started discussing mobile development. You’ve selected a mobile OS; you’ve picked a device; so how do you build a custom business application for it? What tools do you use? Again, Microsoft has several options for you since various tools have been released alongside each new release of Windows CE and its variants.

Microsoft Embedded Visual Tools 3.0
During the first few years of Windows CE, Microsoft opted for an approach where a special mobility toolkit would be grafted inside of Visual Studio to enable Visual Basic and C++ developers to build mobile applications from within an IDE they were familiar with. While the idea was good, the toolkit lacked features and the integration suffered. Several toolkits were thusly released, either as Visual Studio add-ons or as independent environments, until the last pre-.NET release: Embedded Visual Tools 3.0 (eVT). The Embedded Visual Tools feature a separate development environment and provide two development language options: Embedded Visual Basic 3.0 (eVB) and Embedded Visual C++ 3.0 (eVC). The version number matches the version of Windows CE targeted by these tools.

eVB is an interpreted language that is slightly more powerful than VBScript. It lacks the advanced language features of Visual Basic 6.0 or Visual Basic .NET and provides very few options in terms of GUI custom controls. It requires a runtime which was embedded directly in the OS, but at least provided developers with a quick prototyping tool for mobility projects. eVB has virtually no future in the .NET era, so I won’t explore it any further.

Since the 802.11g hardware available today is based on a draft specification, I would steer clear of “g” hardware until the spec is final if I were you.

The serious option for mobile development once again rests on C++. Embedded Visual C++, now available in versions 3.0 and 4.0 depending on the version of the targeted OS (i.e., eVC++ 3.0 for Windows CE 3.0 development, and eVC++ 4.0 for Windows CE .NET projects), enables mobility developers to leverage Microsoft’s many SDKs for various mobile platforms, such as the SDK for Microsoft Smartphone 2002, SDK for Pocket PC 2002, and others. Note that eVC allows you to build mobile applications for any Windows CE-based device, and it is the only option available today for Microsoft Smartphone 2002 development.

Embedded Visual C++ remains a key tool in mobile development on Windows CE and many sources are already available on the topic, but since this column mainly addresses .NET mobility development, I won’t mention it too much in the future. To learn more about the Microsoft Embedded Visual Tools, visit the product Web site on the Internet at

Visual Studio .NET 2003
Whenever you start planning for a new software development project, as a business solution developer or architect a philosophical question faces you right away: should the client interface be a Windows-based rich client or a Web-based client? Over the last few years we’ve all come up with our own guidelines for identifying the pros and cons of both approaches to quickly determine which way to go. Issues like deployment, maintainability, GUI requirements, bandwidth, remote use, and manageability all weigh in the equation.

Mobile applications are just one more form of business software you have to learn to design and write. Not tomorrow… today!

With mobile development, you face the same questions: should you deploy local code on your devices or serve them mobile Web pages from a Web server? This may seem like an easy answer, but consider that many of the rules you used to resolve this question on the desktop don’t necessarily apply on mobile devices, or if they do, they might yield different results. For example, Web applications have the upper hand in many projects since network connectivity?either LAN-based or using Internet broadband?greatly facilitate client-server communications 100% of the time. But with mobile projects, wireless connectivity 100% of the time is virtually unheard of. I’ll address this local-vs.-Web dilemma in a future installment of Mobile CoDe.NET, so I’ll put this debate aside for now and discuss the two basic .NET mobility development technology offerings from Microsoft for local and Web deployment.

Visual Studio .NET 2003?Microsoft’s latest release of its award-winning development suite?brings you key technologies for mobile development: The .NET Compact Framework, for local rich-client applications that run on mobile devices, and the ASP.NET Mobile Controls, which enable Web-based development for mobile devices. Both toolkits require the Professional Edition (and above) of Visual Studio .NET 2003.

.NET Compact Framework
The palm (no pun intended) for single biggest innovation in mobile Windows powered computing since Windows CE goes to the .NET Compact Framework, which is the mobile cousin of the desktop and server-oriented Microsoft .NET Framework. In most respects, you can think of the .NET Compact Framework (.NETcf) as a .NET Framework “Light Edition” since Microsoft has scaled it down to less than 2 MB. While some compromises were necessarily made to reduce the .NET platform’s memory footprint for Windows CE, the most powerful features are still there, including the CLR, support for many languages, CPU-independent IL binaries, a library of base classes, and much more.

Having reached Gold status in Fall 2002 and released commercially in April 2003, the Microsoft .NET Compact Framework 1.0 is targeted for Windows CE .NET 4.1 and higher development only. The sole exceptions are devices running Pocket PC 2000 and 2002. These are the only Windows CE 3.0 specs supported by .NETcf and Microsoft has been so adamant on this I doubt you can expect more support for .NETcf on Windows CE 3.0. .NETcf’s direct competitor is none other than the Java 2 Micro Edition (J2ME) which?like its big brothers J2SE and J2EE runs on several operating systems including the Palm OS, the Symbian OS, Windows CE, Embedded Linux, and others. J2ME can even run as a mobile operating system on its own, which you can see in BlackBerry devices from Research In Motion (RIM).

The CLR in the .NET Compact Framework shares many commonalities with the full version, such as garbage collection, JIT compilation, verifiable type safe execution, error handling with exceptions, a common type system, and CPU independence. This last item is key to Windows CE development which previously required a different compiled binary for any supported CPU. Since the .NETcf CLR is available for all the CPUs supported by Pocket PC and Windows CE .NET (including MIPS, SH-3, StrongARM, x86, etc.), you only need a single IL binary for compatibility across the board. .NET Compact Framework IL assemblies even share a binary compatibility with the full version and can run in the .NET Framework’s CLR with no changes since they are “retargetable.” That is, provided the code does not reference any features unique to the .NETcf.

Not everything is the same though, (which you had to expect by now). The base class library is roughly a 25-30% subset of the full framework… still impressive! Another gotcha limits the .NETcf to two languages only: Visual Basic .NET and C#. It may sound like a bummer when measured against the full framework, but I always remind people that a fair evaluation of the .NET Compact Framework should compare it with the alternatives that is, the Embedded Visual Tools 3.0 and competing products. Other framework features were removed, either because they didn’t make sense or couldn’t exist on Windows CE, such as ASP.NET, classes associated to Directory Services, COM+, WMI, NT services, role-based security, and others, or because the cost in resources and memory was too high. Features in the latter category include COM Interop, .NET Remoting, generic serialization, reflection emit, install-time JITting (nGen), classes related to configuration files, MSMQ CE access, XSLT and XPath, and others.

Development on the .NET Compact Framework is integrated directly in the Visual Studio .NET 2003 IDE through the Smart Device Extensions (SDE). The SDE enable you to select new project types for VB or C# solutions and build these applications within the same environment you have learned to love over the last year. Unlike beta versions of the .NETcf and SDE, you unfortunately cannot add the SDE to the “original” version of VS.NET (2002 if we can call it that), an upgrade to VS.NET 2003 is mandatory.

Should you deploy local code on your devices or serve them mobile Web pages from a Web server?

If wish I could tell you all about the .NET Compact Framework right away, but that will have to wait for a dedicated article covering a deeper look into the .NET Compact Framework in an upcoming installment of Mobile CoDe.NET.

ASP.NET Mobile Controls
If a Web-based approach tickles your fancy when it comes to mobile development, you’ll want to give the ASP.NET Mobile Controls a spin. Formerly known in the first release of Visual Studio .NET as the Microsoft Mobile Internet Toolkit (MMIT), this toolkit allows you to build mobile Web applications for over 200 mobile devices of all types using just a single ASP.NET Mobile Controls project. Once you’ve installed them during setup, ASP.NET Mobile Controls provide you with one more project option?ASP.NET Mobile Web Application?to select from when you start a new Visual Studio .NET project. And contrary to the .NET Compact Framework’s limitation to VB and C#, you can leverage the ASP.NET Mobile Controls from any ASP.NET-compatible language.

When building a new Web application with the ASP.NET Mobile Controls, you still benefit from a Web Forms Designer, albeit this one is “mobile”. It features an array of “smart” controls that support adaptive rendering, which is the ability to “draw” itself and behave correctly regardless of the mobile device’s browser environment. This results in mobile Web pages and applications that you can access from Windows CE devices, Pocket PCs, Palm devices, BlackBerry devices, WAP-based Internet phones, Smartphones, and more. In fact, when it was released in February 2002, ASP.NET Mobile Controls supported a number of devices equivalent to more than 80% of market share in mobile devices worldwide. Microsoft since then published two additional device updates that?once installed on the ASP.NET server?enable support for even more devices without altering a single mobile Web project.

See also  Comparing different methods of testing your Infrastructure-as-Code

ASP.NET Controls applications are built like a deck of cards, where a single mobile ASP.NET page can host many mobile Web forms. Your code simply references the right form?or “card”?based on which one you want to return to the mobile user. Many mobile Web controls are available as shown in Figure 1, and just like other ASP.NET projects, you can extend these controls and design your own. At run-time, HTTP requests from mobile devices are dissected?thanks to the User Agent string?to identify which browser is running on the client device. A catalog of devices is then accessed to retrieve the list of features supported and not supported on this device, such as page type (HTML, CHTML, WML, etc.), screen width and height, support for color, graphics, scripting, CSS, ActiveX controls, java applets, XML and countless other attributes relevant to client-side processing. Once these capabilities are assessed, the mobile Web Form and controls render themselves based on the supported features, the page is JIT compiled once and then returned to the device for display.

The Role of Wireless in Mobility
Wireless connectivity may not be essential to mobile applications since offline modes with delayed synchronization offer a viable alternative. But truly agile mobility scenarios involve immediacy, which requires real-time access to server-side resources. More options become available and true automation is achieved only with a reliable wireless access to your enterprise resources. There are many types of wireless networks and I want to bring you up to speed with the basics.

The most well-known type of wireless access is Wireless Local Area Network (WLAN), which you’ll find in corporate scenarios. With low deployment costs and easy roaming capabilities, Wi-Fi?as it is known?easily connects internal users, meeting rooms, common work areas, warehouses, large surfaces and many other types of deployments, including college buildings, hospitals, and more. Wi-Fi allows you to build your own wireless network with wireless hubs?or access points that can reach out to hundreds of feet in radius. The most common specification is 802.11b, found in most offices and wireless home networks today, which supports transfer rates of 1-11 Mbps 802.11a is also available and supports up to 55 Mbps. but is incompatible with 802.11b hardware. The upcoming 802.11g will support transfer rates up to 55 Mbps. and will be compatible with both the “b” and “a” specs, but since the “g” hardware available today is based on a draft specification, I would steer clear of “g” hardware until the spec is final if I were you. Security is of course of big concerns for many people when wireless enters the room and many reliable options are available today. I’ll cover more on this topic in upcoming issues.

Another well-know but little-used technology is Bluetooth, which enables you to set-up a Personal Area Network (PAN). Bluetooth allows your personal devices, such as PDAs, phones, portable printers, and notebooks, to talk to each other over wireless. With a limited range of roughly 30 feet, this is the type of network you carry around with you. For example, with a Bluetooth-enabled Internet phone, a Pocket PC device with Bluetooth (such as an iPaq) can “borrow” the Internet connectivity from the phone, thus using it as a wireless modem to check e-mail and surf the mobile Web.

Nationwide wireless networking is the dream, and we are getting there. Some telecom companies have started to deploy Wi-Fi “hotspots” in high-traffic areas?like T-Mobile in Starbucks Coffee houses, but such an approach leaves many gaps. True on-the-road access requires a Wireless Wide Area Network (WWAN). Telecom carriers like AT&T Wireless and Sprint provide such networks and allow you to connect to the wireless Internet using a standard data plan as you would with a mobile phone and a voice plan. Contrary to voice plans though, data access is billed based on bytes transferred, not the time you are connected. You can typically get a per-Megabyte package or subscribe to an unlimited access for less than $100 per month in some areas in the US. Canadian subscribers can typically get an unlimited package for approximately $50 CAD per month with Rogers AT&T Wireless.

The CLR in the .NET Compact Framework shares many commonalities with the full version.

There is a tug-of-war between two camps when it comes to WWAN technologies. On one side we have GPRS, or General Radio Packet Services, from carriers relying on GSM networks for voice. On the other, CDMA networks use 1xRTT (Radio Transmission technology, also known as CDMA2000)?or 1X for short?for wireless data access. Since GPRS is widely used in Europe where wireless has at least a two year head start on the US, it is a more mature technology than 1X and many more GPRS devices are available than there are 1X. On the other hand, 1X is faster than GPRS with theoretical connection speeds of up to 144 Kbps compared to the usual 112 kbps on GPRS. GPRS can reach up to 171 Kbps at its highest level in the spec, but this is rarely supported in the hardware. In reality, benchmarked speeds for both oscillate just below a 56.6 Kbps modem, with a slight advantage in the 1X camp depending on which carriers are compared. There is more to these specs than their connection speeds but it is beyond the scope of this column to dig deeper in WWAN analyses.

Both specs will eventually merge sometime in the future with UMTS (Universal Mobile Telephone Service), also known as WCDMA (Wide-CDMA) or its popular name: 3G. This next generation of WWAN networks will support transfer speeds of 2 Mbps and higher on a national scale, but don’t expect them for quite a few years yet. Both 1X and GPRS already have a migration path to 3G, such as GPRS/EDGE which means the transition shouldn’t be too painful. Don’t expect too much forward-compatibility on the part of your devices though.

But enough about hardware and networks, let’s get back to the world of software.

Getting Started
You’re probably eager to give these technologies a spin by now. Let’s write and build your first .NET Compact Framework application using Visual Studio .NET 2003 and the Smart Device Extensions (SDE). You’ll need Visual Studio .NET 2003 (version 7.1) since the SDE is not available as an add-on for Visual Studio .NET 2002 (version 7.0). With a fixed upgrade price tag of $29 US?even for the Enterprise Architect and Enterprise Developer editions?the upgrade is well worth it. I encourage you to read Juval L?wy’s article What’s New in Visual Studio .NET 1.1 from the March/April 2003 issue of CoDe Magazine to find out more about the upgrade to Visual Studio .NET and .NET Framework. Also make sure your installation includes the support for mobile development features.

Figure 2: Creating a Smart Device project
Figure 3: The Smart Device Application Wizard

Building the Application
Start Visual Studio .NET 2003 and create a new Visual Basic project. The project type we’re interested in is Smart Device Application, which is a new option in Visual Studio .NET 2003 (see Figure 2). Select the location of your choice and name your project MyFirstSDEApp. After you accept these settings, Visual Studio .NET launches the Smart Device Application Wizard (see Figure 3) to allow you to select which type of mobile platform you want to target as well as the project type you want to create. I’ll cover these options in greater detail in a future article, so for now let’s simply choose Pocket PC as the platform and Windows Application as the project type. Accept the settings and let the wizard create the application project.

Running the Application
You are now ready to test and run your first SDE application. But what if you do not own a Pocket PC device? How are you supposed to test the application you just created? Luckily, Microsoft provides a powerful device emulator with the SDE and it allows you to fully test your mobile applications as you would on a real Windows CE.NET or Pocket PC device. Note that this is a real emulator?not a simulator?based on Connectix Virtual PC technology running a real operating system image of Windows CE .NET or Pocket PC 2002 on an x86 processor. I’ll discuss the emulator and its various capabilities in a future article.

The power of the Smart Device Extensions and the Emulator quickly become apparent at runtime during a debugging session. The Remote Debugging feature allows you to debug your mobile application just like any other Visual Studio .NET project type by hitting breakpoints and stepping through code in the VS.NET IDE while your application executes within the emulator or an actual device connected via ActiveSync. To put this functionality to the test, set a breakpoint on the first line of code you entered in the Click event of the Go! button. Then press F5 to compile, deploy, and run the application.

There are over 25 standard Windows Forms controls available today with the Smart Device Extensions.

Once Visual Studio .NET compiles and builds the application, you are asked if you want to deploy to a Pocket PC device or to the Pocket PC 2002 Emulator. Select the latter option and the Pocket PC 2002 Emulator will appear. A connection is first established to the emulator and then files are copied to it. Since this is your first time running the emulator, the whole .NET Compact Framework CAB file is also copied and installed on the virtual device. Once all the steps are successfully completed, a remote debugging session is established and the application appears in the emulator.

The power of the Smart Device Extensions and the Emulator quickly become apparent at runtime during a debugging session.

You can now give your newly created application a test run. Enter some text in the textbox and select the Go! button. When you do so, execution will be interrupted and the breakpoint you set will be hit. Behold the power of remote debugging, allowing you to step through your code and watch objects and variables in the VS.NET Debugger when the code is in fact running on a separate device, virtual or not. Finish stepping through the code or hit F5 to resume. The label then displays the text you entered, along with the version of the .NET Compact Framework CLR and the full name and version of Windows CE running in the emulator (see Figure 5).


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist

©2024 Copyright DevX - All Rights Reserved. Registration or use of this site constitutes acceptance of our Terms of Service and Privacy Policy.