Overview

A mobile application will normally be structured as a multi-layered application consisting of user experience, business, and data layers. When developing a mobile application, you may choose to develop a thin Web-based client or a rich client. If you are building
a rich client, the business and data services layers are likely to be located on the device itself. If you are building a thin client, the business and data layers will be located on the server. Figure 1 illustrates common rich client mobile application architecture
with components grouped by areas of concern.

Figure 1 Common rich client mobile application architecture

Design Considerations

The following design guidelines provide information about different aspects you should consider when designing a mobile application. Follow these guidelines to ensure that your application meets your requirements and performs efficiently in scenarios common
to mobile applications:

Decide if you will build a rich client, a thin Web client, or rich Internet application (RIA). If your application requires local processing and must work in an occasionally connected scenario, consider designing a rich client. Keep in mind that
a rich client application will consume more device resources and will be more complex to install and maintain. If your application can depend on server processing and will always be fully connected, consider designing a thin client. If your application requires
a rich user interface (UI), only limited access to local resources, and must be portable to other platforms, design an RIA client.

Determine the device types you will support.** When choosing which device types to support, consider screen size, resolution (DPI), CPU performance characteristics, memory and storage space, and development tool environment availability. In addition,
factor in user requirements and organizational constraints.

Design the application with occasionally connected limited-bandwidth scenarios in mind.** Most mobile applications must work when a network connection is intermittent or not available. It is vital in this situation to design your caching, state management,
and data-access mechanisms with intermittent network connectivity in mind. Batch communications for times of connectivity. Choose hardware and software protocols based on speed, power consumption, and “chattiness,” and not just on ease of programming

Design a UI appropriate for mobile devices, taking into account platform constraints.** Mobile devices require a simpler architecture, simpler UI, and other specific design decisions in order to work within the constraints imposed by the device hardware.
Keep these constraints in mind and design specifically for the device instead of trying to reuse the architecture or UI from a desktop or Web application. The main constraints are memory, battery life, ability to adapt to difference screen sizes and orientations,
security, and network bandwidth.

Design a layered architecture appropriate for mobile devices that improves reuse and maintainability.** Depending on the application type, multiple layers may be located on the device itself. Use the concept of layers to maximize separation of concerns,
and to improve reuse and maintainability for your mobile application. However, aim to achieve the smallest footprint on the device by simplifying your design compared to a desktop or Web application.

Design considering device resource constraints such as battery life, memory size, and processor speed.** Every design decision should take into account the limited CPU, memory, storage capacity, and battery life of mobile devices. Battery life is
usually the most limiting factor in mobile devices. Backlighting, reading and writing to memory, wireless connections, specialized hardware, and processor speed all have an impact on the overall power usage. When the amount of memory available is low, the
Microsoft® Windows Mobile® operating system may ask your application to shut down or sacrifice cached data, slowing program execution. Optimize your application to minimize its power and memory footprint while considering performance during this
process.

Mobile Client Frame

There are several common issues that you must consider as your develop your design. These issues can be categorized into specific areas of the design. The following table lists the common issues for each category where mistakes are most often made.

Table 1 Mobile Client Frame

Category

Key issues

Authentication and Authorization

Failing to authenticate in occasionally connected scenarios

Failing to authorize in occasionally-connected scenarios

Failing to use authentication and authorization over a virtual private network (VPN)

Failing to authenticate during synchronization over the air

Failing to authenticate during synchronization with the host PC

Failing to authenticate for all connection scenarios, such as over the air, cradled, Bluetooth, and Secure Digital (SD) cards

Failing to appreciate the differences between security models of different devices

Caching

Caching unnecessary data on a device that has limited resources

Relying on cached data that may no longer be available in occasionally-connected scenarios

Choosing inappropriate cache locations and formats

Caching sensitive data in unencrypted form

Failing to choose an appropriate caching technology

Communication

Failing to protect sensitive data over the air

Failing to secure Web service communication

Failing to secure communication over a VPN

Not appreciating the performance impact of communication security on limited-bandwidth connections

Not managing limited-bandwidth connections efficiently

Not managing connections to multiple network services efficiently

