Application Security Testing: An Integral Part of DevOps
Building Windows Mobile applications opens new development and business opportunities for a C++ developer, and given the issues with managed development on mobile devices that you covered in last month's article, C++ remains by far the best tool to take advantage over the wide range of development possibilities that Windows Mobile offers. This article examines how the frameworks and supported platforms for a Mobile Application (also referred to as a Smart Device application in the Visual C++ documentation) should be chosen, and then looks at the development process for a MFC Application.
With mobile development in C++, there are two important decisions to make before creating the project—which application framework (if any) will be used to build the application, and which Mobile SDKs will the application target. The type of functionality that the application offers will go a long way to deciding the appropriate application framework to use and SDK to target—for generic line-of-business applications such as an accounting application, the use of the MFC Smart Device Application that supports Pocket PC 2003 and above will be the best option. In contrast, the development of a plug-in for the Today screen of a Windows Mobile 6 Professional device obviously requires the corresponding SDK, and given that the plug-in will be loaded all of the time, the minimalist Win32 Smart Device Project option makes the most sense. In general, targeting the oldest SDK that contains the feature-set that will be used in a given application with the lightest application framework (Win32 followed by ATL followed by MFC) will be the best option. ATL sits between the more heavy-weight MFC option and the minimalistic Win32 option, and provides a wealth of support for COM development.
As with desktop development, it is difficult to anticipate all the features that an application will require when the application skeleton is first being developed, and as with development on the desktop and server, maintaining loose coupling at a source-code level between the various functional areas of an application is the best defence against the possibility that the targeted SDK or chosen application framework needs to change. In addition, rather than take a dependency on MFC just to use a few classes, it is preferable to use features in the C Runtime Library (CRT) and Standard C++ Library for utility types like strings and collections.
The final point worth making on choosing the appropriate starting point for a project is on the best technique for starting specialised applications that have a high degree of interaction with specific features of Windows Mobile such as the Today/Home screen, Internet Explorer Mobile, or a specific piece of hardware. For these specialized applications, it is often easier to start with a sample for the SDK that shows the basics of the task, strip the sample down so it is essentially a skeleton application, and then build on top of this skeleton. The alternative of starting with an App Wizard-generated project and then trying to add the configuration and set-up items to integrate the project with the device typically will be much harder. If it is likely that the skeleton application will need to be re-used as the basis for a number of applications, it is worth the effort to strip out all project-specific strings and make the skeleton into a Visual Studio project-type. It is a relatively easy undertaking, and will generate a positive return on investment with only a few uses.
MFC Smart Device Applications
Rather than provide a dry description of the application frameworks for Mobile Devices, the remainder of the article will follow the development of a MFC Smart Device Application that allows a user to check the number of hours that are booked on a particular date with appointments. All personal information manager (PIM) functionality provided on a Mobile device should be built on top of Pocket Outlook (see the Designed for Windows Mobile Software Application Handbook for other development guidance of a similar nature), and this sample will show how that can be achieved. The application offers reasonably rich functionality (at least with the scope of a demonstration application), so the use of MFC makes sense because it greatly simplifies the task of hooking together UI elements.
After the decision to use MFC has been made, the next decision is the range of devices the application will support. An inspection of the documentation related to the PIM functionality on Windows Mobile reveals that information on the calendar is available through the IPOutlookApp COM interface that has been part of Windows Mobile for a very long time (Pocket PC 2000 and above, according to the MSDN documentation for the interface), so targeting an old SDK like Pocket PC 2003 make sense. Most applications developed against older SDKs will work without modification on newer devices, and the range of emulators that are available with the various Windows Mobile SDK versions makes forward-compatibility checks simple to complete.
The code to implement the application is stock-standard MFC, with very little differences from standard MFC desktop development. The sample application is dialog- rather than document-based, so the Dialog option needs to be selected when the project is created, as shown in Figure 1. As with the desktop version of MFC, a dialog editor is present in Visual Studio to allow controls to be positioned with a WYSIWYG editor, and these controls then can be bound to a member variable in a particular C++ class. Data exchange between the control and member variable is achieved using the same Dialog Data Exchange (DDX) architecture as the desktop version of MFC.
Figure 1: Creating the MFC Application