Windows Mobile - A New Era Has Begun
Jim Wilson
June 2004
Applies to:
Microsoft® Windows Mobile™ software
Microsoft .NET Compact Framework
Microsoft Visual Studio® .NET 2003
Microsoft SQL Server™ 2000
Microsoft Windows® CE
Microsoft ActiveSync®
Microsoft eMbedded Visual C++®
Microsoft Visual Basic® .NET
Summary: In this first installment of "You Can Take It with You," Jim Wilson looks at the new mobility features of Whidbey, and how they affect the future of Windows Mobile. (7 printed pages)
Contents
Introduction
Where We're Going
Whidbey and Windows Mobile
GUI
Conclusion
Introduction
I'm typing this first installment of "You Can Take It with You" on a Sunday morning here at my home in Exeter, NH. The Microsoft® Mobile DevCon (MDC) 2004 is just over a week away, and I'm really looking forward to it both as a presenter and as an attendee. Although I still have a lot of work to do before MDC, I can't wait for it to get here. This year's MDC marks the beginning of a new era; an era where mobile development takes that next giant step to being widely used by the enterprise.
By the time most of you read this, the MDC will have already passed, and you will have had a chance to see the sessions or download the Microsoft PowerPoint® presentations. You may even have already installed the Whidbey Beta containing the first look at the next generation of Microsoft Windows Mobile™ software development. If you've had the opportunity to do any of these things, I think you will agree that mobile developers have never had access to the kind of tools offered by Whidbey. The combination of these tools and the ever growing experience that developers are gaining in building mobile applications has finally brought upon us the era of widespread enterprise-level mobile applications.
The arrival of this era is exactly what has prompted me to start this column.
Where We're Going
As enterprise developers, we deal with large data volumes, complex user interactions, difficult user personalities, and challenging business processes. We're faced with finding out how to navigate the mazes of available classes, tools, and techniques and how to apply them to create meaningful mobile solutions that can effectively deal with our data, users, and processes.
My goal in writing this column is to address a range of issues facing enterprise developers in the mobile space from the standpoint of what I call "pragmatic programming." To me, pragmatic programming means looking at classes, tools, and techniques in terms of the solutions they can provide. It also means that various classes, tools, and techniques often must be considered in relation to one another, and how they may be combined as part of an overall solution. In short, pragmatic programming is about looking at technology as a means to an end rather than the end itself.
Throughout the months ahead, we'll look at a wide array of issues that enterprise developers face when creating mobility applications. Some months we'll look at the details of building a particular solution, other months we'll look at helpful tools, and at other times we'll dig into a particularly useful class or library. Whatever the topic, the goal is the same: share meaningful information that will help developers who are building enterprise applications for the Windows Mobile platform.
Whidbey and Windows Mobile
I've found it a little challenging to decide where to start for the first installment in a new column. Then it occurred to me that, because Whidbey's mobility features motivated me to create this column, we can start by taking a quick look at what I think are some of the most notable additions and modifications to Whidbey that affect mobile application development.
Note Written prior to the actual release of the Whidbey Beta containing the Windows Mobile enhancements, this article is based on pre-beta information. None of these features are finalized and may change between now, the release of the beta, and the release of the final product. Be sure to check the product documentation before using any of these features.
Here are some of my favorite Whidbey mobility features in no particular order. There are too many to investigate in depth this month, but stay tuned as we'll be talking in great detail about these features in the months ahead.
GUI
Let's face it: The graphical user interface (GUI) is where much of the user experience is focused. Although the current release of the Microsoft .NET Compact Framework provides a reasonable first version of the Microsoft Windows® Forms library, it is somewhat limited. But that's changing with the arrival of Whidbey.
Support for Multiple Screen Orientations and Resolutions
For years, all Microsoft Windows Mobile-based Pocket PCs have had a common display layout of 240x320 portrait resolution. This resolution is no longer the case. The most recent generation of Pocket PC devices now have a variety of screen capabilities, including support for both portrait and landscape modes with some even being square. A few devices even support screen resolutions of 480x640, which is the same resolution as the original desktop computer. Whidbey has been updated to provide support for all of these displays, allowing you to build applications capable of taking full advantage of the target device capabilities. Applications can even respond to changes in display settings while the application is running.
Enhanced Control Behavior
Building applications that must work with different resolutions and orientations presents a challenge that didn't previously exist. Thankfully, Whidbey gives us a much needed hand by adding support for control docking and anchoring. Docking allows a control to directly attach to one of the form's edges. Anchoring allows a control's position to be set relative to one or more edges. Docked or anchored controls automatically maintain their relative position and resize as required by the changes in the parent form's size.
Of course, many of the control features added in .NET Compact Framework Service Packs 1 and 2 are also included in Whidbey, such as tabbing support, keyboard events, and ForeColor/BackColor support.
WYSIWYG Form Designer
For those of you who have never worked with pre-Whidbey smart device applications, you may be wondering what the big deal about WYSIWIG (what you see is what you get) is. Those of you who have know the problem all too well. A real frustration has been that fonts and control sizes are different in Visual Studio® .NET 2003 than when shown on the actual device. Simply put, this problem is fixed.
This one change would be enough, but there's still more. The Form Designer now supports the various Pocket PC display modes, including portrait, landscape, and square. The mode is modifiable while designing, so you can ensure that your application looks good on devices running in any of the modes.
And if that weren't enough, the Form Designer now supports skins. With skins, you can see exactly how the form appears relative to the actual device, as shown in Figure 1.
.gif)
Figure 1 Whidbey Smart Device Designer with skin. Click the thumbnail for a larger image.
SQL Server CE
Microsoft SQL Server™ 2000 Windows® CE Edition (SQL Server CE) is our local data store when building .NET Compact Framework applications. The next generation of SQL Server CE, code named Laguna, is a huge step forward. Here are a few of the enhancements.
Updateable, Scrollable Cursor
When working with large data volumes, I've sometimes found it a little frustrating to work with SQL Server CE from the .NET Compact Framework. The problem is that the .NET Compact Framework database classes allow only limited ability for a user to take advantage of the local nature of SQL Server CE. Remember that SQL Server CE runs completely local to the device and has full support for scrolling and update-in-place capabilities, yet these features have had limited support from the .NET Compact Framework. This problem finally has been resolved through the addition of the SqlCeResultSet class. Using this class, .NET Compact Framework applications can scroll, update, and directly bind to data in SQL Server CE. It's no longer necessary to pay the high cost of the DataSet class when needing these features. I think this is one of the most important enhancements in Whidbey, and we'll soon talk more about it in another edition of this column.
Multiuser Access
Just like it sounds, SQL Server CE now supports multiuser access. There is full support for multiple applications to access and modify SQL Server CE databases. The database now supports both row and page locking complete with lock escalation. Although minor, probably one of the most notable impacts of this change on many developers is that they will no longer have to close their databases in SQL Server CE Query Analyzer before they launch the application that uses the database.
Desktop Administration and Access
Microsoft has added desktop computer support for SQL Server CE. You can to view, administer and interact with SQL Server CE databases from the next generation of SQL Server Enterprise Manager.
Believe it or not, you can also write desktop computer applications that can read and create SQL Server CE databases. Now don't get worried that Microsoft has some bizarre plan to make SQL Server CE a desktop computer database. Nothing could be further from the truth. This feature is provided simply for testing and database production purposes. There are many scenarios where some desktop computer or server applications need to create a SQL Server CE database so that a smart device application can access the application data. These application programming interfaces (APIs) are here to resolve this specific case.
Development Experience
Visual Studio .NET 2003 and the .NET Compact Framework tremendously improved the device developer experience. It is much more stable and certainly much easier to use than pretty much any other device developer tools. Device development is still a long way from being as easy as building desktop applications, but Whidbey gives us the next giant step in that direction.
Improved Debugging
Device debugging has always been sluggish. Some of this sluggishness is due to the relatively slow connection speed (serial or USB in most cases) between the mobile device and desktop computer, but this isn't the only reason. Another big factor in the sluggishness is that much of the debugging functionality occurs on the device, which has only a fraction of the memory and CPU available on the desktop computer. So what can be done?
How about moving more of the debugging functionality to the desktop computer; the Whidbey device debugger has been completely redesigned. The new debugger has been designed so that work that absolutely must run on the device runs there. The majority of the debugging behavior now actually occurs on the desktop computer, resulting in a notably faster and more responsive debugger.
Better Emulator
There are just so many improvements to the emulator that I can't really list them all here. I will focus on what I think are some of the best improvements.
The emulator now supports being connected as a Microsoft ActiveSync® guest, making it appear more like a real device.
The emulator supports storing multiple emulator images. This storage allows you to set up multiple emulator configurations (settings, installed programs, and so on) and restore them as needed, thereby simplifying testing and error recovery. By using the current Visual Studio .NET 2003 emulator, we can have only one saved image, and if the emulator needs to be reset for any reason, that image must be completely re-setup.
The emulator supports having a desktop computer folder mapped as a storage card. This support makes it easy to share data between the desktop computer and the emulator. It also makes it easy to have common data across various emulator images.
The new emulator also supports switching among the various screen resolutions and orientations (portrait and landscape).
C++ Projects
Building applications that target mobile devices sometimes requires us to use C++ in addition to the .NET Compact Framework. Up until now, this requirement has meant that we've needed to use two separate integrated development environments (IDEs): Visual Studio .NET 2003 for our .NET Compact Framework code and the eMbedded Visual C++® IDE for our C++ code. Whidbey solves this problem by adding support for mobile device C++ projects.
With Whidbey we can now create, edit, and debug C++ projects targeting mobile devices from within the same Visual Studio environment we use for our .NET Compact Framework projects. We no longer need a separate eMbedded Visual C++ IDE and can now do all of our mobile device development, both managed (.NET Compact Framework) and unmanaged (C++) from a single IDE.
Improved Win32 and COM Interop
The .NET Compact Framework has substantially improved both Microsoft Win32® and COM Interop. Many of the common marshalling problems, such as passing embedded strings or classes with embedded reference types, have been resolved. We also have support for COM Interop now. The .NET Compact Framework can call COM objects and with a little work, COM objects can call .NET Compact Framework objects. The .NET Compact Framework runtime is now hostable in much the same way as the full .NET Framework. There are many details to this issue that we'll look at in an upcoming edition of the column.
Improved IntelliSense
Because of the need both to maintain an object model consistent with the desktop computer and to take into account certain realities of the platform's capabilities, there are some cases where .NET Compact Framework classes expose inherited properties and methods that are not legal to call. These cases are often referred to as "inherited but not supported." Unfortunately, in Visual Studio .NET 2003, these illegal methods still show up in the Microsoft IntelliSense® technology feature and often result in applications receiving runtime errors.
Whidbey fixes these errors by removing these inherited-but-not-supported methods and properties from the IntelliSense functionality. The inherited-but-not-supported methods and properties are in the .NET Compact Framework assemblies so it is still possible to call them (and get errors), but at least IntelliSense won't show them.
Important Additions
We've already seen many great features, but there's still so much more. As time goes on, we'll visit many different new features, but here are a few additions that I particularly like.
Smartphone Support
Smartphone is considered a first-class member of Whidbey with complete support for creating Microsoft Windows Mobile-based Smartphone applications (currently limited to .NET Compact Framework version 1 capabilities). The Form Designer and IntelliSense automatically adapt themselves to work appropriately for the Smartphone, exposing only those controls, classes, and methods that are supported.
Support for the New Whidbey Language Features
Not only is the .NET Compact Framework providing its own improvements, but it also includes support for the richer language features being rolled out with Whidbey. For Microsoft Visual Basic® .NET developers the new "My.*" namespace is supported. C# developers can expect support for generics, anonymous methods, and iterators.
Notification Broker
One very notable Windows Mobile enhancement, the Notification Broker, is not a feature of Whidbey, but it is a feature of the future Windows Mobile platform itself. The Notification Broker serves as a centralized publish and subscribe mechanism for virtually every event that can happen on the device. It allows applications to register interest in significant events, including a change in network status, change in ActiveSync status, arrival of a phone call, and arrival of a SMS (Short Message Service) message. The application is automatically notified when the event occurs. The beauty is that the architecture is completely extensible and centralized, providing a common programming model for all of these events. This is another feature we'll look at in more detail in a future edition of the column.
Conclusion
That concludes our first edition. I hope that previewing these new Whidbey device features has you as psyched about the future of Windows Mobile development as I am. We are at the dawn of a brand new day.
In the months ahead, we will go into much more detail on many of the topics we've introduced here. We'll also look at some more general mobile development topics that are not tied to Whidbey. I hope you'll stay with me.
Right now I need to get back to work on my MDC presentations. Hope to see many of you there; otherwise I'll see you next month.