Not designing to work with intermittent connectivity

Not considering connection cost or allowing the user to manage connections

Not designing to minimize power usage when running on battery power

Failing to use the appropriate communication protocol

Configuration Management

Failing to restore configuration state after a reset

Failing to consider configuration management synchronization over the air

Failing to consider configuration management synchronization with the host PC

Choosing an inappropriate format for configuration information

Failing to protect sensitive configuration information

Failing to consider the techniques used by different manufacturers for loading configuration settings

Data Access

Failing to implement data-access mechanisms that work with intermittent connectivity

Failing to appreciate debugging costs when choosing to support multiple device types

Failing to design with debugging in mind; for example, using emulators instead of the actual devices

Failing to debug in all connection scenarios

Device

Failing to consider device heterogeneity, such as screen size and CPU power

Not presenting user-friendly error messages to the user

Failing to protect sensitive information

Failure to consider the processing power of the device

Exception Management

Not recovering application state after an exception

Revealing sensitive information to the end user

Not logging sufficient details about the exception

Using exceptions to control application flow

Logging

Not considering remote logging instead of logging on the device

Not considering how to access device logs

Not considering resource constraints when logging

Failing to protect sensitive information in the log files

Porting

Failing to rewrite the existing rich client UI to suit the device

Failing to explore the available porting tools

Synchronization

Failing to secure synchronization when communicating

Failing to manage synchronization over the air as opposed to cradled synchronization

Failing to manage synchronization interruptions

Failing to handle synchronization conflicts

Failing to consider merge replication where appropriate

UI

Not considering the restricted UI form factor

Not considering the single window environment

Not considering that only one application can be running

Not designing a touch-screen or stylus-driven UI for usability

Not including support for multiple screen sizes and orientations

Not managing device reset and resume

Not considering the limited API and reduced range of UI controls compared to the desktop

Validation

Not validating input and data during host PC communication

Not validating input and data during over-the-air communication

Failing to protect hardware resources, such as the camera and initiation of phone calls

Not designing validation with limited resources and performance in mind

Authentication and Authorization

Designing an effective authentication and authorization strategy is important for the security and reliability of your application. Weak authentication can leave your application vulnerable to unauthorized use. Mobile devices are usually designed to be single-user
devices and normally lack basic user profile and security tracking beyond just a simple password. Other common desktop mechanisms are also likely to be missing. The discoverability of mobile devices over protocols such as Bluetooth can present users with unexpected
scenarios. Mobile applications can also be especially challenging due to connectivity interruptions. Consider all possible connectivity scenarios, whether over-the-air or hard-wired.

Consider the following guidelines when designing authentication and authorization:

Consider that different devices might have variations in their programming security models, which can affect authorization to access resources

Do not assume that security mechanisms available on larger platforms will be available on a mobile platform, even if you are using the same tools. For example, access control lists (ACLs) are not available in Windows Mobile, and consequently there is no
operating system–level file security.

Ensure that you require authentication for access by Bluetooth devices.

Identify trust boundaries within your mobile application layers; for instance, between the client and the server or the server and the database. This will help you to determine where and how to authenticate.

Caching

Use caching to improve the performance and responsiveness of your application, and to support operation when there is no network connection. Use caching to optimize reference data lookups, to avoid network round trips, and to avoid unnecessarily duplicated
processing. When deciding what data to cache, consider the limited resources of the device; you will have less storage space available than on a PC.

Consider the following guidelines when designing caching:

Identify your performance objectives. For example, determine your minimum response time and battery life. Test the performance of the specific devices you will be using. Most mobile devices use only flash memory, which is likely to be slower than the memory
used in desktop machines.

Cache static data that is useful, and avoid caching volatile data.

Consider caching the data that the application is most likely to need in an occasionally connected scenario.

Choose the appropriate cache location, such as on the device, at the mobile gateway, or in the database server.

Design for minimum memory footprint. Cache only data that is absolutely necessary for the application to function, or expensive to transform into a ready-to-use format. If designing a memory-intensive application, detect low-memory scenarios and design
a mechanism for prioritizing the data to discard as available memory decreases.

