This project is read-only.
Note that the information on this page is the BETA 1 of a guide that is now released. See for the latest PDF and HTML content.

Chapter 18 – Mobile Applications

- J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat


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 layer 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. The following diagram illustrates a common rich client mobile application architecture with components grouped by areas of concern.


Design Considerations

  • Decide if you will build a rich client, a RIA, or a thin client. If your application requires local processing and must work in an occasionally-connected scenario, consider designing a rich client. If your application can depend on server processing and will always be fully connected, consider designing a thin 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 requires a Rich UI, only limited access to local resources, and must be portable to other platforms, design a RIA client.
  • Determine the device types you will support. Consider screen size and format, CPU performance characteristics, memory and storage space, development tool and environment support, as well as user requirements and organizational constraints, when choosing which device types to support.
  • Design the application with occasionally-connected scenarios in mind. Most mobile applications must work when a network connection is intermittent or not available. It is vital in this situation that you design your caching, state management, and data access mechanisms with intermittent network connectivity in mind.
  • Design a UI appropriate for mobile devices; do not try to reuse a desktop application design or UI. Mobile devices require a simpler architecture, simpler UI, and other specific design decisions 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 application or a Web application.
  • Design a layering 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 the application for device resource constraints. Keep device resource constraints in mind when designing for the mobile platform. Every design decision should take into account the limited CPU, memory, storage and battery life of mobile devices.
  • Design considering battery life, memory size and speed. Battery life is usually the 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 Windows Mobile OS 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 speed during this process.

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 AuthN/AuthZ over a 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 SD cards.
Failing to appreciate the differences between security models of different devices.
Caching Not caching streaming data.
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.
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.
Not considering database access performance.
Navigating through large data sets when not required.
Failing to consider appropriate replication technologies and techniques.
Failing to consider access to device database services such as SQL Server Compact Edition.
Debugging Failing to appreciate debugging cost 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.
Deployment Failing to implement appropriate installer packages.
Failing to implement over-the-air installation and configuration.
Failing to implement over-the-air application management and administration.
Failing to appreciate the differences between Pocket PC and Windows CE.
Device Failing to consider device heterogeneity; such as screen size and CPU power.
Failing to consider resource constraints such as storage and memory.
Failing to implement recovery after a device reset.
Failing to implement cradled communication.
Storing critical data in volatile memory.
Exception Management Not recovering application state after an exception.
Not presenting user-friendly error messages to the user.
Failing to protect sensitive information.
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.
Performance Not minimizing power consumption.
Not considering limited resources such as CPU and memory.
Not considering memory technology constraints, such as slower flash memory.
Not providing options to allow the use of specific device features.
Not considering lazy initialization to minimize load time.
Not considering network bandwidth and latency constraints.
Implementing complex and pure programming practices instead of minimizing executable code size and efficiency.
Not considering issues of working with large data sets.
Using ADO.NET DataSets with the .NET Compact Framework.
Porting Failing to rewrite 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 Remote Data Access (RDA) synchronization where appropriate.
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 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 for your mobile application is important for the security and reliability of your application. Weak authentication can leave your application vulnerable to unauthorized use or allow users to access resources beyond their privileges. Authentication and authorization in mobile applications can be especially challenging due to limited device resources and the prevalence of network disconnections and interruptions. It is also necessary to consider the over-the-air, networked scenario, as well as the cradled scenario in which the device is communicating with a host PC.

When designing authentication and authorization, consider the following guidelines:
  • If you have an Active Directory infrastructure, consider using Mobile Device Manager to authorize devices on your network.
  • Consider that different devices may have variations in their programming security model, 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.
  • Ensure that you require authentication for access to Bluetooth devices.
  • As VPN abilities are built into Windows Mobile, utilize VPN functionality in solutions when required.
  • Design authentication for both over-the-air, cradled synchronization scenarios, Bluetooth discovery, and local SD card scenarios.
  • Identify trust boundaries within your mobile application layers. This will help you to determine where and how to authenticate.


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 unnecessary duplicate 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.

When designing caching, consider the following guidelines:
  • 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 RAM as used on desktop machines.
  • 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. Detect low memory scenarios and design a mechanism for prioritizing the data to discard as available memory decreases.
  • Cache static data that is useful, and avoid caching volatile data. For example, when transforming data, cache it until you run out of memory, the free the cached data and perform the transformation on the source data in real time.
  • Consider the scenario where you must persist application configuration information and cached data when your application is forced to stop execution due to resource limitations. You must deal with both the shutdown stage to store the data, and the subsequent startup to detect and reload the stored data.
  • Cache data in ready-to-use format unless this will significantly increase its memory footprint. If considerable resource usage is required to transform the data into a ready-to-use format, and it is not volatile, consider caching this data.
  • Consider the effect of caching on battery life. The more memory the application uses, the more power is required to maintain that memory.
  • Consider using a replication database. You can implement replication using merge replication, custom XML methods, or through calls to a remote service.
  • Consider using the caching capabilities available in the patterns & practices Mobile Client Software Factory.


