Windows mobile 5, 6.0 & 6.5 – a decade on

Windows mobile 5, 6.0 & 6.5 – a decade on

You still sign for your shopping on one. Our clients take Medical Services Audits on one. You still sign for parcels on one. Our clients take Health & Safety Audits on one. Your cab driver uses one (unless he’s on Uber!).

Windows Mobile devices just won’t die.

Which is why we support them – so our clients can carry on processing millions of transactions on them.

Perhaps it is a combination of the investment made and their form factor (rugged, reliable and functional) that means that they are taking ages to disappear.  Which is a good thing because developing for them can be challenging and rewarding.

The technology stack is extremely mature. It comprises of SQL Server Compact and the .NET Compact Framework. There are also some very comprehensive libraries for device specific hardware integration from the main OEMs (e.g. Motorola). Being such a mature technology, it means development and technical support is excellent. Most technical/development issues have well-defined solutions. Somebody, somewhere, will have encountered it all before.

Whilst they are a mature technology stack, they are, compared to today’s mobile devices, absolutely archaic in terms of processor speed and memory. Many devices only have 64MB RAM and a good portion of this is often taken up by things such as background applications and the .NET Compact Framework itself.

Most of the devices also pre-date 3G mobile connectivity (over a decade ago!) and therefore have super-slow data connections when not on Wi-Fi.

Developing for such a platform therefore requires a deep understanding of how cope with limited storage; limited RAM, limited connectivity and a slow CPU. Which is why we find it rewarding.

Even the modest of databases can exceed the in-built storage capacity. Fortunately, though, most devices have a SD card slot for additional storage. As a result, we auto-detect if there’s an SD and then use this by default. This is actually trickier than it might sound though as locating such a card often differs from one OEM to another.

When it comes to memory it is even trickier. Simply put, RAM on a desktop computer or laptop can be thought of in two ways: Actual, physical RAM and Virtual Memory. When you run a large program, or have a number of programs running, you can exceed the physical RAM in your PC.

What Windows (the desktop Operating System) does at this point is use “Virtual Memory”. In effect, it uses some free space on your hard disk as “pretend” memory. Unfortunately, a hard disk is thousands of times slower than actual RAM, so your machine will start performing quite poorly, but it does mean it can continue to function beyond the physical limitations of actual RAM.

Windows Mobile does not have this capability, at all. When the actual RAM, of which there is very little, is used up – the application no longer functions! We have developed various approaches mitigate this limitation.

Like this:

Most applications have multiple “forms” and these often contain “sub-forms”. In a traditional application, these may be held in memory simultaneously. Each of these consumes memory, so a state-machine architecture is often used. Here, we often keep just one “form” in memory at a time, and keep track of the “state” separately.

Often we have to deal with items of data that are too big to hold in memory. For example, downloading an item of data, handling an image etc. To handle this, we effectively replicate the “Virtual Memory” idea that a desktop OS, such as Windows might use. Instead of holding the whole block of data in memory at once, we stream the data in chunks, utilising the SD card as temporary holding space.

When it comes to dealing with slow data connections, we always ensure that data is compressed before uploading/downloading.

Finally, to deal with the slow CPU, we architect SQL Compact databases so that the schema will not need complex queries (e.g. those with lots of joins). We also aim to minimise amount of background processing we need to do.

These lessons have been learned over a number of years, letting us continue to support these seemingly obsolete, yet still pervasive devices.


Leave a reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>