Communication

Device communication includes wireless communication (over the air) and wired communication with a host PC, as well as more specialized communication such as Bluetooth or Infrared Data Association (IrDA). When communicating over the air, consider data security
to protect sensitive data from theft or tampering. If you are communicating through Web service interfaces, use mechanisms such as the WS-Secure standards to secure the data. Keep in mind that wireless device communication is more likely to be interrupted
than communication from a PC, and that your application might be required to operate for long periods in a disconnected state.

Consider the following guidelines when designing your communication strategy:

If you are designing an application that will run on a mobile phone, consider the effects of receiving a phone call during communication or program execution. Design the application to allow it to suspend and resume, or even exit the application.

Protect communication over untrusted connections, such as Web services and other over-the-air methods.

If you must access data from multiple sources, interoperate with other applications, or work while disconnected, consider using Web services for communication.

If you are using WCF and for communication and need to implement message queuing, consider using WCF store and forward.

Configuration Management

When designing device configuration management, consider how to handle device resets, as well as whether you want to allow configuration of your application over the air or from a host PC.

Consider the following guidelines when designing your configuration-management strategy:

Design for the restoration of configuration after a device reset.

If you have you enterprise data in Microsoft SQL Server 2005 or 2008 and desire an accelerated time to market, consider using merge replication with a “buy and configure” application from a third party. Merge replication can synchronize data in a single
operation regardless of network bandwidth or data size.

Consider using compression library routines to reduce the memory requirements for configuration and state information.

If you have a Microsoft Active Directory® directory service infrastructure, consider using the System Center Mobile Device Manager interface to manage group configuration, authentication, and authorization of devices. See the Technology Considerations
section for requirements for the Mobile Device Manager.

Data Access

Data access on a mobile device is constrained by unreliable network connections and the hardware constraints of the device itself. When designing data access, consider how low bandwidth, high latency, and intermittent connectivity will impact your design.

Consider the following guidelines when designing data access:

Program for data integrity. Files left open during device suspend and power failures may cause data-integrity issues, especially when data is stored on a removable storage device.

Include exception handling and retry logic to ensure that file operations succeed.

Do not assume that removable storage will always be available, as a user can remove it at any time. Check for the existence of a removable storage device before writing or using FlushFileBuffers.

If you need to ensure data integrity in case the device loses power or has connectivity disruptions, considering using transactions with SQL Server Mobile.

If your application must access a disconnected database, consider using the device database services (such as SQL Server Compact Edition).

If you use XML to store or transfer data, consider its overall size and impact on performance. XML increases both bandwidth and local storage requirements. Use compression algorithms or a non-XML transfer method.

Consider the use of custom objects instead of DataSets to reduce memory overhead and improve performance.

If your application needs to sync with multiple database types, use Sync Services for ADO.NET. It allows you to store data in Microsoft SQL Server, Oracle, or DB2.

Debugging

Mobile application debugging can be much more expensive than debugging a similar application on a PC. Consider this debugging cost when deciding which devices, and how many devices, your application will support. Also keep in mind that it can be harder to get
debug information from the device, and that device emulators do not always perfectly simulate the device hardware environment.

Consider the following guidelines when designing your debugging strategy:

Understand your debugging costs when choosing which devices to support. Factor in tools support, the cost of initial (and perhaps replacement) test devices, and the cost of software-based device emulators.

If you have the device you are targeting, debug your code on the actual device rather than on an emulator.

If the device is not available, use an emulator for initial testing and debugging. Consider that an emulator might run code slower than the actual device. As soon as you obtain the device, switch to running code on the device connected to a normal PC. Perform
final testing on your device when not connected to a PC. Add in temporary or permanent mechanisms to debug problems in this scenario. Consider the needs of people who will support the device.

Test scenarios where your device is fully disconnected from any network or connection, including a PC debugging session.

If you are an OEM or ODM and your device has not yet been created, note that it is possible to debug a mobile program on a dedicated x86-based Microsoft Windows® CE PC. Consider this option until your device is available.

Device

