Mobile Application Checklist
User Interface, Persistence, Integration and Deployment...
Use this checklist to identify those features you may want to
incorporate into your Windows Mobile Application. Where appropriate we
highlight some of the advantages and disadvantages of the various
options. The list is broken into 4 sections;
User Interface, Persistence,
Most clients want the UI to be as responsive as possible, this requires
efficient use of the limited resources available on the mobile device.
The UI needs to cater for fast intuitive data input. This necessitates
making use of appropriate UI elements – large buttons that can be
clicked by personnel wearing gloves, large tabs – so that users can swap
between tabs easily without stylus use. That said though, data entry in
Windows Mobile often necessitates stylus use.
Dynamic User Interfaces
If you make the Windows Mobile UI dynamic the forms will need to be
built “on the fly” on the device.
The advantage of a dynamic user interface is that any UI enhancements
are easy to deploy; this is a flexible approach. The disadvantages of
dynamic user interfaces are the extra development effort and the
performance impact on the device – each time the UI is displayed it
needs to be built.
Support for different languages; e.g. English, French, Spanish etc
Adv: the mobile application interface is available in different
Disadvantage: there is a slight performance degradation – about 5%
rendering forms coupled with the additional development time associated
with enabling localization.
Identify the devices offering the capabilities required; for example if
you require scanning, GPS and the ability to take pictures then identify
the device candidates. Different devices run differing Operation
Systems, have different memory etc and this may affect the development
Advantage: Using the device specific SDKs to expose device capabilities
dramatically improves development time.
Disadvantage: You will need version specific builds per target device
It is often possible to intercept incoming text messages and display
alerts to the current user. You can also send text messages from your
Windows Mobile UI to third parties provided the application resides on a
Windows Mobile 6 Professional (WM 5 Pocket PC PE). The same is possible
for email messaging. However anytime you do any background task, albeit
in a multithreaded fashion, the device UI is always “slightly” less
One Build per device type
To reduce support overheads try and maintain one build per device type.
For example, you will have one build for all devices that share the same
capabilities. This will prevent the unmanageable scenario of having
multiple builds for different devices. Deployment to mobile devices is
time consuming and frustrating for non technical end users. Testing and
deploying mobile applications needs to be kept as simple as possible.
A username and password should always required to gain access to a
Windows Mobile application that interfaces with your back end data.
If you do signature capture on the devices you need to encrypt it before
transmitting it to the server. You also need to consider any HIPAA
requirements relating to the capture and transmission of confidential
You may want to capture GPS information periodically according to a
Device Data Volatility
On occasion there are problems with devices; they run out of battery
power, they get damaged in the course of field work and in instances
when the data they have been capturing has not been transmitted to the
back end environment this data can be permanently lost unless it is
Choose your development environment; for Windows Mobile development this
will most likely be Visual Studio 2008 using C# against .NET Compact
Framework 3.5 and SQL Compact Edition 3.5.
User Interface Controls
There are three control suites that we highly recommend for all Windows
- DEVBUZZ Color button and tab button (tot $40)
- DEVBUZZ GPS library – free - but DEVUZZ
retains full copyright
- RESCO Mobile Forms Toolkit (tot $1200)
The RESCO control suite has the AdvancedList, AdvancedTree and Smartgrid
Store and forward - Local persistence of data
In the absence of connectivity the device will store the data and send
it to the back end environment when connectivity is available. The
information is stored and forwarded to the server on a first in first
out basis (FIFO) once connectivity has been reestablished in order to
maintain the chronology of the events. If this is the case we recommend
you contact us about DEVBUZZ Background Technology – this will allow you
to fast-track this type of project.
The only reliable mechanism of implementing store and forward as well as
checking for information updates is to poll the back end server. Push
technology does not work with field devices unless the server can
uniquely identify each device via IP.
Communications between device and server middle tier need to be secure.
You need to know what those security requirements are before you start
the development process since this will affect the device serialization
Field communications utilizing cellular or satellite communications are
by their very nature subject to intermittent disruptions. We can cater
for this by implementing a handshake protocol between the device and the
server. No information is removed from the device unless it receives an
acknowledgement receipt from the back end server [available using
DEVBUZZ Background Technology].
This prevents any data loss from interrupted communications, however
sending data to the server (as well as to the device) requires a little
extra processing and communication complexity to ensure no loss of data.
You need a to implement a clear and concise schema for conflict
resolution. The simpler this is the faster the data sync. In many
instances a rule such as “device wins” is the best since:
- the field user is on the scene and has the
most accurate information
- it is much easier for a desktop user to
re-enter information, after is has been overwritten by a field user
than for the field user to “lose” changes.
- trying to offload too much conflict
resolution to the device incurs a performance penalty impacting
usability as the device attempts to capture new information,
schedule it for transmission, download new information and do
conflict resolution concurrently.
IIS compression can dramatically reduce the bandwidth requirements of
the data payload at the expense of some performance on the device since
the data packets will need to be uncompressed before processing.
If you need to maintain multiple versions of your mobile application for
different clients you need a mechanism to keep track of the currently
provisioned application and functionality that enforces licensing.
Central Deployment Server
Managing the client deployments is an order of magnitude easier to
handle with a central deployment server. You can keep track of all the
devices in use for licensing purposes as well as handle deployment
propagation from one central repository. However you will also have the
overhead of maintaining a high availability system. If you decide not to
use a central deployment server you will need to push updates to all
clients devices each time you release a mobile build (with mobile
applications this tends to occur more frequently than you would expect)
Ideally the mobile application should automatically check for
application updates each time the user logs in and has connectivity. The
user will be prompted with a message box asking whether they want to
update or not.
Device Usage Metrics
Tracking device usage metrics is important for licensing and audit
purposes in many industries.
You can enhance the security of mobile application deployment by asking
for a security token for initial log in and registration. This means
that no one can deploy your application to a device with the install
Hopefully this list has exhausted you ;) If you would like us to develop
a Windows Mobile solution please contact us -
you can find all our contact details here.