Device communication includes wireless communication (over the air), wired communication with a host PC, as well as more specialized communication such as Bluetooth or 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 your application may be required to operate for long periods in a disconnected state.

When designing your communication strategy, consider the following guidelines:
  • Design for occasionally connected scenarios.
  • Consolidate and batch synchronization and updates, and send them when network connectivity is restored.
  • Consider the power usage of your choice of transport mechanism. Detect when the device is running on battery, and defer optional communications until it is running on mains power or directly connected to a PC.
  • Wireless transmission greatly reduces battery life. Different wireless technologies consume varying amounts of power. For example, the 3G protocol uses more power than the Edge protocol. Research the differences and choose a communication mechanism that uses the lowest consumption by default when on battery power.
  • Consider user connection costs. The user may need to pay for some types of communication. Give the user information about costs and allow them to control the connection.
  • If 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.
  • Design asynchronous, threaded communication to improve usability in occasionally-connected scenarios.
  • If you must access data from multiple sources, interoperate with other applications, or work while disconnected, consider using Web services for communication.
  • If you want to optimize for performance and low communication overhead, consider using the HTTP request/response pattern.
  • If you need direct, online access to a remote data source, consider using a .NET Compact Framework Data Provider.
  • If you need guaranteed delivery, asynchronous messaging, message security, or transaction support, consider using message queuing.
  • Consider using REST, TCP/IP (HTTP based), or WCF; for store and forward communication consider using WCF over email or SMS (text message) mechanisms.
  • Protect communication over un-trusted connections, such as Web services and other over-the-air methods.

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.

When designing your configuration management strategy, consider the following guidelines:
  • Design for the restoration of configuration after a device reset.
  • Design for the saving and restoration of configuration in device memory.
  • If your device memory is extremely limited, consider utilizing configuration management over the air or when connected to a host PC.
  • Due to memory limitations, choose binary format over XML for configuration files
  • Consider using compression library routines to reduce the memory requirements for configuration and state information.
  • Protect sensitive data in device configuration files.
  • If you have an Active Directory infrastructure, consider using the Mobile Device Manager interface to manage group configuration of devices.

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.

When designing data access, consider the following guidelines:
  • Consider using query objects to improve separation between the database code and the business logic.
  • Consider the use of data transfer objects instead of DataSets to reduce data mapping complexity and improve performance.
  • 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.
  • If your application must access to a disconnected database, consider using the device database services (such as SQL Server Compact Edition).
  • Consider merge replication to synchronize large volumes of data in one operation over a high bandwidth network connection. Consider Remote Data Access (RDA) if you must synchronize individual sets of a data over a remote connection.
  • Consider reducing complexity by utilizing stateless REST services that divide a system into resources identified by a Uniform Resource Indicator (URI).


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.

When designing your debugging strategy, consider the following guidelines:
  • Understand your debugging costs when choosing which devices to support. Factor in tools support, cost of initial and perhaps replacement test devices, and cost of software based device emulators,
  • If possible, design first for devices that are supported by your development tools.
  • Run and debug in an emulator first, periodically transferring stable code to your device to confirm that is works correctly. Carry out final testing on the device itself.
  • Design with device debugging in mind. Build in mechanisms to assist when debugging on the device as necessary.
  • Consider that it may be difficult to maintain context between different types of code running on a device. For example, you may not be able to debug native and managed code in the same debug session. Arrange simple ways to pass process and context information in function calls so that you can track program execution.
  • Design to debug your program in fully-disconnected scenarios. Do not rely on tests only carried out using wireless or synchronized connection to a PC.


Mobile applications can be deployed over the air or from the host PC. Consider the requirements of your users, as well as how you will manage the application, when designing for deployment.

When designing your deployment strategy, consider the following guidelines:
  • 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 have an existing Active Directory infrastructure, consider using the Mobile Deployment Manager (MDM) 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 OS starts up.
  • If the baseline application will not be upgraded itself, consider storing and loading it from ROM so that it is always accessible.
  • If your application relies heavily on a host PC, consider using ActiveSync to deploy your application.
  • 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.
  • If you are using CAB file distribution for multiple devices, include multiple device executables in the CAB file. Have the device detect which to install, and discard the rest.


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; plus limitations in memory and storage space, and network bandwidth and connectivity. Your choice of mobile operating system will generally depend on the target device type.