Mobile device design and development is unique in that you may be targeting multiple devices with very different hardware parameters. Keep the heterogeneous device environment in mind when designing your mobile application. Factors include variations in screen
size and orientation, limitations in memory and storage space, and network bandwidth and connectivity. Your choice of a mobile operating system will generally depend on the target device type.

Consider the following guidelines when determining your device strategy:

Optimize the application for the device by considering factors such as screen size and orientation, network bandwidth, memory storage space, processor performance, and other hardware capabilities.

Exception Management

Designing an effective exception-management strategy is important for the security and reliability of your application. Good exception handling in your mobile application prevents sensitive exception details from being revealed to the user, improves application
robustness, and helps to avoid your application being left in an inconsistent state in the event of an error.

Consider the following guidelines when designing for exception management:

Design your application to recover to a known good state after an exception occurs.

Do not use exceptions to control logic flow.

Do not catch exceptions unless you can handle them.

Design a global error handler to catch unhandled exceptions.

Design an appropriate logging and notification strategy that does not reveal sensitive information for critical errors and exceptions.

Logging

Because of the limited memory on mobile devices, logging and instrumentation should be limited to only the most necessary cases; for example, attempted intrusion into the device. When devices are designed to be a part of a larger infrastructure, choose to track
most device activity at the infrastructure level. Generally, auditing is considered most authoritative if the audits are generated at the precise time of resource access, and by the same routines that access the resource. Consider the fact that some of the
logs might have to be generated on the device and must be synchronized with the server during periods of network connectivity.

Consider the following guidelines when designing logging:

If you carry out extensive logging on the device, consider logging in an abbreviated or compressed format to minimize memory and storage impact. There is no system Event Log in Windows Mobile.

If you do not require extensive logging, consider using OpenNetCF on the device. Be aware that OpenNetCF relies upon XML and will take up more space than a simple binary logging model.

Consider using platform features such as health monitoring on the server, and mobile device services on the device, to log and audit events.

Synchronize between the mobile database logs and the server database logs to maintain audit capabilities on the server. If you have an Active Directory infrastructure, consider using the System Center Mobile Device Manager to extract logs from mobile devices.
See the Technology Considerations section for requirements for the Mobile Device Manager.

Do not store sensitive information in log files.

Decide what constitutes unusual or suspicious activity on a device, and log information based on these scenarios.

Porting

Developers often want to port part or all of an existing application to a mobile device. Certain types of applications will be easier to port than others, and it is unlikely that you will be able to port the code directly without modification.

Consider the following guidelines when designing to port your existing application to a mobile device:

If you are porting a rich client application from the desktop, rewrite the application in its entirety. Rich clients are rarely designed to suit a small screen size and limited memory and disk resources.

If you are porting a Web application to a mobile device, consider rewriting the UI for the smaller screen size. Also, consider communication limitations and interface chattiness as these can translate into increased power usage and connection costs for
the user.

If you are porting an RIA client, research details to discover which code will port without modification. Consult the technology considerations section of this chapter for specific advice.

Research and utilize tools to assist in porting. For example, Java-to-C++ convertors are available. When converting from Smartphone to Pocket PC code, Microsoft Visual Studio® will allow you to change the target platform and will provide warnings when
you are using Smartphone-specific functionality. You can also link Visual Studio Desktop and Mobile projects to assist in knowing what is portable between the two projects.

Do not assume that you can port custom controls as-is to a mobile application. Supported APIs, memory footprint, and UI behavior are different on a mobile device. Test the controls as early as possible so that you can plan to rewrite them or find an alternative
if required.

Power

Power is the most limiting factor for a mobile device. All design decisions should at take into account how much power the device consumes and its effect on overall battery life. If you have a choice in devices, consider devices that can draw power from Universal
Serial Bus (USB) or other types of data hookups. Research communication protocols for their power consumption.

Consider the following guidelines when designing for power consumption:

To conserve battery life, do not update the UI while the application is in the background.

Choose communication methods considering both power usage as well as network speed.

Consider deferring nonessential wireless communications until the device is under external power.

Implement power profiles to increase performance when the device is plugged into external power and not charging its battery.

