Compartir por

Chapter 24: Designing Mobile Applications

  • Artigo

For more details of the topics covered in this guide, see Contents of the Guide.

Contents

  • Overview
  • General Design Considerations
  • Specific Design Issues
  • Technology Considerations
  • Deployment Considerations
  • Relevant Design Patterns
  • Additional Resources

Overview

This chapter will help you to understand when and how mobile applications are an appropriate solution, and the key design considerations for mobile applications. This includes learning about the components found in a mobile application; specific issues for mobile applications such as deployment, power usage, and synchronization; and the key patterns and technology considerations.

A mobile application will normally be structured as a multilayered application consisting of presentation, 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, all of the layers will be located on the server. Figure 1 illustrates common rich client mobile application architecture with components grouped by areas of concern.

Ee658108.8ec1d9ab-f582-4365-aae5-05385f5235e5(en-us,PandP.10).png

Figure 1

The typical structure of a mobile application

A mobile application generally contains user interface components in the presentation layer, and perhaps may include presentation logic components. The business layer, if it exists, will usually contain business logic components, any business workflow and business entity components that are required by the application, and, optionally, a façade. The data layer will usually include data access and service agent components. In order to minimize the footprint on the device, mobile applications generally use less rigid layering approaches and fewer discrete components. For more information about layered design, see Chapter 5, "Layered Application Guidelines." For more information about the components appropriate for each layer, see Chapter 10 "Component Guidelines."

General Design Considerations

The following design guidelines provide information about different aspects that 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. A rich client application 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 an RIA client.
  • Determine the device types you will support. When choosing which device types to support, consider screen size and resolution, CPU performance characteristics, memory and storage space, and development tool environment availability. In addition, factor in user requirements and organizational constraints. You may require specific hardware such as a global positioning system (GPS) or a camera, which may impact not only your application type, but also your device choice.
  • Consider occasionally connected and limited-bandwidth scenarios when appropriate. If your mobile device is a stand-alone device, you will not need to account for connection issues. When network connectivity is required, mobile applications should handle cases when a network connection is intermittent or not available. It is vital in this case to design your caching, state management, and data access mechanisms with intermittent network connectivity in mind; batch communications for delivery when connectivity is available. Choose hardware and software protocols based on speed, power consumption, and granularity, 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.
  • Consider 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 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.

Specific Design Issues

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 sections contain guidelines to help you resolve the common issues in each area:

  • Authentication and Authorization
  • Caching
  • Communication
  • Configuration Management
  • Data Access
  • Device Specifics
  • Exception Management
  • Logging
  • Porting Applications
  • Power Management
  • Synchronization
  • Testing
  • User Interface
  • Validation

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 risks. Mobile application design 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:

  • Design authentication and authorization for both fully connected and occasionally connected scenarios; including synchronization over the air, cradled (PC) synchronization, Bluetooth discovery, synchronization over a Virtual Private Network (VPN), and local SD memory card synchronization.
  • Consider that different devices might have variations in their programming security models, which can affect authorization for resource access.
  • 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.
  • Identify trust boundaries within your mobile application layers; for example, 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. Caching can optimize reference data lookups, avoid network round trips, and prevent 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 desktop computer. 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 computers.
  • 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. However, consider caching any data, including volatile data, that the application will need in an occasionally connected or offline scenario. Also, ensure that the application can survive the situation where cached data is not available in offline or occasionally connected scenarios.
  • Choose the appropriate cache location, such as on the device, at the mobile gateway, or in the database server. Consider using SQL Server Compact edition for caching instead of device memory because memory consumed by the application may be cleared in low-memory situations.
  • Ensure that sensitive data is encrypted when caching, especially when caching data in removable memory media, but also consider encryption when caching data in device memory.

For more information about designing a caching strategy, see Chapter 17 "Crosscutting Concerns."

Communication

