Mobile Applications Archetype

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

Objectives

  • Define a Mobile application.
  • Understand components found in a mobile application.
  • Learn the key scenarios where mobile applications would be used.
  • Learn the design considerations.
  • Identify specific scenarios for mobile applications such as deployment, power usage, and synchronization.
  • Learn the key patterns and technology considerations.

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 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. Figure 1 illustrates common rich client mobile application architecture with components grouped by areas of concern.

MobileApp.PNG
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 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 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. 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. Some protocols have higher speed, but may use significantly more power or bandwidth. Users may pay by bytes transferred so chattier, long-winded service interfaces could increase costs while also slowing program execution. You may not always have control of the hardware protocol used as different areas may be covered by different protocols. Plan for this scenario.
  • Design a UI appropriate for mobile devices taking into account platform constraints. 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. The main constraints are memory, battery life, ability to adapt to difference screen sizes and orientations, security and network bandwidth.
  • 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 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 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 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 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.

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 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
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
Exception Management Not recovering application state after an exception
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 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 or allow users to access resources beyond their privileges. Mobile applications can be especially challenging due connectivity interruptions. The discoverability of mobile devices over protocols like Bluetooth can present users with unexpected scenarios. Consider all possible connectivity scenarios whether over-the-air or hardwired.

When designing authentication and authorization, consider the following guidelines:
  • Design authentication for over-the-air, cradled synchronization, Bluetooth discovery, and local SD card scenarios.
  • 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 by Bluetooth devices.
  • Identify trust boundaries within your mobile application layers. 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 unnecessary 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.

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.
  • 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. 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), 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 asynchronous, threaded communication to improve usability in occasionally connected scenarios.
  • 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.
  • Protect communication over un-trusted 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 need guaranteed delivery, asynchronous messaging, message security, or transaction support, consider using message queuing.

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.
  • Due to memory limitations, choose binary format over XML for configuration files
  • Protect sensitive data in device configuration files.
  • Consider using compression library routines to reduce the memory requirements for configuration and state information.
  • If you have an Active Directory infrastructure, consider using the System Center Mobile Device Manager interface to manage group configuration 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.

When designing data access, consider the following guidelines:
  • If your application must access a disconnected database, consider using the device database services (such as SQL Server Compact Edition).
  • Consider the use of merge replication to synchronize large volumes of data in one operation over a high bandwidth network connection.
  • 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 you will be developing your own mobile application, use Sync Services for ADO.NET. This will allow you to store data in a Microsoft SQL Server, Oracle, or DB2 database.

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.

When designing your debugging strategy, consider the following guidelines:
  • 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.
  • Use an emulator for initial testing and debugging. Consider that an emulator may 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.
  • If you have the device you are targeting, debug your code on the actual device while it is continually connected to a normal PC running a debugging session.
  • 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.

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

When designing for exception management, consider the following guidelines:
  • Design your application to recover to a known good state after an exception.
  • 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 for critical errors and exceptions that does not reveal sensitive information.

Logging

Designing an effective logging and instrumentation strategy is important for the security and reliability of your mobile application. You should design 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 helps 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:
  • Do not store sensitive information in log files.
  • 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.
  • 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 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.

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.

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. 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 a RIA client, research details to discover which code will port without modification. Consult the technology considerations section of this article for specific advice.
  • Research and utilize tools to assist in porting. For example, Java to C++ convertors is available. When converting from Smartphone to PocketPC code, 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 know 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 they consume and its effect on overall battery life. If you have a choice in devices, consider devices that can draw power from USB or other types of data hookups. Research communication protocols for their power consumption.
  • To conserve battery life, do not update the UI while the application is in the background.
  • When possible, choose communication methods that use least power. For example, 3G and Bluetooth generally use more power than the Edge protocol.
  • Implement power profiles to increase performance when device is plugged into external power and not charging the 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, 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.

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 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:
  • 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, 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 over email or SMS (text message) mechanisms.

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 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.
  • Do not place menu bars at the top of the screen because they are difficult to see when using a stylus or touch screen input.
  • Design for a single window, full screen UI. Remember that only one application can be running at a time.
  • 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 "finger-friendly".
  • Design for various screen sizes and orientations.

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.

