Mistakes are not always a bad thing. Making mistakes is a natural way to learn.
However, the cost of such ‘learning’ in the development cycle can be pretty high. This
is especially true for mobile applications, where a programmer battles against so many issues that
desktop developers can’t even
remember any more.
There are a number of things that are most harmful for mobile developers
to do. I present several of the most common troubles worth reviewing in
this article. I start with strategic issues.
Different Platforms are Different
The very first and probably most important fact mobile developers must remember is that Windows
CE operating system is by far not like its big brother the desktop operating system. They have common
features and share common philosophy, but there is a big difference in development approaches used
for each. This is due to different form factors, resources that are available, supported APIs and
so forth. Regardless of whether you use C++, Visual Basic, Java or C#, you will be lucky if the same
code will run on both the desktop and on a PDA in the same way. Thus if you’re considering the
porting of your existing desktop application to WinCE or considering the development of new
applications, remember that the mobile operating system is not the same as a desktop operating
Operating Systems, Devices and Frameworks
In addition to knowing that mobile operating systems are different from desktop operating systems,
you should also note that there are different mobile operating systems as well as different devices
and frameworks. You need to properly plan for the device types and operating system
you would like to target.
For example, if you have developed an applications for devices using Windows Mobile, then your
application might not run good on PDAs with CE.NET inside. This lack of support could cut your target
devices in half. Similarly, if your product uses specific features of a specific device, then there
may be devices that can’t support your application as well. For this reason, you should
ask yourself if targeting specific device features is a right decision. Of course, if you are
device vendor, such problems are out of scope! For application developer, however, generic
code you produce as better for the whole project, i.e. you application will be
able to run almost everywhere.
Another issue from the same family is the use of various frameworks, libraries and technologies.
For example, the Pocket PC SDK contains MFC library but the Smartphone SDK does not. As such, if you
want to target both Pocket PC Devices and Smartphone devices, then you need to think twice. Another
example can be seen with ADO CE. In addition to many differences with desktop version, Microsoft has
decided to discontinue its support in Windows Mobile 5.x. So be double careful there!
That is enough regarding issues with strategy, now consider the structure of a mobile application.
There are at least two polar approaches: to make an application solid — do you always have the one
and only executable or do you divide your application into a main executable and number of DLLs?
Both structures have well-known pros and cons. I’ve seen many projects
(very complicated and fat enough to be honest), which used COM objects and huge
number of DLLs. I have to state here that such approach doesn’t work well on
Windows Mobile platform. One executable and few DLLs are ideal though. This is
obviously true for desktop systems as well, but there you are in much
more comfortable situation with resources. In case of Windows CE application performance
will be reduced dramatically.
Another issue with DLLs on Windows CE is that if you store resources, (e.g. to support multiple
your application), it may cause significant problems because the application may switch
resource handles at runtime. The resulting behavior may be quite unpredictable.
Eugene Tilman and I have spent a number of sleepless nights trying to detect why
a big application sporadically crashes on a device but works like a
charm in desktop emulation. There are different methods for avoiding the need for
many DLLs. For example, when implementing internationalization, you might ‘translate’ resources
within the executable rather than keep them in a separate DLL. There are a number of references
on the web describing similar techniques.
How you configured your application is also important
for avoiding mistakes. Again, there are many different ways to configure a
mobile application, so we will not dig into specific mistakes. Rather, there are
two possible configurations issues you should consider: Registry use and code reusability.
There are big desktop systems which use the Registry in
much the same way as a database in that it is used to store hundreds
(if not thousands) of parameters. For Windows Mobile application such tricks just
won’t work due for a very simple reason: mobile devices suffer from
hard resets from time to time. If a hard reset occurs, you have a
good chance that all data in the registry will be reset as well and thus lost.
Regardless, maintenance of such configuration storage can be a real nightmare, although
it can be done by purchasing additional tools such as Pocket
If your application needs a lot of parameters then consider suitable method to store
them — a method such as XML, binary files or something else.
One of the best things in development is
code reusability. That’s why we all create libraries, frameworks and so forth. This helps us
to develop faster, better, … (you can continue as much as you want to).
You have to be careful using such libraries. For example, the MFC framework can cause you
problems when used incorrectly on mobile devices. No doubts, it helps a lot where you can utilize
it; however, there many classes that are implemented for mobile usage with much less efficiency than
in desktop version. This includes classes like CSocket and the WinInet
stuff. Additionally, some functionality available through the
API are unavailable for mobile usage. But this is not the worst trouble. Such problematic
parts of the library are obviously subject to improve. Programmers simply do
not use ineffective classes. Hence, Microsoft has decided to discontinue some
of them in newest MFC version for Windows CE. For example, the WinInet classes are
being discontinued. If you’ve the bad luck to have used them in your projects, then
you will have to rewrite them. In rarer cases, some GUI classes may be dropped,
but I believe it should be treated as an accident rather than common case.
I/O, Memory, Stack & Co.
Finally, there are programming issues that can be the cause of mistakes in mobile
I/O operations are the very first point to talk about from a performance and device
resources point of view. For desktop systems the normal receipt is simple: read
by blocks rather than by bytes. For mobile applications it is not as straightforward.
If data is stored on a flash card (SD, CF etc.), then access time may
be painfully long. Suppose that data is kept in a flat files with no matter binary or
text (like XML). It is a good thing if you can read it all in one shot to memory
and then process as needed. In the case of huge amounts of data, however, this is simply impossible.
In those cases, you have to allocate chunks here and there. It is a really
bad thing that memory allocation strategies may vary from one version of an OS to next
one. You can easily test on a Pocket PC 2002, 2003 and Windows Mobile 2003 SE.
On Pocket PC 2002 you benefit from big allocations, but on later versions smaller
chunks are allocated faster. With Windows CE 5.0 the situation changed once again,
because there is no RAM anymore. Storage Cards are still there, but as you see,
it might be a particular magic to choose the best method to reach the best I/O
Not all PDAs are loaded with resources or have lots of resources available. This fact
hits you first of all with the stack size that is available for applications.
Many mobile applications uses Dialog-based architecture because it is simple.
It is well-known that big allocations on the stack, e.g. BYTE arr, are inapplicable
because you have by
default only a 64KB for stack. Less intuitive effects can occurs when you have
a number of dialogs created on the stack and open simultaneously. It appears that critical number is
on the boundary of 3 to 4 dialogs only. If your program tries to
pop up more, a Stack Overflow exception will be the best thing you can get. Usually
it just crashes at some arbitrary place.
The last but not the least thing regarding programming mistakes is in exception handling.
Earlier versions of Windows CE did not support exception handling extensively. Now the situation is
Normal C/C++ handling is allowed, TRY and CATCH macros may be forgotten. Exception handling
is extremely important for mobile applications, because an environment
is less friendly than the desktop. Applying exception handling in the correct way
will make your product much more robust, but don’t be too excited with it, otherwise
you can loose the performance.
You’ve now seen many of the biggest
mistakes! I hope reviewing them will help you to avoid
them and thus lead to better decisions in your own mobile applications. With mobile
technology growing so rapidly, doing mobile development is getting better with every new operating
system release. So who knows, maybe soon mobile programming will become as regular as
About the Author
Alex Gusev started to play with mainframes in the end of the 1980s, using
Pascal and REXX, but soon switched to C/C++ and Java on different platforms.
When mobile PDAs seriously rose their heads in the IT market, Alex did it too.
Now, he works at an international retail software company as a team leader of
the Mobile R department, making programmers’ lives in the mobile jungles
a little bit simpler.