Design so that parts of the devices can be powered down when not in use, or when not required. Common examples are screen backlighting, hard drives, GPS functions, speakers, and wireless communications.

Design services and communications to transfer the smallest number of bytes possible over the air. Choose protocols, design service interfaces, and batch communications with this goal in mind.

If you are considering using the 3G hardware communications protocol, consider that while it is significantly faster, it also currently uses much more power than its predecessors, such as the Edge protocol. When you are using 3G, be sure to communicate
in batched bursts and to shut down communication at times when it is not needed.

Synchronization

Consider whether you want to support over-the-air synchronization, cradled synchronization, or both. Because synchronization will often involve sensitive data, consider how to secure your synchronization data, especially when synchronizing over the air. Design
your synchronization to handle connection interruptions gracefully, either by canceling the operation or by allowing it to resume when a connection becomes available. Merge replication allows both upload-only and bidirectional synchronization and is a good
choice for infrastructures utilizing newer versions of SQL Server. Consider the Microsoft Sync Framework as it can provide robust synchronization services in a wide variety of situations.

Consider the following guidelines when designing synchronization:

Design for recovery when synchronization is reset, and decide how to manage synchronization conflicts.

If you must support bidirectional synchronization to SQL Server, consider using merge replication synchronization. Remember that merge synchronization will synchronize all of the data in the merge set, which may require additional network bandwidth and
can impact performance.

If your users must synchronize data when away from the office, consider including over-the-air synchronization in your design.

If your users will be synchronizing with a host PC, consider including cradled synchronization in your design.

Consider store-and-forward synchronization using WCF rather than e-mail or SMS (text message), as WCF guarantees delivery and works well in a partially connected scenario.

User Interface

When designing the UI for a mobile application, do not try to adapt or reuse the UI from a desktop application. Design your device UI so that it is as simple as possible, and designed specifically for pen-based input and limited data entry capabilities as appropriate.
Consider the fact that your mobile application will run in full-screen mode and will only be able to display a single window at a time. Therefore, blocking operations will prevent the user from interacting with the application. Consider the various screen
sizes and orientations of your target devices when designing your application UI.

Consider the following guidelines when designing the UI for your mobile application:

Design considering that a person’s hand can block a touch-screen UI during input with a stylus or finger. For example, place menu bars at the bottom of the screen, expanding options upwards.

Design for a single-window, full-screen UI. If your device will be a single-user device running only the main application, consider using kiosk mode. Keep in mind that Windows Mobile does not support a kiosk mode, so you will need to use Windows CE.

Consider input from various sources such as stylus, keypad, and touch. For example, accommodate touch-screen input by making buttons large enough, and lay out controls so that the UI is usable using a finger or stylus for input. Design for various screen
sizes and orientations.

Give the user visual indication of blocking operations; for example, an hourglass cursor.

Performance Considerations

Design your mobile application with device hardware and performance constraints in mind. Designing for a mobile device requires that you consider limited CPU speed, reduced memory and storage, narrow bandwidth and high latency connections, and limited battery
life.

Consider the following guidelines when designing your performance strategy:

Design configurable options to allow the maximum use of device capabilities. Allow users to turn off features they do not require in order to save power.

Consider limited memory resources and optimize your application to use the minimum amount of memory. When memory is low, the system may release cached intermediate language (IL) code to reduce its own memory footprint, return to interpreted mode, and thus
slow overall execution.

Consider using programming shortcuts as opposed to following pure programming practices that can inflate code size and memory consumption. For example, examine the cost of using pure object-oriented practices such as abstract base classes and repeated object
encapsulation.

Consider power consumption when using the device CPU, wireless communication, screen, or other power-consuming resources while on battery power. Balance performance with power consumption.

Deployment

Mobile applications can be deployed using many different methods. Consider the requirements of your users, as well as how you will manage the application, when designing for deployment. Ensure that you design to allow for the appropriate management, administration,
and security for application deployment.

Deployment scenarios listed for Windows Mobile device applications, with the more common ones listed first, are:

Microsoft Exchange ActiveSync® using a Windows Installer file (MSI).

Over the air, using HTTP, SMS, or CAB files to provide install and run functionality.