Device communication includes wireless communication (over the air) and wired communication with a host computer, 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 computer, 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:

  • Design asynchronous, threaded communication to improve performance and usability in occasionally connected scenarios. Limited bandwidth connections common on mobile devices can reduce performance and affect usability, especially if they block the user interface. Use appropriate communication protocols, and consider how the application will behave when multiple connection types are available. Consider allowing users to choose the connection to use, and to switch off communication to preserve battery life when appropriate.
  • 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. Consider using encryption and digital signatures for sensitive data, and ensure that data passed over a VPN is protected. However, consider the effects of communication security on performance and battery life.
  • If you must access data from multiple sources, interoperate with other applications, or work while disconnected, consider using Web services for communication. Ensure you manage connections efficiently, especially in limited bandwidth communication scenarios.
  • If you are using WCF for communication and must implement message queuing, consider using WCF store and forward.

For more information about communication protocols and techniques, see Chapter 18 "Communication and Messaging."

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 computer. Consider the following guidelines when designing your configuration management strategy:

  • Choose an appropriate format for configuration information. Consider a binary format over XML to minimize memory use. Consider using compression library routines to reduce the memory requirements for storing configuration and state information. Ensure that you encrypt sensitive data stored in configuration files.
  • Ensure that your design supports restoration of configuration after a device reset. Consider how you will synchronize configuration information over the air and with a host computer when cradled, and ensure that you are familiar with the techniques used by different manufacturers for loading configuration settings.
  • If you have your enterprise data in Microsoft SQL Server 2005 or 2008 and require 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.
  • If you have an Active Directory infrastructure, consider using the System Center Mobile Device Manager interface to manage group configuration, authentication, and authorization of devices. See "Technology Considerations" for the requirements of 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 affect your design. Consider the following guidelines when designing data access:

  • Consider using a local device database that provides synchronization services, such as SQL Server Compact Edition. Only design a custom mechanism to synchronize data if the standard data synchronization features cannot meet your requirements.
  • Program for data integrity. Files that remain 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. To ensure data integrity in cases where the device loses power or connectivity, consider using transactions with SQL Server Mobile.
  • 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 to it or using FlushFileBuffers.
  • 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.
  • Minimize performance impact by designing for efficient database access and data processing. Consider the use of typed objects instead of DataSets to reduce memory overhead and improve performance. If you are only reading and not writing data, utilize DataReaders. Avoid process intensive operation such as navigating through large data sets.

For more information about designing a data layer, see Chapter 8 "Data Layer Guidelines."

Device Specifics

Mobile device design and development is unique due to the constrained and differing nature of device hardware. 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.
  • Consider device-specific capabilities that you can use to enhance your application functionality such as accelerometers, graphics processing units, GPS, haptic (touch, force, and vibration) feedback, compass, camera, and fingerprint readers.
  • If you are developing for more than one device, design first for the subset of functionality that exists on all of the devices and then customize the code to detect and use device-specific features when they are available.
  • 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.
  • Create modular code to allow easy module removal from executables. This covers cases where separate smaller executable files are required due to constraints in device memory size.
  • 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 using lazy initialization so that objects are instantiated only when required.

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 keep your application from remaining in an inconsistent state when an error occurs. Consider the following guidelines when designing for exception management:

  • Design your application to recover to a known good state after an exception occurs without revealing sensitive information to the end user.
  • Catch exceptions only if you can handle them, and do not use exceptions to control logic flow. Ensure that you design a global error handler to catch unhandled exceptions.
  • Design an appropriate logging and notification strategy that stores sufficient details about exceptions, but bear in mind memory and storage limitations of mobile devices. Ensure that user friendly exception messages are displayed, and that they do not reveal sensitive information for critical errors and exceptions.

For more information about designing an exception management strategy, see Chapter 17 "Crosscutting Concerns."

Logging

