什么是最宝贵的.Net Compact Framework的提示，技巧和疑难杂症，逃避者？ [英] What are the most valuable .Net Compact Framework Tips, Tricks, and Gotcha-Avoiders?

问题描述

我们在.NET Compact Framework中和Windows Mobile的大量工作。我见过很多问题，有关细节，以ASP.Net应用程序或其他基于.Net的桌面应用程序，但没有具体的CF

We work extensively in the .Net Compact Framework and Windows Mobile. I've seen plenty of questions come up regarding specifics to development of ASP.Net apps or other .Net based desktop apps but nothing CF specific.

任何人的移动开发者，有可以分享一些东西开始做，停止做，和避免在Compact Framework的开发时在做什么？

Anyone else a mobile developer out there that can share some things to start doing, stop doing, and avoid doing when developing in the Compact Framework?

推荐答案

肯定的：

• 使用一个物理设备只要有可能（不是模拟器）
• 在与多个设备（不同厂商，不同型号）测试
• 在各地的睡眠/唤醒行为精矿测试
• 当使用MSTEST单元测试，从未使用私有访问
• 避免ActiveSync的像瘟疫 - 直接使用CoreCon调试
• 在获取熟悉RPM，并尽早开始使用它
• 再利用对象时，可能
• 避免做了很多工作，在窗体的构造函数 - 开路它的延迟加载，或在后台线程
• 在加载表格需求时，可能（不是所有的人都在一次）
• 在高速缓存中的常用形式，根据需要创建偶发的人
• 在保持图像分辨率低
• 如果一个类公开处置的使用的。始终。
• 在没有应用程序是太小，无法从MVC / MVP模式中受益
• 不得用于CF微软CAB / SCSF端口（谁移植它的人显然没有实际使用的资源有限的设备）
• 在获取熟悉的概念，偶尔连接，如果你会做任何远程数据/服务活动
• 停靠和锚定是你的朋友和你的敌人 - 试运行时的屏幕旋转和多种分辨率（即使你认为你会不会瞄准他们，因为你可能错在这种思维）
• 在看，但不要投入巨资在设备部署包项目类型。它有可能会咬你很大的局限性。批处理文件的工作原理出奇地好或自定义MSBuild任务调用CabWiz
• 在刷上你的C ++和P / Invoke的技能。您会需要他们。这几乎是不可能写出一个有用的CF应用程序没有P /调用的东西。
• code到最小公分母的目标。
• 部分类是你的朋友，尤其是用于将目标类型（PPC，电话，非移动CE）之间的逻辑。
• 避免运行从持久存储的应用程序，特别是对CE和pre-的WinMo 5.复制到杀死你，特别是在睡眠/觉醒周期RAM，并运行从那里到prevent需求分页。
• 应用程序应该不会在乎睡眠/唤醒的转换，但这是纯理论。休眠唤醒*的将会的改变您的应用程序的行为，如此反复测试，测试，再测试。
• 在我提到的测试？特别是对每一个设备，你可以让你的手？买便宜的硬件从易趣为您的测试实验室。有更多的设备比拥有最新的，除非你打算使用新设备的特定功能更重要。
• 询问神助，如果你打算以编程方式使用蓝牙。获取熟悉的Widcomm和微软堆栈和了解，他们是不一样的。
• 在观看有关内存管理的MSDN网络广播在紧凑型框架。再看你错过了第一时间的东西。
• 当心休眠/唤醒无效的内部处理和引发访问冲突。这是比较深奥，但确实会发生。例如，如果你正在运行的应用程序关闭存储卡上，整个程序不加载到RAM中。在用件的需求分页的执行。这是一切都很好。现在，如果你设备电源关闭时，司机全部关闭。当你再次启动的，许多设备只需重新安装存储设备。当你的应用程序需要要求页的更多的程序，它不再是地方是，它死了。类似的行为可以通过安装在商店的数据库发生。如果你有一个打开的句柄到数据库，睡眠/觉醒周期后，连接句柄可能不再有效。
• 安装<一href="http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=7e286847-6e06-4a0c-8cac-ca7d4c09cb56">evaluation版本平台生成器的的。该人士$ ​​C $下一大堆的东西在那里（如网络用户界面，很多司机等），当你的P / Invoke code是没有做什么，你希望你至少有一个地方去寻找为什么。