When determining your device strategy, consider the following guidelines:
  • Optimize the application for the device by considering factors such as screen size and orientation, network bandwidth, memory and storage space, and other hardware capabilities.
  • Consider device-specific capabilities that you can use to enhance your application functionality, such as accelerometers, GPUs, GPS, haptic (touch, force and vibration) feedback, compass, camera and fingerprint readers.
  • If you are developing for more than one device, design for a core functionality subset. Next add in customization for device-specific features, including functionality to detect when the code is running on a device that can utilize this functionality. Create modular code that can be removed if separate executable files are required due to device memory size constraints.

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 avoid your application being left in an inconsistent state in the event of an error.

When designing for exception management, consider the following guidelines:
  • Display user-friendly messages to end users.
  • Design your application to recover to a known good state after an exception.
  • Do not use exceptions to control logic flow.
  • Design your code to avoid exceptions where possible.
  • Do not catch exceptions unless you can handle them.
  • Design a global error handler to catch unhandled exceptions.
  • Do not reveal sensitive information through exception details.
  • Design an appropriate exception propagation strategy.
  • Design an appropriate exception logging strategy.
  • Design an appropriate notification strategy for critical errors and exceptions.


Designing an effective logging and instrumentation strategy is important for the security and reliability of your mobile application. You should have a logging strategy that includes the mobile device and any remote resources that are a primary part of its functionality. Using combined logs, you can detect suspicious activity that provides early indications of an attack, and help to address the repudiation threat where users deny their actions. Log files may be required in legal proceedings to prove the wrongdoing of individuals. 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 may be generated on the device and must be synchronized with the server during periods of network connectivity.

When designing logging, consider the following guidelines:
  • If you have an Active Directory infrastructure, consider using the Mobile Device Manager to extract logs from mobile devices.
  • 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.
  • Do not store sensitive information in log files.
  • If you carry out extensive logging on the device, consider logging in an abbreviated or compressed format to minimize memory and storage impact.
  • Decide what constitutes unusual or suspicious activity on a device, and log information based on these scenarios.
  • Consider auditing for business critical operations


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.

When designing your performance strategy, consider the following guidelines:
  • 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.
  • Design configurable options to allow the maximum use of device capabilities.
  • Design for the efficient use of CPU, memory, storage, and other limited device resources.
  • To optimize for mobile device resource constraints, consider using lazy initialization.
  • Design with network bandwidth and latency constraints in mind.
  • 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 limited file system resources that will usually be shared with execution memory.
  • Consider and account for varying memory types. For example, only flash memory may be available on your device, which is often slower than RAM found in desktop PCs.
  • 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.


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.

When designing to port your existing application to a mobile device, consider the following guidelines:
  • 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 user interface for the smaller screen size.
  • If you are porting a 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 PocketPC code, Visual Studio will allow you to change a target platform and will provide warnings when you are using Smartphone-specific functionality




When designing synchronization for your mobile application, consider whether you want to support over-the-air synchronization or just cradled synchronization. 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 again. For lightweight synchronization, remote data access (RDA) synchronization is the easiest to implement. For more complex synchronization, including bidirectional data synchronization, consider using merge replication.

When designing synchronization, consider the following guidelines:
  • If you want easy-to-implement one-way synchronization, consider Remote Data Access (RDA) synchronization. RDA is efficient because users can specify what to synchronize and when synchronization will occur.
  • If you must support bidirectional synchronization to SQL Server 2000 or SQL Server 2005, consider using merge replication synchronization. Remember that merge synchronization will synchronize all of the data, 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.
  • Design for recovery when synchronization is reset.
  • Design to manage synchronization conflicts.
  • Consider replication methods that use Web services through REST, TCP/IP (HTTP based), or WCF.
  • Consider store and forward synchronization using WCF over email or SMS (text message) mechanisms.


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 full screen, and 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.

When designing the UI, consider the following guidelines:
  • Give the user visual indication of blocking operations; for example, an hourglass cursor.
  • Consider the use of pen input when sizing and spacing controls
  • Consider input from various sources. For example, stylus, keypad and so on.
  • Design for various screen sizes and orientations.
  • Design for a single window, full screen UI.
  • Consider the fact that the .NET compact framework has a reduced set of controls.
  • If you are building a Web client interface, consider using the MVC pattern.
  • If you are building a mobile rich client interface, consider using the MVP pattern.
  • Remember that only one application can be running at a time.
  • Consider using colors to mitigate the limitations of screen size, but plan to accommodate color-blind users.
  • Consider using kiosk mode to maximize screen are availability for your application.
  • Do not place menu bars at the top of the screen as they are difficult to see when using a stylus or touch screen input.
  • Design to accommodate touch screen input by making buttons large enough, and lay out controls so that the UI is "finger-friendly".

