Chapter 19: Mobile Applications
J.D. Meier, Alex Homer, David Hill,
Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat
- 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 for mobile applications.
- Identify specific scenarios for mobile applications, such as deployment, power usage, and synchronization.
- Learn the key patterns and technology considerations for designing mobile applications.
A mobile application will normally be structured as a multi-layered application consisting of user experience, business, and data layers. When developing a mobile application, you may choose to develop a thin Web-based client or a rich client. If you are building
a rich client, the business and data services layers are likely to be located on the device itself. If you are building a thin client, the business and data layers will be located on the server. Figure 1 illustrates common rich client mobile application architecture
with components grouped by areas of concern.
Figure 1 Common rich client mobile application architecture
The following design guidelines provide information about different aspects you should consider when designing a mobile application. Follow these guidelines to ensure that your application meets your requirements and performs efficiently in scenarios common
to mobile applications:
- Decide if you will build a rich client, a thin Web client, or rich Internet application (RIA). If your application requires local processing and must work in an occasionally connected scenario, consider designing a rich client. 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 user interface (UI), only limited access to local resources,
and must be portable to other platforms, design an RIA client.
- Determine the device types you will support.** When choosing which device types to support, consider screen size, resolution (DPI), CPU performance characteristics, memory and storage space, and development tool environment availability. In addition,
factor in user requirements and organizational constraints. 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.
- Design considering occasionally connected, limited-bandwidth scenarios when required.** 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 times of
connectivity. Choose hardware and software protocols based on speed, power consumption, and “chattiness,” and not just on ease of programming.
- Design a UI appropriate for mobile devices, taking into account platform constraints.** Mobile devices require a simpler architecture, simpler UI, and other specific design decisions in order to work within the constraints imposed by the device hardware.
Keep these constraints in mind and design specifically for the device instead of trying to reuse the architecture or UI from a desktop or Web application. The main constraints are memory, battery life, ability to adapt to difference screen sizes and orientations,
security, and network bandwidth.
- Design a layered architecture appropriate for mobile devices that improves reuse and maintainability.** Depending on the application type, multiple layers may be located on the device itself. Use the concept of layers to maximize separation of concerns,
and to improve reuse and maintainability for your mobile application. However, aim to achieve the smallest footprint on the device by simplifying your design compared to a desktop or Web application.
- Design considering device resource constraints such as battery life, memory size, and processor speed.** Every design decision should take into account the limited CPU, memory, storage capacity, and battery life of mobile devices. Battery life is
usually the most limiting factor in mobile devices. Backlighting, reading and writing to memory, wireless connections, specialized hardware, and processor speed all have an impact on the overall power usage. When the amount of memory available is low, the
Microsoft® Windows Mobile® operating system may ask your application to shut down or sacrifice cached data, slowing program execution. Optimize your application to minimize its power and memory footprint while considering performance during this
Mobile Client Frame
There are several common issues that you must consider as your develop your design. These issues can be categorized into specific areas of the design. The following table lists the common issues for each category where mistakes are most often made.
Table 1 Mobile Client Frame
|Authentication and Authorization
||Failing to authenticate in occasionally connected scenarios
||Failing to authorize in occasionally-connected scenarios
||Failing to use authentication and authorization over a virtual private network (VPN)
||Failing to authenticate during synchronization over the air
||Failing to authenticate during synchronization with the host PC
||Failing to authenticate for all connection scenarios, such as over the air, cradled, Bluetooth, and Secure Digital (SD) cards
||Failing to appreciate the differences between security models of different devices
||Caching 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
||Failing to protect sensitive data over the air
||Failing to secure Web service communication
||Failing to secure communication over a VPN
||Not appreciating the performance impact of communication security on limited-bandwidth connections
||Not managing limited-bandwidth connections efficiently
||Not managing connections to multiple network services efficiently
||Not designing to work with intermittent connectivity
||Not considering connection cost or allowing the user to manage connections
||Not designing to minimize power usage when running on battery power
||Failing to use the appropriate communication protocol
||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
||Failing to implement data-access mechanisms that work with intermittent connectivity
||Not considering database access performance
||Navigating through large datasets when not required
||Failing to consider appropriate replication technologies and techniques
||Failing to consider access to device database services such as Microsoft SQL Server® Compact Edition
||Failing to consider device heterogeneity, such as screen size and CPU power
||Not presenting user-friendly error messages to the user
||Failing to protect sensitive information
||Failure to consider the processing power of the device
||Not recovering application state after an exception
||Revealing sensitive information to the end user
||Not logging sufficient details about the exception
||Using exceptions to control application flow
||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
||Failing to rewrite the existing rich client UI to suit the device
||Failing to explore the available porting tools
||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
||Failing to appreciate debugging costs when choosing to support multiple device types
||Failing to design with debugging in mind; for example, using emulators instead of the actual devices
||Failing to debug in all connection scenarios
||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
||Not validating input and data during host PC communication
||Not validating input and data during over-the-air communication
||Failing to protect hardware resources, such as the camera and initiation of phone calls
||Not designing validation with limited resources and performance in mind
Authentication and Authorization
Designing an effective authentication and authorization strategy is important for the security and reliability of your application. Weak authentication can leave your application vulnerable to unauthorized use. Mobile devices are usually designed to be single-user
devices and normally lack basic user profile and security tracking beyond just a simple password. Other common desktop mechanisms are also likely to be missing. The discoverability of mobile devices over protocols such as Bluetooth can present users with unexpected
scenarios. Mobile applications can also be especially challenging due to connectivity interruptions. Consider all possible connectivity scenarios, whether over-the-air or hard-wired.
Consider the following guidelines when designing authentication and authorization:
- Design authentication for over-the-air, cradled synchronization, Bluetooth discovery, and local SD card scenarios.
- Consider that different devices might have variations in their programming security models, which can affect authorization to access resources
- Do not assume that security mechanisms available on larger platforms will be available on a mobile platform, even if you are using the same tools. For example, access control lists (ACLs) are not available in Windows Mobile, and consequently there is no
operating system–level file security.
- Ensure that you require authentication for access by Bluetooth devices.
- Identify trust boundaries within your mobile application layers; for instance, between the client and the server or the server and the database. This will help you to determine where and how to authenticate.
Use caching to improve the performance and responsiveness of your application, and to support operation when there is no network connection. Use caching to optimize reference data lookups, to avoid network round trips, and to avoid unnecessarily duplicated
processing. When deciding what data to cache, consider the limited resources of the device; you will have less storage space available than on a PC.
Consider the following guidelines when designing caching:
- Identify your performance objectives. For example, determine your minimum response time and battery life. Test the performance of the specific devices you will be using. Most mobile devices use only flash memory, which is likely to be slower than the memory
used in desktop machines.
- 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.
- Cache static data that is useful, and avoid caching volatile data. However, consider caching any data, including volatile data, that the application will need in an occasionally connected or offline scenario.
- Consider using SQL Server Compact edition for caching instead of device memory. Memory consumed by the application may be cleared in low-memory situations.
- Choose the appropriate cache location, such as on the device, at the mobile gateway, or in the database server.
Device communication includes wireless communication (over the air) and wired communication with a host PC, as well as more specialized communication such as Bluetooth or Infrared Data Association (IrDA). When communicating over the air, consider data security
to protect sensitive data from theft or tampering. If you are communicating through Web service interfaces, use mechanisms such as the WS-Secure standards to secure the data. Keep in mind that wireless device communication is more likely to be interrupted
than communication from a PC, and that your application might be required to operate for long periods in a disconnected state.
Consider the following guidelines when designing your communication strategy:
- Design asynchronous, threaded communication to improve usability in occasionally connected scenarios.
- If you are designing an application that will run on a mobile phone, consider the effects of receiving a phone call during communication or program execution. Design the application to allow it to suspend and resume, or even exit the application.
- Protect communication over untrusted connections, such as Web services and other over-the-air methods.
- If you must access data from multiple sources, interoperate with other applications, or work while disconnected, consider using Web services for communication.
- If you are using WCF for communication and need to implement message queuing, consider using WCF store and forward.
When designing device configuration management, consider how to handle device resets, as well as whether you want to allow configuration of your application over the air or from a host PC.
Consider the following guidelines when designing your configuration-management strategy:
- Design for the restoration of configuration after a device reset.
- If you have your enterprise data in Microsoft SQL Server 2005 or 2008 and desire an accelerated time to market, consider using merge replication with a “buy and configure” application from a third party. Merge replication can synchronize data in a single
operation regardless of network bandwidth or data size.
- Due to memory limitations, choose binary format over Extensible Markup Language (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 a Microsoft Active Directory® directory service infrastructure, consider using the System Center Mobile Device Manager interface to manage group configuration, authentication, and authorization of devices. See the Technology Considerations
section for requirements for the Mobile Device Manager.
Data access on a mobile device is constrained by unreliable network connections and the hardware constraints of the device itself. When designing data access, consider how low bandwidth, high latency, and intermittent connectivity will impact your design.
Consider the following guidelines when designing data access:
- Always prefer strongly typed collections or generics over DataSets and XML to reduce memory overhead and improve performance. If you decide to use DataSets and are only reading (and not writing) data, utilize
- Consider using a local device database that provides synchronization services, such as SQL Server Compact Edition. Only architect a special mechanism to synchronize data if the standard data synchronization cannot meet your requirements.
- Program for data integrity. Files left open during device suspend and power failures may cause data-integrity issues, especially when data is stored on a removable storage device. Include exception handling and retry logic to ensure that file operations
- Do not assume that removable storage will always be available, as a user can remove it at any time. Check for the existence of a removable storage device before writing or using FlushFileBuffers.
- If you need to ensure data integrity in case the device loses power or has connectivity disruptions, considering using transactions with SQL Server Mobile.
- If 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 typed objects instead of DataSets to reduce memory overhead and improve performance. If you are only reading and not writing data, utilize
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 (GPUs), global positioning systems (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 for device-specific features when they are detected.
- Create modular code to allow easy module removal from executables. This covers cases where separate smaller executable files are required due to device memory-size constraints.
Designing an effective exception-management strategy is important for the security and reliability of your application. Good exception handling in your mobile application prevents sensitive exception details from being revealed to the user, improves application
robustness, and helps to avoid your application being left in an inconsistent state in the event of an error.
Consider the following guidelines when designing for exception management:
- Design your application to recover to a known good state after an exception occurs.
- Do not use exceptions to control logic flow.
- Do not catch exceptions unless you can handle them.
- Design a global error handler to catch unhandled exceptions.
- Design an appropriate logging and notification strategy that does not reveal sensitive information for critical errors and exceptions.
Because of the limited memory on mobile devices, logging and instrumentation should be limited to only the most necessary cases; for example, attempted intrusion into the device. When devices are designed to be a part of a larger infrastructure, choose to track
most device activity at the infrastructure level. Generally, auditing is considered most authoritative if the audits are generated at the precise time of resource access, and by the same routines that access the resource. Consider the fact that some of the
logs might have to be generated on the device and must be synchronized with the server during periods of network connectivity.
Consider the following guidelines when designing logging:
- If you carry out extensive logging on the device, consider logging in an abbreviated or compressed format to minimize memory and storage impact. There is no system Event Log in Windows Mobile.
- Consider using a third-party logging mechanism that supports the .NET Compact Framework. Several of these mechanisms are available at the time this document was written (OpenNetCF, nLog, log4Net).
- 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 the Technology Considerations section for requirements for the Mobile Device Manager.
- Do not store sensitive information in log files.
- Decide what constitutes unusual or suspicious activity on a device, and log information based on these scenarios.
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
- If you are porting an RIA client, research details to discover which code will port without modification. Consult the technology considerations section of this chapter for specific advice.
- Research and utilize tools to assist in porting. For example, Java-to-C convertors are available. When converting from Smartphone to Pocket PC code, Microsoft Visual Studio® will allow you to change the target platform and will provide warnings when
you are using Smartphone-specific functionality. You can also link Visual Studio Desktop and Mobile projects to assist in knowing what is portable between the two projects.
- Do not assume that you can port custom controls as-is to a mobile application. Supported APIs, memory footprint, and UI behavior are different on a mobile device. Test the controls as early as possible so that you can plan to rewrite them or find an alternative
Power is the most limiting factor for a mobile device. All design decisions should at take into account how much power the device consumes and its effect on overall battery life. If you have a choice in devices, consider devices that can draw power from Universal
Serial Bus (USB) or other types of data hookups. Research communication protocols for their power consumption.
Consider the following guidelines when designing for power consumption:
- To conserve battery life, do not update the UI while the application is in the background.
- Choose communication methods considering both power usage as well as network speed.
- Consider deferring nonessential wireless communications until the device is under external power.
- Implement power profiles to increase performance when the device is plugged into external power and not charging its battery.
- Design so that parts of the devices can be powered down when not in use, or when not required. Common examples are screen backlighting, hard drives, GPS functions, speakers, and wireless communications.
- Design services and communications to transfer the smallest number of bytes possible over the air. Choose protocols, design service interfaces, and batch communications with this goal in mind.
- If you are considering using the 3G hardware communications protocol, consider that while it is significantly faster, it also currently uses much more power than its predecessors, such as the Edge protocol. When you are using 3G, be sure to communicate
in batched bursts and to shut down communication at times when it is not needed.
Consider whether you want to support over-the-air synchronization, cradled synchronization, or both. Because synchronization will often involve sensitive data, consider how to secure your synchronization data, especially when synchronizing over the air. Design
your synchronization to handle connection interruptions gracefully, either by canceling the operation or by allowing it to resume when a connection becomes available. Merge replication allows both upload-only and bidirectional synchronization and is a good
choice for infrastructures utilizing newer versions of SQL Server. Consider the Microsoft Sync Framework as it can provide robust synchronization services in a wide variety of situations.
Consider the following guidelines when designing synchronization:
- Design for recovery when synchronization is reset, and decide how to manage synchronization conflicts.
- If you must support bidirectional synchronization to SQL Server, consider using merge replication synchronization. Remember that merge synchronization will synchronize all of the data in the merge set, which may require additional network bandwidth and
can impact performance.
- If your users must synchronize data when away from the office, consider including over-the-air synchronization in your design.
- If your users will be synchronizing with a host PC, consider including cradled synchronization in your design.
- Consider store-and-forward synchronization using WCF rather than e-mail or SMS (text message), as WCF guarantees delivery and works well in a partially connected scenario.
Mobile application debugging can be much more expensive than debugging a similar application on a PC. Consider this debugging cost when deciding which devices, and how many devices, your application will support. Also keep in mind that it can be harder to get
debug information from the device, and that device emulators do not always perfectly simulate the device hardware environment.
Consider the following guidelines when designing your debugging strategy:
- Understand your debugging costs when choosing which devices to support. Factor in tools support, the cost of initial (and perhaps replacement) test devices, and the cost of software-based device emulators.
- If you have the device you are targeting, debug your code on the actual device rather than on an emulator.
- If the device is not available, use an emulator for initial testing and debugging. Consider that an emulator might run code more slowly than the actual device. As soon as you obtain the device, switch to running code on the device connected to a normal
PC. Perform final testing on your device when not connected to a PC. Add 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 being disconnected from a PC debugging session.
- If you are an OEM or ODM and your device has not yet been created, note that it is possible to debug a mobile program on a dedicated x86-based Microsoft Windows® CE PC. Consider this option until your device is available.
When designing the UI for a mobile application, do not try to adapt or reuse the UI from a desktop application. Design your device UI so that it is as simple as possible, and designed specifically for pen-based input and limited data entry capabilities as appropriate.
Consider the fact that your mobile application will run in full-screen mode and will only be able to display a single window at a time. Therefore, blocking operations will prevent the user from interacting with the application. Consider the various screen
sizes and orientations of your target devices when designing your application UI.
Consider the following guidelines when designing the UI for your mobile application:
- Design considering that a person’s hand can block a touch-screen UI during input with a stylus or finger. For example, place menu bars at the bottom of the screen, expanding options upwards.
- Design for a single-window, full-screen UI. If your device will be a single-user device running only the main application, consider using kiosk mode. Keep in mind that Windows Mobile does not support a kiosk mode, so you will need to use Windows CE.
- Consider input from various sources such as stylus, keypad, and touch. For example, accommodate touch-screen input by making buttons large enough, and lay out controls so that the UI is usable using a finger or stylus for input. Design for various screen
sizes and orientations.
- Give the user visual indication of blocking operations; for example, an hourglass cursor.
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
Consider the following guidelines when designing your performance strategy:
- Design configurable options to allow the maximum use of device capabilities. Allow users to turn off features they do not require in order to save power.
- 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
- 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.
Mobile applications can be deployed using many different methods. Consider the requirements of your users, as well as how you will manage the application, when designing for deployment. Ensure that you design to allow for the appropriate management, administration,
and security for application deployment.
Deployment scenarios listed for Windows Mobile device applications, with the more common ones listed first, are:
- Microsoft Exchange ActiveSync® using a Windows Installer file (MSI).
- Over the air, using HTTP, SMS, or CAB files to provide install and run functionality.
- Mobile Device Manager–based, using Active Directory to load from a CAB or MSI file.
- Post load and auto-run, which loads a company-specific package as part of the operating system.
- Site loading, manually using an SD card.
Consider the following guidelines when designing your deployment strategy:
- If your users must be able to install and update applications while away from the office, consider designing for over-the-air deployment.
- If you are using CAB file distribution for multiple devices, include multiple device executables in the CAB file. Have the device detect which executable to install, and discard the rest.
- If your application relies heavily on a host PC, consider using ActiveSync to deploy your application.
- If you are deploying a baseline experience running on top of Windows Mobile, considering using the post-load mechanism to automatically load your application immediately after the Windows Mobile operating system starts up.
- If your application will be run only at a specific site, and you want to manually control distribution, consider deployment using an SD memory card.
Key patterns are organized by the key categories detailed in the Mobile Client Frame in the following table. Consider using these patterns when making design decisions for each category.
||Data Transfer Object
- For more information on Application Controller, Model View Controller (MVC),
Domain Model, Transaction Script, Active Record, Data Mapper,
Data Transfer Object, patterns see “Patterns of Enterprise Application Architecture (P of EAA)” at
- For more information on Entity Translator pattern see “Useful Patterns for Services” at
- For more information on Active Object pattern see “Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects.” Published by Chichester, England; New York: John Wiley & Sons Ltd., 2000
- For more information on Communicator pattern see “Patterns for point-to-point communications” by Guidi-Polanco, F., Cubillos F., C., Menga, G., & Penha, S. (2003)
- For more information on Pagination pattern see “Improving Application Performance by Implementing Paginated Lists” at
- For more information on synchronization pattern see “Data Patterns” at
- For more information on Lazy Acquisition pattern see “Pattern-Oriented Software Architecture, Patterns for Resource Management. John Wiley & Sons.”
- Active Object.** Support asynchronous processing by encapsulating the service request and service completion response.
- Active Record. Include a data access object within a domain entity.
- Application Controller. An object that contains all of the flow logic, and is used by other Controllers that work with a Model and display the appropriate View.
- Communicator.** Encapsulate the internal details of communication in a separate component that can communicate through different channels.
- Data Transfer Object (DTO).** An object that stores the data transported between processes, reducing the number of method calls required.
- Domain Model.** A set of business objects that represents the entities in a domain and the relationships between them.
- Entity Translator.** An object that transforms message data types into business types for requests, and reverses the transformation for responses.
- Lazy Acquisition. Defer the acquisition of resources as long as possible to optimize device resource use.
- Model-View-Controller.** Separate the UI code into three separate units: Model (data), View (interface), and Presenter (processing logic), with a focus on the View. Two variations on this pattern include Passive View and Supervising Controller, which
define how the View interacts with the Model.
- Model-View-Presenter.** Separate request processing into three separate roles, with the View being responsible for handling user input and passing control to a Presenter object.
- Pagination.** Separate large amounts of content into individual pages to optimize system resources and minimize use of screen space.
- Reliable Sessions.** End-to-end reliable transfer of messages between a source and a destination, regardless of the number or type of intermediaries that separate the endpoints**
- Synchronization. A component installed on a device tracks changes to data and exchanges information with a component on the server when a connection is available.**
- Transaction Script.** Organize the business logic for each transaction in a single procedure, making calls directly to the database or through a thin database wrapper.
The following guidelines contain suggestions and advice for common scenarios for mobile applications and technologies.
Microsoft Silverlight for Mobile
Consider the following guidelines if you are using Microsoft Silverlight® for Mobile:
- At the time of this document’s release, Silverlight for Mobile was an announced product under development, but not yet released.
- If you want to build applications that support rich media and interactivity and have the ability to run on both a mobile device and desktop as is, consider using Silverlight for Mobile. Silverlight 2.0 code created to run on the desktop in the Silverlight
2.0 plug-in will run in the Windows Mobile Silverlight plug-in in the latest version of Microsoft Internet Explorer for Mobile. Consider that while it is possible to use the same Silverlight code in both places, you should take into account the differing screen
size and resource constraints on a mobile device. Consider optimizing the code for Windows Mobile.
- If you want to develop Web pages for both desktop and mobile platforms, consider Silverlight for Mobile or normal ASP.NET/HMTL over ASP.NET for Mobile unless you know that your device cannot support either of these alternatives. As device browsers have
become more powerful, they are able to process the same native HTML and ASP.NET targeted by the desktop, thus making ASP.NET Mobile development less important. ASP.NET Mobile Controls currently supports a variety of mobile devices through specific markup adapters
and device profiles. While ASP.NET Mobile Controls automatically render content to match device capabilities at run time, there is overhead associated with testing and maintaining the device profiles. Development support for these controls is included in Microsoft
Visual Studio 2003 and 2005 but is no longer supported in Visual Studio 2008. Run-time support is currently still available, but may be discontinued in the future. For more information, see the links available in the Additional Resources section.
.NET Compact Framework
Consider the following guidelines if you are using the Microsoft .NET Compact Framework:
- If you are familiar with the Microsoft .NET Framework and are developing for both the desktop and mobile platforms concurrently, consider that the .NET Compact Framework is a subset of the .NET Framework class library. It also contains some classes exclusively
designed for Windows Mobile. The .NET Compact Framework supports only Microsoft Visual Basic® and Microsoft Visual C#® development.
- If you are attempting to port code that uses Microsoft Foundation Classes (MFC), consider that it is not trivial due to MFC’s dependency on Object Linking and Embedding (OLE). The Windows Compact Edition supports COM, but not OLE. Check to see if the OLE
libraries are available for separate download to your device before trying to use MFC on a mobile device.
- If you have issues tracing into a subset of Windows Mobile code with the Visual Studio debugger, consider that you might require multiple debug sessions. For example, if you have both native and managed code in the same debug session, Visual Studio might
not follow the session across the boundary. In this case, you will require two instances of Visual Studio running and will have to track the context between them manually.
Consider the following general guidelines for Windows Mobile applications:
- If you are targeting an application for both Windows Mobile Professional and Windows Mobile Standard editions, consider that the Windows Mobile security model varies on the different versions of Windows Mobile. Windows Code that works on one platform might
not work on the other because of the differing security models for APIs. Check the Windows Mobile documentation for your device and version.
- If you will have to manage your application in the future or are upgrading an existing application, be sure that you understand the Windows Mobile operating system derivation, product naming, and versioning tree. There are slight differences between each
version that could potentially impact your application.
- Windows Mobile is derived from releases of the Windows CE operating system.
- Both Windows Mobile version 5.x and 6.x are based on Windows CE version 5.x.
- Windows Mobile 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 is mentioned in this article as a possible solution for authorizing, tracking, and collecting logs from mobile devices, assuming that you have an Active Directory infrastructure. MDM also requires a number of other products to
fully function, including:
- Windows Mobile 6.1 on devices
- Windows Software Update Service (WSUS) 3.0
- Windows Mobile Device Management Server
- Enrollment Server
- Gateway Server
- Active Directory as part of Windows Server
- SQL Server 2005 or above
- Microsoft Certificate Authority
- Internet Information Server (IIS) 6.0
- .NET Framework 2.0 or above
Consider the following guidelines if you are choosing a Windows Embedded technology:
- If you are designing for a set-top box or other larger-footprint device, consider using Windows Embedded Standard.
- If you are designing for a point-of-service (POS) device such as an automated teller machine (ATMs, customer-facing kiosks, or self-checkout systems), consider using Windows Embedded for Point of Service.
- If you are designing for a GPS-enabled device or a device with navigation capabilities, consider using Microsoft Windows Embedded NavReady™. Note that Windows Embedded NavReady 2009 is built on Windows Mobile 5.0, while Windows Mobile version 6.1 is used
in the latest versions for Windows Mobile Standard and Professional. If you are targeting a common codebase for NavReady and other Windows Mobile devices, be sure to verify that you are using APIs available on both platforms.