• Use a physical device whenever possible (not the emulator)
• Test with multiple devices (different vendors, different models)
• Concentrate testing around sleep/wakeup behaviors
• When using MSTEST unit tests, never use private accessors
• Avoid ActiveSync like the plague - debug using CoreCon direct
• Get familiar with RPM and start using it early
• Reuse objects when possible
• Avoid doing a lot of work in a Form's ctor - off load it for lazy load or in a background thread
• Load Forms on demand when possible (not all of them at once)
• Cache the frequently used Forms, create infrequent ones on demand
• Keep image resolutions low
• If a class exposes Dispose use it. Always.
• No app is too small to benefit from MVC/MVP patterns
• Don't use the Microsoft CAB/SCSF port for the CF (the people who ported it obviously never actually used a resource-limited device)
• Get familiar with the concept of "occasionally connected" if you will be doing any remote data/service activity
• Docking and Anchoring are your friend and your enemy - test run-time screen rotations and multiple resolutions (even if you think you won't target them, because you're probably wrong in that thinking)
• Look at, but don't heavily invest in the device deployment package project type. It has major limitations that will likely bite you. A batch file works surprisingly well or a custom MSBUILD task to call CabWiz
• Brush up on your C++ and P/Invoke skills. You will need them. It's almost impossible to write a useful CF app without P/Invoking something.
• Code to the lowest common denominator for targets.
• Partial classes are your friend, especially for dividing logic between target types (PPC, Phone, non-mobile CE).
• Avoid running an app from persistent storage, especially for CE and pre-WInMo 5. Copy to RAM and run from there to prevent demand-paging from killing you, especially after a sleep/wake cycle.
• Apps should not care about sleep/wake transitions, but that's pure theory. Sleep wake *will change your app behavior, so again test, test, test.
• Did I mention test? Especially on every device you can get your hands on? Buy cheap hardware off of eBay for your test lab. Having more devices is more important than having the latest unless you intend to use a specific feature of a newer device.
• Ask for divine intervention if you plan to use bluetooth programmatically. Get familiar with the Widcomm and Microsoft stacks and understand that they aren't the same.
• Watch the MSDN webcast on memory management in the Compact Framework. Watch it again for the stuff you missed the first time.
• Watch out for sleep/wake invalidating internal handles and causing access violations. This is more esoteric but certainly happens. For example, if you're running an application off of a storage card, the entire app isn't loaded into RAM. Pieces in use are demand-paged in for execution. This is all well and good. Now if you power the device off, the drivers all shut down. When you power back up, many devices simply re-mount the storage devices. When your app needs to demand-page in more program, it's no longer where it was and it dies. Similar behavior can happen with databases on mounted stores. If you have an open handle to the database, after a sleep/wake cycle the connection handle may no longer be valid.
• Install the evaluation version of Platform Builder. The source code for a whole lot of things is in there (like the network UI, many drivers, etc) and when your P/Invoke code isn't doing what you expect you'll at least have a place to go look for the "why".

添加10年5月25日

• 不要期望的WinMo下的电源管理API工作consistenly或正常的（甚至全部）跨设备。事实上，即使使用相同的硬件可能从OS改变编译到OS构建。

• Don't expect the power management APIs under WinMo to work consistenly or properly (or even at all) across devices. In fact even with the same hardware it might change from OS build to OS build.

添加10年7月27日

• 如果你是一个唯美的UI后，会ppared做大量的定制或手工绘图的$ P $。
• 如果你正在做的自定义或手工绘图，你需要使用的透明度，做好准备的<一个负载href="http://blog.opennetcf.com/ctacke/2009/10/26/ProjectResistanceTransparencyInTheCompactFrameworkSucks.aspx">frustrations并有写<一个href="http://blog.opennetcf.com/ctacke/2010/07/21/GettingAPixelsTransparencyInTheCompactFramework.aspx">wacky code 或致电本土code 直接的变通 <一href="http://blog.opennetcf.com/ctacke/2009/10/28/ProjectResistanceDay4GraphicFixesAndMoreGesturing.aspx">shortcomings在CF。

• If you're after a aesthetic UI, be prepared to do a lot of custom or manual drawing.
• If you're doing custom or manual drawing and you need to use transparency, get ready for a load of frustrations and having to write wacky code or call native code directly to work around shortcomings in the CF.

添加11年11月22日

• 请不要以为只是因为一个命名空间或类的BCL存在，它实际上是任何有用的方式来实现。 <一href="http://blog.opennetcf.com/ctacke/2011/11/22/X509CertificatesCompactFrameworkWTF.aspx">Certificates肯定不是的。

我只是添加到列表中，因为它们发生，我...

I'm simply adding to the list as they occur to me...

这篇关于什么是最宝贵的.Net Compact Framework的提示，技巧和疑难杂症，逃避者？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！