When designing your performance strategy, consider the following guidelines:
  • Design configurable options to allow the maximum use of device capabilities. Allow users to turn off features they do not require to save power.
  • To optimize for mobile device resource constraints, consider using lazy initialization.
  • 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 in 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 listed with the more common ones first are:
  • 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.

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 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.
  • 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 OS 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

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 - 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 to 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 user interface 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 will help you to choose an appropriate implementation technology.
  • If you want to build connected applications that require WAP, cHTML, or similar rendering formats, consider using ASP.NET Mobile Forms and Mobile Controls.
  • If you want to build applications that support rich media and interactivity, consider using Silverlight for Mobile.
  • If you decide to use Windows Compact Framework and you are designing for a phone, media device, or other small footprint device, consider Windows Embedded CE.
  • If you decide to use Windows Compact Framework and you are designing for a set-top box, kiosk, or other larger footprint device, consider Windows Embedded Standard.
  • If you decide to use Windows Compact Framework and 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 decide to use Windows Compact Framework and you are designing for a GPS-enabled device or a device with navigation capabilities, consider Windows Embedded NavReady.

The following guidelines contain suggestions and advice for common scenarios for mobile applications and technologies. Use this specific guidance to help you decide if the technologies discussed are appropriate for your scenario:
  • ASP.NET supports mobile devices through specific page and control classes and some additional controls. These automatically adapt to suit the target device at runtime. Development support for these controls was included in Visual Studio 2005, but not Visual Studio 2008.
  • The .NET Compact Framework is a subset of the .NET Framework class library and also contains classes exclusively designed for it. It supports only Visual Basic and Visual C# development.
  • Porting MFC applications to Windows Mobile is not trivial due to its dependency on OLE. Windows Compact Edition supports COM, but not OLE. Check if the OLE libraries are available for separate download before trying to use MFC on a mobile device.
  • In some cases, you may require multiple debug sessions when debugging Windows Mobile code. For example, you may not be able to debug native and managed code in the same debug session. You will require two instances of Visual Studio running and you must track the context between them manually.
  • It is possible to use Silverlight code created for a desktop UI on in a Silverlight plug-in for Windows 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. Windows Mobile Standard (Smartphone) supports blocked, normal, and privileged modes. Windows Mobile Professional (Pocket PC) supports blocked and privileged modes.
  • Garbage collection in the .NET Compact Framework running on Windows Mobile is non-generational.

The following guidelines discuss Windows Mobile and Windows CE. This information was available when the guide was published, and Windows Mobile 6.1 was in production. For versions later than 6.1, check the current documentation. Use this specific guidance to help you decide if Windows Mobile and Windows CE are appropriate for your scenario:
  • 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. This means that structures such as file handles and pointers may no longer be actual physical pointers to memory. Programs that relied on this implementation detail may fail when moved to Windows Mobile 7 or later.
  • The 3G hardware communications protocol, while significantly faster, currently uses much more power than Edge protocol based communications. You may not always be able to choose which communication method to use if the device is equipped with hardware to handle both protocols.
  • The Pocket PC and the Smartphone have some differences in their UI. For example, the Smartphone does not have a Button class in the Compact Framework implementation because the keypad is used for data entry.
  • It is possible to debug a mobile program on a dedicated x86-based Windows CE PC. OEMs or ODMs should explore this scenario to see if it can provide them with any time or money savings compared to debugging on an actual device.
  • Access Control lists (ACLs) are not available on the Windows Mobile v6.x platform or below. Check the current documentation for versions later than 6.x.
  • Mobile Device Manager 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 6
    • .NET 2.0 or above

Additional Resources

Last edited Nov 20, 2008 at 11:55 PM by prashantbansode, version 3

Comments

No comments yet.