Pattern Map

Category Key Issues
Authentication and Authorization Brokered Authentication
Direct Authentication
Caching Cache Dependency
Communication Application Service Layer
Entity Translator
Front Controller
Reliable Sessions
Data Access Active Record
Compensating Transaction
Data Transfer Object
Domain Model
Domain Object Factory
Object Relational Mapper
Optimistic Offline Lock
Pessimistic Offline Lock
Transaction Script
Unit of Work
Exception Management Exception Shielding
Logging Provider
UI Application Controller
Model View Controller
Model View Presenter
Template View

Key Patterns

  • Application Controller - Place all the application flow logic in an Application Controller, which is used by other controllers to use a model and display correct view.
  • Brokered Authentication - Perform authentication through a broker, which provides a token to use for authentication when accessing services or systems.
  • Composite View - Combine individual views into a composite view.
  • Data Transfer Object - Encourage the use of coarse-grained operations by packaging the data in a structure for movement across layers.
  • Exception Shielding - Filter exception data that should not be exposed to external systems or users.
  • Front Controller - Consolidate all request handling by channeling requests through a single handler object, which can be modified at runtime with decorators.
  • Layered Application - Structure an application to support such operational requirements as maintainability, reusability, scalability, robustness, and security.
  • Model View Controller - Separate the user interface, the data repository features, and the code logic that binds the two together.
  • 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.
  • Template View - Implement a common template view, and derive or construct views using the template view.

Technology Considerations

The following technology-specific information was available at publishing time. At the time, Windows Mobile 6.1 was in production. For versions later than 6.1, check the current documentation.
  • If you are designing for a phone, media device, or other small footprint device, consider Windows Embedded CE.
  • If you are designing for a set-top box, kiosk, or other larger footprint device, consider Windows Embedded Standard.
  • If you are designing for a point-of-service device such as an ATM or self-checkout, consider Windows Embedded for Point of Service.
  • If you are designing for a GPS-enabled device or a device with navigation capabilities, consider Windows Embedded NavReady.
  • ASP.NET support mobile devices through specific page and control classes and some additional controls. These automatically adapt to suit the target device at runtime.
  • Porting MFC apps to Mobile is not trivial due to its dependency on OLE. Windows CE supports COM, but not OLE.
  • It is possible to use Silverlight code created for a desktop UI on Silverlight 2 Mobile. However, you cannot use WPF on a mobile device.
  • The Windows Mobile security model differs on Windows Mobile Professional Two Tier and Three Tier. Smartphone Standard supports blocked, normal, and privileged modes. Windows Mobile Professional on the Pocket PC supports blocked and privileged modes.
  • Garbage collection in the compact frameworks running on Windows Mobile is non-generational.
  • Windows Mobile is based on the Windows CE operating system. Both Windows Mobile version 5.x and 6.x are based on Windows CE version 5.x.
  • Pocket PC was renamed Windows Mobile Professional and Smartphone was renamed to Windows Mobile Standard starting with Windows Mobile 6.0.
  • Windows CE version 6.x uses a virtualized memory model and a different process execution model than previous versions.
  • The PocketPC and the Smartphone have some differences in their UI. For example, the Smartphone does not have a button class in the CFM because the keypad is used for data entry.
  • Access Control lists (ACLs) are not available on the Windows Mobile v6.x platform or below. Check current documentation for version above 6.x.

Common deployment scenarios for Windows mobile device applications are:
  • ActiveSync using a Windows Installer file (MSI).
  • Site loading, manually using an SD card.
  • ROM-based, where the application loads when the device boots up.
  • Over the air, using HTTP, SMS, or CAB files to provide install and run functionality.
  • Post load and auto-run, which loads a company-specific package as part of the operating system.
  • Mobile Device Manager based, using Active Directory to load from a CAB or MSI file.

Additional Resources

Last edited Dec 16, 2008 at 8:19 AM by rboucher, version 3


190 Jan 12, 2013 at 4:53 AM 
Attention, please! Good coast are here. Get your <a href=""><strong>coast clothing</strong></a>,<a href=""><strong>coast dresses</strong></a> and <a href=""><strong>coast dress</strong></a> from the coast online. There are <a href=""><strong>occasion wear dresses</strong></a>, <a href=""><strong>cheap bridesmaid dresses uk</strong></a> and <a href=""><strong>Coast Bridal Dresses</strong></a> for you. The <a href=""><strong>occassion dresses</strong></a> and <a href=""><strong>Coast One Shoulder Dress</strong></a> are good, too. If you like the <a href=""><strong>coast dress sale</strong></a> here, you should hurry. The <a href=""><strong>coast perla dress</strong></a> maybe your favourite. Just go!