The beta release of Visual Studio 2005 includes some of the most significant enhancements to the Microsoft development environment since the release of .NET itself. Nowhere is this more true than for developers targeting smart devices such as the Pocket PC.
Visual Studio 2005 provides tremendous improvements to the smart device development experience and the inclusion of the .NET Compact Framework Version 2 (.NET CF v2) gives us the richest Smart Device platform we've had to date. Virtually every aspect of smart device development has been improved with this latest release, but one of the most tangible areas of improvement is the addition of support for developing screen orientation-aware user interfaces.
Screen Orientation and Resolution
When .NET CF v1 was first released about a year and a half ago, designing a smart device user interface was pretty straightforward. At that time one of the requirements to brand a device as a Pocket PC was that the screen had to have a screen resolution of 240 x 320 with portrait orientation. No device branded as a Pocket PC could deviate from this requirement. This meant that the Visual Studio 2003 form designer, with its fixed layout of 240 x 320, portrait worked fine. Today, this fixed behavior is no longer enough.
The release of Windows Mobile 2003 Second Edition (Windows Mobile 2003 SE) back in June changed everything by introducing support for multiple screen orientations. Although these choices are good for device manufactures and users, it makes our job as developers much more difficult. Pocket PCs can now have screen resolutions of 240 x 320 (portrait), 320 x 240 (landscape) and, 240 x 240 (square). Some devices even support rotating the screen between portrait and landscape on-the-fly.
Without significant enhancements to the capabilities of Visual Studio 2003 and .NET CF v1, supporting these devices would be very difficult. Not to worry though, Visual Studio 2005 and .NET CF v2 add several features that make creating applications capable of supporting the variety of screen orientations much easier.
Visual Studio 2005 Form Designer
Since the Form Designer is the place where most of us begin our user interface development that's what we'll look at first. Just one look at the Visual Studio 2005 smart device form designer in Figure 1 tells you something is different. Rather than being just a simple form, the form designer now looks a lot like a device.
The resemblance to a device is no accident. One of the enhancements to the form designer is to provide developers with a much better design-time experience so that we can get a more accurate sense of what our applications will look like before running them.
One of the key areas where this is useful is in comparing a form's portrait appearance to the appearance in landscape. As you can see in Figure 2, the form designer supports rotating the form by simply right-clicking on the form and choosing either "Rotate Left" or "Rotate Right". Figure 3 shows my form in the designer displayed in a landscape orientation after choosing "Rotate Right". As you can see, the designer shows that my contact list application form needs some work before I can say that I'm ready for landscape devices.
The Visual Studio 2005 form designer is not limited to just rotating between portrait and landscape. It actually supports every permutation of device supported by Windows Mobile 2003 Second Edition including square (240 X 240) and VGA (480 x 640). You control which appearance the designer uses by selecting the form's FormFactor property (see Figure 4).
Design for Square
As we saw just a moment ago, my little contact list application doesn't render too well when viewed in landscape mode. It would look just as bad, if not worse, on a square device (240 x 240). What I want, of course, is for my application to be usable on all devices. One option I have is to do what is called "Design for Square".
With a resolution of 240 x 240, square devices represent the width of a portrait layout (240 x 320) and the height of a landscape layout (320 x 240). The idea is a simple one: design for the smallest screen and everything will fit on larger ones. Figure 5 shows my application with the layout reworked to fit on a square device.
For some applications, using "Design for Square" may work well. In other cases, and I think this is where my little contact list application fits, using "Design for Square" is not the answer. "Design for Square" is literally designing for the lowest common denominator and preventing the application from taking advantage of the screen space available on many devices. In the case of a landscape device, I'm not taking advantage of the screen width and may truncate long names in the list box. In a portrait display, I'm not taking advantage of the height and therefore unnecessarily limit the number of names that can be viewed in the listbox.
Anchoring and Docking Controls
What we really need is for the controls on the form to adapt to changes in the form size. This is something we could handle manually but in most cases that isn't necessary. One of the key control features that have been added with Visual Studio 2005 and .NET CF v2 is control anchoring.
Anchoring designates that a side of a control should remain a constant distance from the edge of the form. The controls will then automatically move and resize as necessary to maintain that relative position. A control can anchor to as many sides as required including all four if desired.
Anchoring is just what my contact list application needs. We'll anchor the top, left, and right sides of the two text boxes and all four sides of the list box. Anchoring the left and right edges of the two text boxes causes them to become wider and narrower with the form; anchoring the top keeps them a consistent distance from the top of the form. As for the listbox, having all four sides anchored causes both its width and height to adjust with the form. Figures 6 and 7 show the portrait and landscape views of the form with the controls anchored.
Docking is similar to anchoring. Rather than position a control a fixed distance from an edge, docking places a control directly against an edge and occupies the entire edge. It is useful for scenarios when you would like a particular control to occupy the entire edge of a form.
Resize Events
As we've seen, the Visual Studio 2005 form designer provides excellent support for developing orientation-aware applications. But sometimes the designer just isn't enough. For cases where we'd like to take layout management a little further we can handle the Resize event.
The Resize event is sent any time the screen orientation is changed. Your application can use this event to do any layout adjustment necessary. In extreme cases an application can use the event to manually position each individual control. Needing to take that level of control is not usually necessary; more commonly we use the Resize event in conjunction with anchoring and docking to fine-tune things. Using this technique, we can improve the look of our contact list application even further.
Rather than using anchoring for the listbox control, I'd like to use docking to attach it to the bottom edge of the form. I like docking because it utilizes the full width of the form and gives the application a nice clean look. The problem is that once I dock the listbox to the bottom of the form, I can't use anchoring to have the listbox automatically adjust its height.
This is a perfect opportunity to take advantage of the Resize event. We're still using anchoring on the two textboxes to manage their positions. As for the listbox, we're taking advantage of docking to manage the position and width of the control but when it comes to the height, we'll step in and handle the Resize event to change the listbox height manually; while we're at it let's go ahead and reposition the "Contact" label.
Listing 1 is the code for the Resize event handler.
The event handler implementation is pretty straightforward. We first compare the height and width of the form. If the height is greater, then we know we're in portrait mode so we set the listbox height accordingly; otherwise, we set the height for landscape. For the label we can just set the position relative to the listbox by simply subtracting the height of the label from the top of the listbox and then subtracting two more points to leave some white space. Figures 8 and 9 show the portrait and landscape views of the application.
Orientation-Specific Forms
Although not commonly required, in some cases it may be desirable to create distinctly different portrait and landscape views for your application. If this is your goal, the easiest thing to do may be to design separate portrait and landscape forms.
One of the important new classes in .NET CF v2 is the Screen class. The Screen class has one static property, PrimaryScreen, which tells us the size of the device screen. Using this class, we can modify the Main function found in Program.cs to create the appropriate form instance. All we need to do is compare the height of the screen to its width. If the screen is greater, create the portrait form; otherwise, create the landscape form. Once the appropriate form is created, passing the form reference to Application.Run will make that form the main application form (see Listing 2).
Using the modified main function, the application's main form will now be the portrait or landscape form that is appropriate for the device.
Conclusion
The introduction of support for portrait, landscape, and square device displays by Windows Mobile 2003 Second Edition has substantially increased the complexity of user interface development for smart device applications. Fortunately, Visual Studio 2005 and the .NET Compact Framework Version 2 provide the tools necessary to develop applications that make the most of these displays. These new devices, combined with the power of the new tools, give developers an opportunity to develop richer smart device user interfaces than ever before.
Subscribe to .NET Developer's Journal Email News Alerts
Subscribe via RSS
