Write Once, Run Anywhere

In the February/March edition of Smartphone and Pocket PC magazine, I discussed some interesting approaches for creating applications that support the wide variety of form factors and screens associated with the newer Windows Mobile devices. Its definitely a challenge to develop one program that works on a variety of devices. But the same variety offers the opportunity to create exciting applications that take advantage of the new features.

In the first article, we took a look at several approaches for dealing with the ambiguities of the screen layouts, focusing on using Managed Code, that is, C# or Visual Basic.NET. We looked at the features of Visual Studio 2005 and some ways of expanding upon them to create even more flexibility.

The crux of the matter is this: How do you make sure your programs buttons, menus, dialog boxes and other controls work when you can't be sure of the size and shape of the screen or whether its displaying in landscape or portrait mode?

More reasons to love Managed Code

There are disadvantages associated with Managed Code: its not suited to low-level development, Today/Home screens, and developing apps that squeeze the very last CPU cycle of power out of a device. However, with C# you can knock together a complete application with a professional-looking user interface in about 10 minutes. In another half hour, you can harness the power of all those wonderful Compact Framework classes to access databases, open Web pages or process XML files. That's compelling stuff.

Coming back to C or C++ after a Managed Code project can be a bit of a shock. When developing in Native Code, you often end up declaring and instantiating your user controls (buttons, menus, combo boxes) manually with lines of code instead of dragging ready-to-go controls from the toolbox to your Form.

Also, when you double-click a button in the Visual Studio 2005 C++ IDE, you won't get a function automatically created for you. There is no concept of anchoring or docking controls: they stay where you put them, and won't be moved automatically at run-time.

Given these limitations, building a user interface is time-consuming, even when things are going smoothly. Add in the work involved in creating a user interface that also functions with different screen sizes and resolutions, and it can appear a little overwhelming.

My goal is to show you some ways to minimize the pain and maximize the number of devices your application can run on. As before, were going to take a look at some approaches which can simplify things a little and hopefully encourage you to invest your time in making your software as device-agnostic as possible. As a refresher, here's a list of the currently supported screen resolutions and orientations for Windows Mobile devices:

Detecting orientation changes

The issue here is how you place buttons and other controls on the screen so they work on any device. This will allow you to concentrate on making your application do useful stuff, rather than spending all your time rewriting code for different user interfaces.

The first thing your application needs be able to do is to determine which way is up. This is pretty easy; its achieved by listening out for a WM_SIZE message, which makes your code aware of the current width and height of the screen and when that changes (e.g., when the screen orientation changes) :

switch (uMessage)

{

case WM_SIZE:

// lParam = width of application

// wParam = height of application

break;

}