Write Once, Run Anywhere

I work in Microsoft's Pocket PC and Smartphone division and get to see new devices months before the rest of the world does. I am continually surprised by the variety of features and screen sizes in these new devices. They offer great opportunities to software developers, but also some very real challenges. How can a developer be certain an application will work when a user rotates their screen into landscape mode? How will an application look when a new device with an unexpected screen size is released? Will their software work on a square screen? Or a screen that's twice as large?

In an ideal world, developers wouldn't have to have to spend so much of their coding time worrying about how a user interface will look on every possible device. In this programming nirvana, the developers could instead focus on the core functionality or business logic of their application. However, in the real world there are some issues that developers absolutely must be aware of when creating their user interface.

A little history

From the earliest times of software development, the existence of different hardware configurations has plagued software developers. Early PCs had various graphics adaptors with wildly different capabilities. Fortunately, things today are nowhere near as complicated for Windows Mobile device developers.

Windows Mobile 5.0 supports DirectDraw and Direct3D, and these provide abstraction levels for coding software to be used with different types of graphics hardware. Unfortunately. DirectDraw and Direct3D are mostly of use when writing high-performance games or when creating graphics-intensive software. They still leave us some fundamental issues to solve.

Fig. 1: A carefully laid-out design in Portrait mode can be unusable in Landscape mode.

The main issue can best be demonstrated by the screenshots in Fig. 1. On the left is a Pocket PC running in Portrait mode. That is, the screen orientation is 240 pixels wide by 320 pixels high: this is the default configuration for the majority of devices on the market today. An application is running, and it is displaying a series of controls.

On the right, the same Pocket PC is running the same application, but the display has been rotated 90 degrees into landscape mode—240 pixels high by 320 pixels wide. This display mode is supported by Pocket PCs running Windows Mobile 5, and is even the default view for a few devices. Notice how the controls are hidden at the bottom of the screen. Windows Mobile 5 tries to help by providing scroll bars. But even so, vital information is not immediately apparent.

There are ways to deal with different screen sizes and orientations when developing using C# or Visual Basic.NET with the latest version of the Compact Framework, and Visual Studio 2005. We'll cover applications that are built using C++ in a later article. The information presented will be equally applicable to both Pocket PC and Smartphone devices.

Solution 1: Being careful

One way to cope with different screen sizes is to design for only the smallest possible screen area that devices have in common. In our first example, if we design the application so that all the controls are further up in the top left of the display (Fig.2), then rotating the display to landscape won't cause anything to be hidden.

Keeping controls in the top left of the screen is the easiest way to keep them visible.

This is the simplest workaround, but it's hardly the most elegant. It wastes a lot of screen real estate and packs all the controls into one location, which makes them harder to use. On the plus side there is no extra programming involved, but the results are not going to win any design awards.