Mobile Device Manager–based, using Active Directory to load from a CAB or MSI file.

Post load and auto-run, which loads a company-specific package as part of the operating system.

Site loading, manually using an SD card.

Consider the following guidelines when designing your deployment strategy:

If your users must be able to install and update applications while away from the office, consider designing for over-the-air deployment.

If you are using CAB file distribution for multiple devices, include multiple device executables in the CAB file. Have the device detect which executable to install, and discard the rest.

If your application relies heavily on a host PC, consider using ActiveSync to deploy your application.

If you are deploying a baseline experience running on top of Windows Mobile, considering using the post-load mechanism to automatically load your application immediately after the Windows Mobile operating system starts up.

If your application will be run only at a specific site, and you want to manually control distribution, consider deployment using an SD memory card.

Pattern Map

Table 2 Pattern Map

Category

Relevant patterns

Caching

Lazy Acquisition

Communication

Active Object

Communicator

Entity Translator

Reliable Sessions

Data Access

Active Record

Data Transfer Object

Domain Model

Transaction Script

Synchronization

Synchronization

UI

Application Controller

Model-View-Controller

Model-View-Presenter

Pagination

Pattern Descriptions

Active Object.** Support asynchronous processing by encapsulating the service request and service completion response.

Active Record. Include a data access object within a domain entity.

Application Controller. An object that contains all of the flow logic, and is used by other Controllers that work with a Model and display the appropriate View.

Communicator.** Encapsulate the internal details of communication in a separate component that can communicate through different channels.

Data Transfer Object (DTO).** An object that stores the data transported between processes, reducing the number of method calls required.

Domain Model.** A set of business objects that represents the entities in a domain and the relationships between them.

Entity Translator.** An object that transforms message data types into business types for requests, and reverses the transformation for responses.

Lazy Acquisition. Defer the acquisition of resources as long as possible to optimize device resource use.

Model-View-Controller.** Separate the UI code into three separate units: Model (data), View (interface), and Presenter (processing logic), with a focus on the View. Two variations on this pattern include Passive View and Supervising Controller, which
define how the View interacts with the Model.

Model-View-Presenter.** Separate request processing into three separate roles, with the View being responsible for handling user input and passing control to a Presenter object.

Pagination.** Separate large amounts of content into individual pages to optimize system resources and minimize use of screen space.

Reliable Sessions.** End-to-end reliable transfer of messages between a source and a destination, regardless of the number or type of intermediaries that separate the endpoints**

Synchronization. A component installed on a device tracks changes to data and exchanges information with a component on the server when a connection is available.**

Transaction Script.** Organize the business logic for each transaction in a single procedure, making calls directly to the database or through a thin database wrapper.

Technology Considerations

The following guidelines contain suggestions and advice for common scenarios for mobile applications and technologies.

Microsoft Silverlight for Mobile

If you are using Microsoft Silverlight® for Mobile, consider the following guidelines:

Consider that at the time of this writing, Silverlight for Mobile was an announced product under development, but not yet released.

If you want to build applications that support rich media and interactivity and have the ability to run on both a mobile device and desktop as is, consider using Silverlight for Mobile. Silverlight 2.0 code created to run on the desktop in the Silverlight
2.0 plug-in will run in the Windows Mobile Silverlight plug-in in the latest version of Microsoft Internet Explorer for Mobile. Consider that while it is possible to use the same Silverlight code in both places, you should take into account the differing screen
size and resource constraints on a mobile device. Consider optimizing the code for Windows Mobile.

If you want to develop Web pages for both desktop and mobile platforms, consider Silverlight for Mobile or normal ASP.NET/HMTL over ASP.NET for Mobile unless you know that your device cannot support either of these alternatives. As devices browsers have
become more powerful, they are able to process the same native HTML and ASP.NET targeted by the desktop, thus making ASP.NET Mobile development less important. ASP.NET Mobile Controls currently supports a variety of mobile devices through specific markup adapters
and device profiles. While ASP.NET Mobile Controls automatically render content to match device capabilities at run time, there is overhead associated with testing and maintaining the device profiles. Development support for these controls is included in Microsoft
Visual Studio 2003 and 2005 but is no longer supported in Visual Studio 2008. Run-time support is currently still available, but may be discontinued in the future. For more information, see the links available in the Additional Resources section.

