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 system.
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!
Application Structure
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 languages in 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.
Application Configuration
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 Controller .
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 applications.
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 performance.
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[65536], 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 balancing 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 quite different. 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.
In Conclusion...
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 desktop development.
Source : http://www.developer.com