Mobile Application Design Checklist
Mobile Application Design Checklist
Caching
Performance objectives are identified, such as minimum response time and battery life.
You are caching static data that is useful, and avoided caching volatile data.
You have considered data caching requirements for occasionally-connected scenarios.
Your design supports low memory detection, and prioritization of data to discard, as available
memory decreases.
You chose the appropriate cache location, such as on the device, at the mobile gateway, or in the
database server.
[edit]
Communication
Your design supports asynchronous, threaded communication to improve usability in occasionally-
connected scenarios.
You have considered the effects of receiving a phone call during communication or program
execution.
Communication over un-trusted connections, such as Web services and other over-the-air methods,
is protected.
You have considered using Web services for communication when you must access data from
multiple sources, interoperate with other applications, or work while disconnected.
You have considered message queuing when you need guaranteed delivery, asynchronous
messaging, message security, or transaction support.
[edit]
Configuration Management
Your design supports the saving and restoration of configuration data after a device reset.
Merge replication with a “buy and configure” application from a third party is used, if the enterprise
data is in Microsoft SQL Server 2005 or 2008 and desire an accelerated time to market.
You are using a binary format instead of XML for configuration files due to memory limitations.
You are protecting sensitive data in device configuration files.
You have considered using compression library routines to reduce the memory requirements for
configuration and state information.
You have considered using the Mobile Device Manager interface to manage group configuration of
devices when you have an Active Directory infrastructure.
[edit]
Data Access
You have designed application to ensure data integrity.
You are using the device database services (such as SQL Server Compact Edition) when your
application must access a disconnected database.
You are using merge replication to synchronize large volumes of data in one operation over a high
bandwidth network connection.
You have considered the overall size and impact on performance when you use XML to store or
transfer data.
You are using custom data transfer objects instead of DataSets to reduce memory overhead and
improve performance.
You are using the Microsoft Sync Framework when you must synchronize individual sets of a data
over a remote connection.
[edit]
Debugging
You understand debugging costs associated with devices you need to support.
You are using an emulator for initial testing and debugging.
You are using the device for final testing.
You have tested fully-disconnected scenarios in the design.
You understand that it may be difficult to maintain context between different types of code running
on a device.
[edit]
Deployment
Your design supports over-the-air deployment when users must be able to install and update
applications while away from the office.
You are using ActiveSync to deploy your application when the application relies heavily on a host
PC.
You are using the post-load mechanism to automatically load your application immediately after the
Windows Mobile OS starts up when you are deploying a baseline experience running on top of
Windows Mobile.
You have included multiple device executables in the CAB when you are using CAB file distribution.
Application will be deployed using an SD memory card if the application will be run only at a specific
site and you want to manually control distribution.
[edit]
Device
The application is optimized for the device by considering factors such as screen size and
orientation, network bandwidth, memory and storage space, and other hardware capabilities.
Device-specific capabilities have been considered that will enhance your application functionality,
such as accelerometers, GPUs, GPS, haptic (touch, force and vibration) feedback, compass, camera
and fingerprint readers.
You have designed a core functionality sub set when you are developing for more than one device.
You have considered adding customization for device-specific features, including functionality to
detect when the code is running on a device that can utilize this functionality.
You have created modular code that can be removed if separate executable files are required due to
device memory size constraints.
[edit]
Exception Management
Your application is designed to recover to a known good state after an exception.
You did not use exceptions to control logic flow.
Sensitive information in exception messages and log files are not revealed to users.
Unhandled exceptions are dealt with appropriately.
You have designed an appropriate logging and notification strategy for critical errors and exceptions.
[edit]
Logging
You did not store sensitive information in log files.
You have considered using the Mobile Device Manager to extract logs from mobile devices when
you have an Active Directory infrastructure.
You have considered using platform features such as health monitoring on the server, and mobile
device services on the device, to log and audit events.
You have considered logging in an abbreviated or compressed format to minimize memory and
storage impact when you carry out extensive logging on the device.
You have used OpenNetCF on the device if you do not require extensive logging.
You have decided what constitutes unusual or suspicious activity on a device, and logged
information based on these scenarios.
[edit]
Porting
The application was re-written in its entirety when porting a Rich Client application from the
desktop.
The user interface has been redesigned for the smaller screen size when porting a Web application
to a mobile device.
You have researched details to discover what code will port without modification when porting a RIA
client.
You have researched and utilized tools to assist in porting.
You have tested the custom controls which when porting to a mobile application and based on the
results decided to rewrite to find an alternative.
[edit]
Power
The user interface is not updated while the application is in the background.
Communication methods that use the least amount of power necessary are used.
Power profiles have been implemented to increase performance when device is plugged into
external power and not charging the battery.
Power consumption has been considered when using the device CPU, wireless communication,
screen, or other power-consuming resources while on battery power.
Device functionality is allowed to be powered down when not in use or not needed. Common
examples are screen backlighting, hard drives, GPS functions, speakers, wireless communications.
[edit]
Synchronization
Your design supports recovery when synchronization is reset, and is able to manage synchronization
conflicts.
You have considered the Microsoft Sync Framework when you want easy-to-implement one-way
synchronization.
You have considered using merge replication synchronization when you must support bidirectional
synchronization to SQL Server.
You have considered including over-the-air synchronization in your design when users must
synchronize data when away from the office.
You have considered including cradled synchronization in your design when users will be
synchronizing with a host PC.
You have considered store and forward synchronization using WCF over email or SMS (text
message) mechanisms.
[edit]
[edit]
Performance Considerations
Your design supports configurable options to allow the maximum use of device capabilities.
You have considered using lazy initialization to optimize for mobile device resource constraints.
You have considered limited memory resources and optimized your application to use the minimum
amount of memory.
You have considered using programming shortcuts as opposed to following pure programming
practices that can inflate code size and memory consumption.
You have balanced performance requirements with power consumption requirements.
This page was last modified 17:31, 29 March 2010. This page has been accessed 599 times. Privacy policy
About Guidance Share Disclaimers