.NET Compact Framework

Consider the following guidelines if you are using the Microsoft .NET Compact Framework:

If you are familiar with the Microsoft .NET Framework and are developing for both the desktop and mobile platforms concurrently, consider that the .NET Compact Framework is a subset of the .NET Framework class library. It also contains some classes exclusively
designed for Windows Mobile. The .NET Compact Framework supports only Microsoft Visual Basic® and Microsoft Visual C#® development.

If you are attempting to port code that uses Microsoft Foundation Classes (MFC), consider that it is not trivial due to MFC’s dependency on Object Linking and Embedding (OLE). The Windows Compact Edition supports COM, but not OLE. Check to see if the OLE
libraries are available for separate download to your device before trying to use MFC on a mobile device.

If you have issues tracing into a subset of Windows Mobile code with the Visual Studio debugger, consider that you might require multiple debug sessions. For example, if you have both native and managed code in the same debug session, Visual Studio might
not follow the session across the boundary. In this case, you will require two instances of Visual Studio running and will have to track the context between them manually.

Windows Mobile

Consider the following general guidelines for Windows Mobile applications:

If you are targeting an application for both Windows Mobile Professional and Windows Mobile Standard editions, consider that the Windows Mobile security model varies on the different versions of Windows Mobile. Windows Mobile Standard (Smartphone) supports
three levels: blocked, normal, and privileged mode. Windows Mobile Professional (Pocket PC) supports only blocked and privileged mode. Code that works on one platform might not work on the other because of the differing security models for APIs. Check the
Windows Mobile documentation for your device and version.

If you will have to manage your application in the future or are upgrading an existing application, be sure that you understand the Windows Mobile operating system derivation, product naming, and versioning tree. There are slight differences between each
version that could potentially impact your application.

Windows Mobile is derived from releases of the Windows CE operating system.

Both Windows Mobile version 5.x and 6.x are based on Windows CE version 5.x.

Windows Mobile Professional and Windows Mobile Standard have slight differences in their APIs. For example, the Windows Mobile Standard (Smartphone) lacks a Button class in its Compact Framework implementation because softkeys are used for data entry instead.

Always use the Windows Mobile APIs to access memory and file structures. Do not access them directly after you have obtained a handle to either structure. Windows CE version 6.x (and thus the next release of Windows Mobile) uses a virtualized memory model
and a different process execution model than previous versions. This means that structures such as file handles and pointers may no longer be actual physical pointers to memory. Windows Mobile programs that relied on this implementation detail in versions
6.x and before will fail when moved to the next version of Windows Mobile.

The Mobile Device Manager is mentioned in this article as a possible solution for authorizing, tracking, and collecting logs from mobile devices, assuming that you have an Active Directory infrastructure. MDM also requires a number of other products to
fully function, including:

Windows Mobile 6.1 on devices

Windows Software Update Service (WSUS) 3.0

Windows Mobile Device Management Server

Enrollment Server

Gateway Server

Active Directory as part of Windows Server

SQL Server 2005 or above

Microsoft Certificate Authority

Internet Information Server (IIS) 6.0

.NET Framework 2.0 or above

Windows Embedded

Consider the following guidelines if you are choosing a Windows Embedded technology:

If you are designing for a set-top box or other larger-footprint device, consider using Windows Embedded Standard.

If you are designing for a point-of-service (POS) device such as an automated teller machine (ATMs, customer-facing kiosks, or self-checkout systems), consider using Windows Embedded for Point of Service.

If you are designing for a GPS-enabled device or a device with navigation capabilities, consider using Microsoft Windows Embedded NavReady™. Note that Windows Embedded NavReady 2009 is built on Windows Mobile 5.0, while Windows Mobile version 6.1 is used
in the latest versions for Windows Mobile Standard and Professional. If you are targeting a common codebase for NavReady and other Windows Mobile devices, be sure to verify that you are using APIs available on both platforms.