Developing for Windows Mobile-based Smartphones: Present and Future

  • Article

 

Marco Bellinaso
www.dotnet2themax.com

April 2005

Applies to:
   Windows Mobile-based Smartphones
   Windows Mobile 2003 Second Edition software for Smartphones
   Smartphone 2003 SDK
   Microsoft Visual Studio 2003
   Microsoft Visual Studio 2005
   Microsoft .NET Compact Framework version 1.0
   Microsoft .NET Compact Framework version 2.0

Contents

The Present with Visual Studio 2003
The Future with Visual Studio 2005
Conclusion
For More Information
About the Author

Summary: Covers the current Smartphone development features provided by Visual Studio .NET 2003, then provides an overview of those features in Visual Studio .NET 2005 by exploring the current beta 1 release. (12 printed pages)

Developing applications for Windows Mobile software for Smartphone is a reality today, and thanks to the .NET Compact Framework version 1.0 and the Visual Studio 2003 form designer, code editor, compilers, debuggers, and emulators, it's not more difficult than developing a typical desktop program. Visual Studio 2005 will improve the development experience even more, making it easier and more productive. This article covers the current features provided by Visual Studio .NET 2003, provides an overview of Visual Studio .NET 2005 by exploring the current beta 1 release, and anticipates the new APIs and components that will be introduced in a future version of Windows Mobile software.

The PDA and Smartphone market has expanded enormously over the last few years, and the trend is likely to continue in the future. The possibility to carry in your pocket all the power of a personal computer available a few years ago, packed in a small device such as a Pocket PC, is just too appealing to many people. The general public appreciates the multimedia features, the games, the possibility to create, read, and manage documents of many types, and of course to browse the Web and read e-mails.

Business people also see the possibility to use a Pocket PC to keep connected and in sync with their office's data while they are on the go, provide more dynamic information to customers, take and manage orders and other business-related data. They like the opportunity to make their work more effective, quick and comfortable, without needing to carry around a laptop.

The Present with Visual Studio 2003

Out of the box, Visual Studio 2003 includes support for smart device projects, namely projects that use .NET Compact Framework to target Pocket PC 2002, Pocket PC 2003, and other Windows CE devices. It doesn't, however, immediately support Windows Mobile software for Smartphone. Smartphone 2002 doesn't support the .NET Compact Framework. The Smartphone 2003 SDK integrates Smartphone support into Visual Studio 2003 .NET. (Download SDK for Windows Mobile 2003-based Smartphones.) Before August 2003, when the Smartphone 2003 SDK was released, if you wanted to develop Smartphone applications you would have been better off knowing C++ well, as your only choice was to use eMbedded Visual C++ (eVC++) 3.0 with the Smartphone 2002 SDK. However, the Smartphone 2003 SDK integrates with Visual Studio .NET 2003, and adds support for the Smartphone 2003 platform to smart device projects. Thus, after installing this separate package you can use the same environment, programming languages, and compilers that you use to develop desktop and Web applications with the .NET Compact Framework. Only Visual Basic .NET and C# are supported, so if you want to use C++ for some parts of your program you still need to use eVC++ (version 4.0, if you're targeting Smartphone 2003). Figure 1 shows the IDE while designing a form.

Click here for larger image

Figure 1. Visual Studio .NET 2003 IDE while designing a Smartphone form (click for larger image)

Your design process works the same as with a typical Windows Forms project: You drag and drop controls on the form's surface, set their properties in the Properties window, and then switch to the code view to write event handlers. Adding references to external assemblies or Web services also works the same way. The first obvious difference lies of course in the size of the form, which is 176 x 220 pixels, and just 176 x 180 pixels after you remove the vertical space required for the title and menu bars. These limits dramatically reduce the number of controls you can place on the form without making it scroll, and remember that controls must be large enough to be readable. Also, you should place no more than one control per line.

