作者：Alex Gusev

错误并不总是不祥之事。犯错是自然的学习方法。但是，这种“学习”在开发循环中可能要付出极高的“学费”。这点在手机应用开发方面尤为突出，应用程序员需要对付许多电脑软件开发者早已忘却的问题。

许多错误会给手机开发者带来严重的伤害。在这篇文章中，我将列举某些最为普遍的问题。

mistakes(from mbaintheusa.com)

平台差异

手机开发者必须记住的一件最重要的事情是，Windows CE操作系统与桌面操作系统并不相同。它们有某些共有的功能，但是两个系统所对应的开发方法存在很大的差异。这些差异来源于不同形式的要素、可用资源、API支持等。无论你使用的是C++、Visual Basic、Java还是C#，如果相同的代码可以在PC和PDA（游戏邦注：即个人掌上电脑）上以相同的方式运行，那么你就算是相当幸运的。因而，如果你考虑将现有的桌面应用移植到WinCE上或者考虑开发新的应用，应当记住手机操作系统和电脑操作系统并不相同。

操作系统、设备和框架

除了知晓手机操作系统不同于电脑操作系统之外，你还应当注意到，目前存在不同的手机操作系统以及不同的设备和架构。你需要针对目标设备类型和操作系统制定合适的计划。

比如，如果你以使用Windows Mobile的设备为目标开发出某个应用，那么该应用可能就无法在使用CE.NET的PDA上良好地运行。这种支持缺陷可能会让你所考虑的目标设备减少一半。同样，如果你的产品使用了某款设备中的某个特别功能，那么也可能存在无法支持该应用的设备。这时候你应该考虑，以特定的设备为目标是否是正确决策。当然，如果你是设备产商，自然无需考虑这个问题！但是，对于应用开发者来说，你最好让整个项目的类代码可在几乎所有的设备和平台上运行。

各种框架、程序库和技术的使用也是个问题。比如，Pocket PC SDK包含MFC库，但是Smartphone SDK却没有。基于这种情况，如果你想要兼顾两种设备，就需要有两套方案。所以，在做决定时要格外谨慎！

应用结构

以上是战略的相关问题，现在我们开始讨论手机应用的结构。目前有两种截然不同的方法：为保持应用稳定，是选择只制作一个可执行文件还是选择将应用分割成一个主要可执行文件和数个DLL呢？

两种结构都各有利弊。我见过许多使用COM对象和大量DLL的项目，这些项目都非常复杂。我必须声明的是，这种方法在Windows Mobile平台上的运行表现并不好。因而，单个可执行文件和少数几个DLL是理想的选择。对桌面系统而言，这种方法显然也是很棒的，但是桌面系统提供了更完善的资源。对Windows CE而言，应用表现会显著弱化。

Windows CE上的DLL中还存在的问题是，如果你存储资源（游戏邦注：比如设置应用支持多种语言），可能导致很严重的问题，因为应用可能在运行期间转变资源处理方式。这使得应用的表现极具不可预测性。现在有许多方法可以避免在应用中使用大量DLL。比如，在将应用投放国际市场时，你可以在可执行文件中“翻译”资源，而不是将它们设置成独立的DLL。网络上有许多描述类似技术的方法可供参考。

应用配置

你如何配置应用对避免开发失误来说也很重要。手机应用的配置同样也有许多不同的方法，因而我们没必要深入探讨某些具体的错误。但是，有两个可能产生的配置问题应当考虑，那就是注册表的使用和代码的再用性。

大型桌面系统使用注册表的方法就像是用数据库来存储数百个参数。对于Windows Mobile应用来说，这种方法无效，原因很简单：手机设备时常需要更新固件。一旦进行固件更新，很可能注册表中的所有数据也被重置，从而丢失。不管怎样，维持此类配置存储简直是个噩梦，因而可以通过购买Pocket Controller等额外的工具来实现目标。

如果你的应用需要大量的参数，那么就要考虑用合适的方法来存储，比如XML和二进制文件等方法。

代码的重复使用无疑是开发中最棒的事情。这也是我们创建程序库和框架等内容的原因，这可以帮助我们更好更快地开发应用。

你必须谨慎地使用此类程序库。比如，如果在手机设备上使用不当的话，MFC框架可能产生许多问题。毫无疑问，如果你能够利用它的话自然可以带来很大的帮助，但是，某些类运用到手机上时，其效能要远远小于桌面版本。CSocket和WinInet等正属于这个范畴。而且，某些可通过API实现的功能性在手机上无法实现。程序员不可使用那些无效的类。微软已经决定在Windows CE的最新版MFC中终止某些类。比如，WinInet类就会被终止。如果你不幸在项目中使用了这些类，那么你就需要从新编写（游戏邦注：此处内容以2006年为叙述背景）。GUI类崩溃是出现相对较少的情况，但是我认为应当将此视为意外而不是普遍问题。

I/O、内存和堆栈

最后，我们要探讨的是可能导致手机应用出现错误的编程问题。

首先，从表现和设备资源的角度来谈论I/O操作。对于桌面系统来说，正常的接受是以模块为单位来读取而不是字节。对于手机应用来说，情况并没有如此简单。如果数据存储在闪存卡（游戏邦注：如SD和CF等）中，那么访问时间就会非常长。假设数据存储在展平文件中，不使用二进制或文本文件（游戏邦注：比如XML）。如果你能够瞬间读取内存然后按照需要加工处理，那么确实很不错。但是，在需要处理大量数据的情况下，这几乎是不可能的。在这种情况下，你必须配给分布在各处的组块。各版本操作系统的内存配给战略可能存在差异，这是件很麻烦的事情。你可以在Pocket PC 2002版、2003版和Windows Mobile 2003 SE上进行测试。在Pocket PC 2002上，你可以享受到大组块配给，但是在随后的版本中，较小组块的配给更快。在Windows CE 5.0中，情况再次发生改变，因而不再有RAM。存储卡依然存在，但是正如你所看到的那样，需要重新选择最佳的方法来实现最好的I/O表现。

并非所有的PDA都搭载着资源或者有大量可用的资源。这会直接影响到应用可用的栈大小。许多手机应用使用基于对话的结构，因为它很简单。为众人所知的是，对栈进行大型配给是不可行的，因为你默认的栈大小只有64KB。当你在栈上创建多个对话且同时打开时，能够呈现的直观效果较少。显然，边界上平衡的关键对话数量只有3到4个。如果你的程序尝试使用更多，栈溢出已经是最好的结果了。通常情况下，这会导致应用某些部分崩溃。

最后要阐述的编程错误是异常情况处理中的问题。Windows CE的早期版本并没有广泛支持异常情况处理。现在，情况大有不同，该系统已支持一般的C/C++处理。异常情况处理对手机应用来说特别重要，因为手机平台的运行环境友好度不如桌面系统。正确地运用异常情况处理会使你的产品更加健全，但是不要滥用这种功能，否则会影响到应用表现。

游戏邦注：原文发表于2006年2月28日，所涉事件及数据以当时为准。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Big Mistakes To Avoid in Windows Mobile Development

Alex Gusev

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 application 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: Smackall Games)