Because of the limited memory available 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:

  • There is no Event Log mechanism in Windows Mobile. Consider using a third-party logging mechanism that supports the .NET Compact Framework, such as OpenNetCF, NLog, or log4Net (see Additional Resources at the end of this chapter for more details). Also, consider how you will access logs stored on the device.
  • If you carry out extensive logging on the device, consider logging in an abbreviated or compressed format to minimize memory and storage impact. Alternatively, consider remote logging instead of logging on the device.
  • Consider using platform features such as health monitoring on the server, and mobile device services on the device, to log and audit events. Explore adding remote health monitoring capabilities using the Open Mobile Alliance Device Management (OMA DM) standard.
  • 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 "Technology Considerations" for the requirements of Mobile Device Manager.
  • Do not store sensitive information in log and audit files unless absolutely necessary, and ensure that any sensitive information is protected through encryption.
  • Decide what constitutes unusual or suspicious activity on a device, and log information based on these scenarios.

Porting Applications

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 a RIA client, carry out research 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, Visual Studio allows you to change the target platform and provides warnings when you are using Smartphone-specific functionality. You can also link Visual Studio Desktop and Mobile projects to discover what is portable between the two projects.
  • Do not assume that you can port custom controls to a mobile application without modification. 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 Management

Power is the major limiting design factor for mobile devices. All design decisions should take into account how much power the device consumes, and their effect on overall battery life. If you have a choice, consider devices that can draw power from Universal Serial Bus (USB) or other types of data connections. Research communication protocols and investigate their relative power consumption. Consider the following guidelines when designing for power consumption:

  • Implement power profiles to increase performance when the device is plugged into external power and not charging its battery. Allow the user to turn off features of the device when not in use or when not required. Common examples are screen backlighting, hard drives, GPS functions, speakers, and wireless communications.
  • To conserve battery life, do not update the UI while the application is running in the background.
  • Choose protocols, design service interfaces, and batch communications in such a way as to transfer the smallest number of bytes possible over the air. Consider both power usage as well as network speed when choosing communication methods, and consider deferring nonessential wireless communications until the device is using external power.
  • 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 required.

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, which can provide robust synchronization services in a wide variety of situations. Consider the following guidelines when designing synchronization:

  • If your users will be synchronizing with a host computer, consider including cradled synchronization in your design. If your users must synchronize data when away from the office, consider including over the air synchronization in your design.
  • Ensure that the application can recover when synchronization is reset or when synchronization is interrupted, and decide how you will manage synchronization conflicts.
  • Ensure that synchronization communication is protected, perhaps using encryption and digital certificates, and use secure channels. Be especially sure to apply appropriate authentication and authorization when using Bluetooth synchronization.
  • 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 adversely affect performance.
  • Consider store and forward synchronization using WCF rather than e-mail or SMS (text message), as WCF guarantees delivery and works well in occasionally connected scenarios.

Testing

Mobile application debugging can be much more costly than debugging a similar application on a computer. 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 access to the physical device you are targeting, debug your code on the actual device rather than using an emulator. If the device is not available, use an emulator for initial testing and debugging. Consider that an emulator might run code more slowly than the actual device.
  • As soon as you obtain the physical device, switch to running code on the device connected to a normal computer. Test scenarios where your device is fully disconnected from any network or connection, including being disconnected from a computer debugging session, and perform final testing on your device when not connected to a computer. Add temporary or permanent mechanisms to debug problems in this scenario. Consider the needs of people who will support the device.
  • If you are an OEM and your device has not yet been created, note that it is possible to debug a mobile program on a dedicated x86-based Windows CE computer. Consider this option until your device is available.

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 tailored specifically for pen-based input and limited data entry capabilities where 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; and, therefore, blocking operations will prevent the user from interacting with the application. Consider the following guidelines when designing the UI for your mobile application:

  • 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.
  • Take into account the various screen sizes and orientations of your target devices when designing your application UI. Also, consider the limitations imposed by the small screen size, limited API, and reduced range of UI controls compared to desktop environments.
  • Design for usability by supporting touchscreen or stylus-driven UI. Place menu bars and other controls at the bottom of the screen (expanding upwards when required) to prevent the user's hands from obscuring the display. Support touchscreen input by making buttons large enough, and lay out controls so that the UI is usable using a finger or stylus for input.
  • Give the user visual indication of blocking operations; for example, an hourglass cursor.