When you look at the Toolbox window you'll also see that many controls, such as Button, ListBox, Toolbar, and InputPanel (among others) are grayed out, or unavailable for Smartphone applications. The available controls are Label, TextBox, CheckBox, PictureBox, Panel, ComboBox, ListView, TreeView, HScrollBar, VScrollBar, Timer, ProgressBar, ImageList, and MainMenu. Although not grayed out, the DataGrid is not available in Smartphone forms—there is a bug that shows it as available at design-time, so you can drag and drop it on a form, but when you launch the application you are informed that the DataGrid class is not present in the project's assemblies.

In some cases, such as for Button and InputPanel, the fact that the controls are unavailable is due to the Smartphone platform itself: Since it doesn't have a touch screen, you can't tap a button or a letter in the Soft Input Panel (SIP) as you would on a Pocket PC. Instead of buttons you must use menus. There should be one or two top-level items, activated by the two softkeys: the one on the left should represent the default action and shouldn't have submenus, while the one on the right can have submenus. This is one of the many guidelines you should follow if you want to qualify for the Designed for Windows Mobile logo. These guidelines will help you make your application more user-friendly and help to create a common set of standards among programs targeting Windows Mobile. Another extremely important guideline is that you should provide a default value for the form's controls every time you can. Remember that your user doesn't have a full-sized keyboard on which to type, nor a mouse to move through controls: They must use the numeric keypad to write anything, the direction pad to move up and down through controls, the action key to select a control (for example to select/unselect a checkbox, or expand a textbox to multiline mode in a separate form view), and the soft keys to select menus. Using the keypad certainly isn't the most comfortable way to type, and therefore the less users have to type, the better. Following this simple guideline can dramatically improve the user experience, and thus the success of your application.

A typical business-oriented application will likely need some sort of database for the data it uses, but it is not possible to install SQL Server CE 2.0 on the Smartphone platform, so you can't use it as your data store, as you would do in many cases when you target the Pocket PC platform. The Data visual components are also not available in Visual Studio .NET when building mobile applications—the Data tab is not present in the Toolbox. You will typically use an untyped DataSet to load data from a local XML file, or store data returned by a remote Web service, accessed via a GPRS connection or an Internet/LAN connection shared through ActiveSync (which connection the user uses is transparent to the developer).

Once you've created a simple form with some controls, you want to see it running live, so just press F5 to start the project. You're presented with a dialog box that asks where you want to deploy the compiled application: you can choose among various Smartphone emulators or a connected physical device. You can have multiple emulators installed at the same time, and by default you get the Smartphone 2003 emulators with or without Virtual Radio support (i.e. a virtualization of the Radio stack of the phone, which, for example, allows sending test SMS messages to a hardcoded special number). Testing on the physical device is slower, and the security policies of your Smartphone's mobile operator may require you to get a development certificate and digitally sign your code. (For more information, see A Practical Guide to the Smartphone Application Security and Code Signing Model for Developers.) Therefore, you will typically deploy and test your applications on the emulators during development, and then use the physical device for the final tests and for operations that are impossible or difficult to reproduce on an emulator (for example, sending/intercepting an SMS, starting a phone call, taking pictures with the built-in camera, or using a programmable add-on accessory). The emulator is based on a special version of Windows Mobile software compiled for x86 CPUs. This means that it appears and behaves much like the operating system on the physical Smartphone, while not being really the same binary image, and also that you yourself will compile your projects twice: once to produce x86 output, to be run on the emulator, and once to produce an ARM version for the real device. Using breakpoints and other typical debugging options is fully supported on both the emulator and the physical device.

Figure 2 shows what the sample application shown at design-time in Figure 1 looks like at runtime, inside the emulator. Note how the design-time visual designer renders the form's controls (such as the text box, combo box, and menus) with the typical appearance of Windows Forms controls, while the controls look different on the emulator. This is because there they are rendered by Windows Mobile, whose user interface (UI) is different from the Windows UI. For example, only the active control (the one with the focus) has a border around it, the combo box doesn't have a drop-down list box with the available items (but you can move through them with the left and right keys of the direction keypad), and menu items are automatically numbered so that the user can use the numeric keypad to select them faster.

Figure 2. A test form running inside the Smartphone 2003 emulator

I won't explore development with Visual Studio .NET 2003 in more detail, since code examples and design guidelines are already published on MSDN online. For example, you can refer to Crafting Smartphone User Interfaces Using .NET Compact Framework and Develop for Windows Mobile 2003 for Smartphone Using the .NET Compact Framework. Do yourself a favor and jump to www.opennetcf.org to download the Smart Device Framework, an open source collection of new classes and controls that extend the .NET Compact Framework and can work on both the Pocket PC and Smartphone 2003. There are classes to do 2-D drawing, do cryptography and serial communication, work with threads, access phone features such as SMS and voice calls, read SIM data, and more. There are graphical UI controls such as an extended button or progress bar, or new controls such as a very advanced ListBox, a MonthCalendar, an HTML Viewer, and many more. They usually wrap a lot of unmanaged API calls, and can save you plenty of time (and money).

The Future with Visual Studio 2005

Visual Studio 2003, with the addition of the Smartphone 2003 SDK, is already a very good environment to develop for Windows Mobile-based Smartphones because you can use the same .NET Framework languages, IDE, and tools you're familiar with. It has, however, some shortcomings: you still need to use a separate IDE (eVC++ 4.0) for writing C++ components (you may need them to access some features with unmanaged code, since not everything is wrapped in .NET Framework classes, or to achieve better performance for critical operations), the visual designer doesn't exactly represent how the form will be rendered at run time, the code editor's IntelliSense lists members that are available on the classes, but not implemented, and that if called will throw exceptions at run time. The current release of the .NET Compact Framework also has important missing pieces, such as UI controls (all those that are grayed out in Figure 1, but also others such as MonthCalendar or DateTimePicker), many classes that are present in the full .NET Framework, and others that should be specific to the Smartphone platform, for example to provide access to PIM data, voice calls, SMS, and camera.

Visual Studio 2005 will improve the development experience quite a lot. First of all, you can develop for the Smartphone 2003 out-of-the-box (although you will still target .NET Compact Framework 1.0), without installing separate SDKs. In Visual Studio 2005 C++ will be a fully supported language, and there are wizards and templates to create MFC or ATL projects. The first thing you note after you create a new project is the new form designer, shown in Figure 3. The form is placed directly into a skin representing the emulator, as you would see it at run time (although you can turn off this option). The controls and menus also look like they do at run time, and they no longer appear as standard Windows controls at design-time, as is the case with Visual Studio .NET 2003.

Click here for larger image

Figure 3. Visual Studio .NET 2005 IDE while designing a Smartphone form (click for larger image)

Double-click the emulator's skin, and you'll get a template for the form's KeyDown event handler, with if blocks to handle the various Smartphone keys, as follows:

private void Form1_KeyDown(object sender, KeyEventArgs e)
{
   if ((e.KeyCode == System.Windows.Forms.Keys.F1))
   { // left softkey
   }
   if ((e.KeyCode == System.Windows.Forms.Keys.F2))
   { // right softkey
   }
   if ((e.KeyCode == System.Windows.Forms.Keys.Up))
   { // dpad-up
   }
   ...more if blocks here...
   ...
   if ((e.KeyCode == System.Windows.Forms.Keys.D0))
   { // num pad 0
   }
   if ((e.KeyCode == System.Windows.Forms.Keys.F9))
   { // num pad #
   }
}

A very simple improvement, but it's these kind of small improvements that make you more productive. Another helpful improvement is that the code editor's IntelliSense no longer shows the inherited but not implemented members of a type, although they are still callable in reality, and this reduces run-time exceptions.

The .NET Compact Framework 2.0 includes new UI controls, such as a MonthCalendar, DateTimePicker, and WebBrowser, supports docking and anchoring, and includes new classes to work with cryptography, XML serialization, messaging (MSMQ), and more. However the .NET Compact Framework installed on the current Smartphone 2003 platform is version 1.0 and cannot be updated; therefore, even with Visual Studio .NET 2005 you won't be able to access these new controls and classes from Smartphone 2003 projects. For this to be possible, we will have to wait until the next release of Windows Mobile software that will support the .NET Compact Framework 2.0 runtime. This is also true for the languages used to program with the .NET Compact Framework: all the new features introduced by the next version of Visual Basic .NET and C#, such as partial classes, generics, iterators, and anonymous methods, are not supported for Smartphone 2003 projects.

In practice, Visual Studio .NET 2005 in itself doesn't change or improve the code you write, but improves the way you write and test it, thanks to its improved integration with the Smartphone SDK and C++ language and its debugging tools. When you launch an application, the dialog box asking you whether to deploy the program on the real device or on the emulator lists more choices than are provided in Visual Studio .NET 2003, as shown in Figure 4.

Figure 4. Visual Studio .NET 2005 has emulators that run an x86 or an ARM version of the Windows Mobile image

The Legacy emulator is an image of Windows Mobile 2003 Second Edition compiled for x86 CPUs. Except for being updated to the Second Edition, this is what happens also for the emulator installed with the Smartphone 2003 SDK that you use from Visual Studio .NET 2003. It has, however, been improved, and it is now possible to share a folder on the computer (Figure 5), and access it as if it were a memory card plugged into the device. This is great when you need to copy files from the computer to the emulator (instead of adding them to the Visual Studio project and have them deployed with the application, as you would do today), and to test code that will access an external memory card.

Figure 5. The new Smartphone 2003 legacy emulator allows sharing a folder on the computer, and seeing it as a memory card from the Smartphone

But the real and great news is the other emulator, the one without the Legacy suffix. This runs an ARM version of the Windows Mobile platform, as the actual device does. This means that the appearance and behavior of your software run on this emulator should be exactly the same as if run on a real device. You will therefore be able to run accurate tests and debug sessions without using a real device, except for actions that can't be emulated, such as voice calls or access to external devices, or Bluetooth. A side effect of this is that once (and if) Microsoft includes support for connections between ActiveSync and the ARM emulator (at this time they're still evaluating this possibility, and I don't know if it will make it into Visual Studio .NET 2005) it will be possible to install third-party programs on the emulator, and thus almost perfectly reproduce the software configuration of the actual Smartphone, increasing the fidelity of the emulator against the device. At this time testing third-party software on the emulators is not possible, because the emulators run an x86 version of the OS, while the third-party software is compiled for the actual devices running the ARM release of the OS.

The ARM emulator also has other helpful features, such as the ability to save multiple image states (programs and configuration) and not just one as in the Visual Studio .NET 2003 emulators, and it enables you to set up various configuration options (to double the emulator's size, keep it always on top, change its skin, and others). Finally, the new emulators can work from inside a virtual machine (such as those created with Microsoft Virtual PC). Virtual machines are used by many developers to set up multiple operating systems and software configurations on the same PC—if something goes wrong they can always make a step back and restore a saved image (this is particularly important when you install beta software that is not guaranteed to be stable). However, Smart Device projects created with Visual Studio .NET 2003 cannot be tested in virtual machines—you're required to create separate partitions to install the various operating systems and Visual Studio .NET 2003, and thus you can't run multiple systems at the same time. Visual Studio 2005 overcomes this limit at last.

Conclusion

With all the improvements in Visual Studio .NET 2005, the future of development for Smartphone devices seems bright and full of opportunities. However, it's important to underline the fact that you can already develop great Smartphone applications with Visual Studio .NET 2003 and the Smartphone 2003 SDK. Add external libraries, in particular the Open NET CF libraries, and you'll be able to easily develop advanced business applications with an attractive user interface that take advantage of many features of the underlying platform.

For More Information

About the Author

Marco Bellinaso is the editor in chief and main developer of www.dotnet2themax.com, and works as a consultant and trainer for Code Architects Srl, an Italian company that specializes in the .NET Framework. He is also the author or co-author of some popular programming tools for Visual Basic 6 and .NET Framework programmers. Marco writes for various programming magazines, and is a co-author for a number of Wrox Press books, among which are ASP.NET Website Programming (C# and Visual Basic .NET editions), Fast Track ASP.NET, and Visual C# .NET: A Guide for VB6 Developers.