Validation

Use validation to protect the device and your application, and to improve usability. Validating input values before submitting them to a remote server can reduce communication roundtrips and improve the performance and usability of the application, especially in occasionally connected or disconnected scenarios. When designing validation, consider the following guidelines:

  • Validate data input by the user where possible to prevent unnecessary communication and server roundtrips. This also makes the application more responsive when the user enters invalid values.
  • Validate all data received during communication with a host computer and during over the air communication.
  • Ensure that you protect hardware resources, such as the camera and initiation of phone calls, by validating code and actions that automatically initiate these features.
  • Consider the limited resources and performance of the device by designing efficient validation mechanisms that have the minimum memory footprint.

For more information about validation techniques, see Chapter 17 "Crosscutting Concerns."

Technology Considerations

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

Microsoft Silverlight for Mobile

At the time of release of this guidance, Silverlight for Mobile was an announced product under development but not released. Consider the following guidelines if you are using Silverlight for Mobile:

  • 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, 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 browser. Consider that while it is possible to use the same Silverlight code on both mobile device and desktop, you should take into account the differing screen size and resource constraints of 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 instead of using ASP.NET for Mobile, unless you know that your device cannot support either alternative. As device browsers have become more powerful, they are able to process the same native HTML and ASP.NET targeted at the desktop, thus making ASP.NET mobile-specific development less important. ASP.NET for Mobile currently supports a variety of mobile devices through specific markup adapters and device profiles. While ASP.NET for Mobile automatically renders 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 not included in Visual Studio 2008. Run-time support is currently still available but may be discontinued in the future. For more information, see "Additional Resources" at the end of this chapter.

.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 the Microsoft Visual Basic® and Microsoft Visual C#® development systems.
  • 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 you must 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. 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. Also see the “Additional Resources” section at the end of this chapter.
  • 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 Pocket PC was renamed Windows Mobile Professional starting with Windows Mobile 6.0.
    • Windows Mobile Smartphone was renamed Windows Mobile Standard starting with Windows Mobile 6.0.
    • 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 (MDM) is a possible solution for authorizing, tracking, and collecting logs from mobile devices, assuming that you have an Active Directory infrastructure. As well as Windows Mobile 6.1 on the managed devices, MDM also requires a number of other products to be installed on the server in order to function fully, including:
    • Windows Mobile 6.1 on devices
    • Windows Server 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 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™ software. 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.

Deployment Considerations

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 for Windows Mobile device applications, with the more common ones listed first, are:

  • Microsoft Exchange ActiveSync® technology 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 autorun, 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 computer, 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.

For more information on deployment patterns and scenarios, see Chapter 19 "Physical Tiers and Deployment."

Relevant Design Patterns

Key patterns are organized into categories such as Caching, Communication, Data Access, Synchronization, and UI; as shown in the following table. Consider using these patterns when making design decisions for each category.

Category

Relevant patterns

Caching

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

Communication

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

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

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

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.

Data Access

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

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.

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.

Synchronization

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.

UI

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.

Model-View-Controller. Separate the data in the domain, the presentation, and the actions based on user input into three separate classes. The Model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the View), and responds to instructions to change state (usually from the Controller). The View manages the display of information. The Controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate.

Model-View-Presenter. Separate request processing into three roles, with the View being responsible for handling user input, the Model responsible for application data and business logic, and the Presenter responsible for presentation logic and for coordinating the interaction between the View and the Model.

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

Additional Resources

For more information, see the following resources: