Application Architecture Guide 2.0 - CH 19 - Mobile Applications(6)

简介:

本文翻译第19章的最后部分,包括"Technology Considerations"中的".NET Compact Framework"、"Windows Mobile"、"Windows Embedded"和"Additional Resources"部分。

 

.NET Compact Framework

Consider the following guidelines if you are using the Microsoft .NET Compact Framework:

 If you are familiar with the Microsoft .NET Framework and are developing for both the desktop and mobile platforms concurrently, consider that the .NET Compact Framework is a subset of the .NET Framework class library. It also contains some classes exclusively designed for Windows Mobile. The .NET Compact Framework supports only Microsoft Visual Basic® and Microsoft Visual C#® development.

 If you are attempting to port code that uses Microsoft Foundation Classes (MFC), consider that it is not trivial due to MFC’s dependency on Object Linking and Embedding (OLE). The Windows Compact Edition supports COM, but not OLE. Check to see if the OLE libraries are available for separate download to your device before trying to use MFC on a mobile device.

• If you have issues a subset of Windows Mobile code with the Visual Studio debugger, consider that you might require multiple debug sessions. For example, if you have both native and managed code in the same debug session, Visual Studio might not follow the session across the boundary. In this case, you will require two instances of Visual Studio running and will have to track the context between them manually.

.NET Compact Framework

如果你在使用Microsoft .NET Compact Framework,那么就考虑如下指导方针:

如果你很熟悉Microsoft .NET Framework,并且同时在开发桌面应用和移动应用,那么将Microsoft .NET Compact Framework看成.NET Framework类库的一个子集。他还包括一些特别为Windows Mobile设计的类。.NET Compact Framework只支持Microsoft Visual Basic®Microsoft Visual C#®语言来开发。

•由于MFCOLE的依赖,如果你尝试移植MFC代码, 那么这就不是小事一桩。Windows CE支持COM,但不支持OLE。那么,在移动设备上使用MFC之前,确认OLE库是否可以单独下载到你的设备上。

•如果你想使用Visual Studio调试器来追踪代码,考虑可能需要多个调试会话。例如,如果你在一个调试会话中拥有本地代码和托管代码,Visual Studio可能不跟随会话。在这种情况下,你就需要运行两个Visual Studioinstance来手动追踪他们之间的内容。

 

Windows Mobile

Consider the following general guidelines for Windows Mobile applications:

• If you are targeting an application for both Windows Mobile Professional and Windows Mobile Standard editions, consider that the Windows Mobile security model varies on the different versions of Windows Mobile. Windows Mobile Standard (Smartphone) supports three levels: blocked, normal, and privileged mode. Windows Mobile Professional (Pocket PC) supports only blocked and privileged mode. Code that works on one platform might not work on the other because of the differing security models for APIs. Check the Windows Mobile documentation for your device and version.

Windows Mobile应用程序考虑如下通用指导方针:

•如果你要设计同时运行于Windows Mobile ProfessionalWindows Mobile Standard之上的应用程序,那么就要考虑不同Windows Mobile版本上的不同的安全模型。Windows Mobile Standard (Smartphone)支持三个级别:受限,正常和特权模式。Windows Mobile Professional (Pocket PC)只支持受限模式和特权模式。在一个平台上可以工作的代码可能在另一个平台上就不能工作了,因为安全模式的API不同。检查你Windows Mobile设备的文档和版本。

 

• If you will have to manage your application in the future or are upgrading an existing application, be sure that you understand the Windows Mobile operating system derivation, product naming, and versioning tree. There are slight differences between each version that could potentially impact your application.

• Windows Mobile is derived from releases of the Windows CE operating system.

 Both Windows Mobile version 5.x and 6.x are based on Windows CE version 5.x.

 Windows Mobile Pocket PC was renamed Windows Mobile Professional starting with Windows Mobile 6.0

 Windows Mobile Smartphone was renamed Windows Mobile Standard starting with Windows Mobile 6.0.

 Windows Mobile Professional and Windows Mobile Standard have slight differences in their APIs. For example, the Windows Mobile Standard (Smartphone) lacks a Button class in its Compact Framework implementation because softkeys are used for data entry instead.

•如果你要在以后管理你的应用程序,或者升级现在的应用程序,那么确认你认识了Windows Mobile操作系统的来历,产品名字,和版本树。各个版本之间可能会有轻微的差别,影响你的应用程序。

         Windows MobileWindows CE操作系统的发布衍生而来。

         Windows Mobile 5.x6.x都是基于Windows CE 5.x的版本上的。

         Windows Mobile 6.0以后,Windows Mobile Pocket PC被命名为Windows Mobile Professional

         Windows Mobile 6.0以后,Windows Mobile Smartphone被命名为Windows Mobile Standard

         Windows Mobile ProfessionalWindows Mobile StandardAPI上有所不同。例如,Windows Mobile Standard (Smartphone)Compact Framework类库中缺少Button类,因为他使用软键盘处理数据输入。

 

• Always use the Windows Mobile APIs to access memory and file structures. Do not access them directly after you have obtained a handle to either structure. Windows CE version 6.x (and thus the next release of Windows Mobile) uses a virtualized memory model and a different process execution model than previous versions. This means that structures such as file handles and pointers may no longer be actual physical pointers to memory. Windows Mobile programs that relied on this implementation detail in versions 6.x and before will fail when moved to the next version of Windows Mobile.

 The Mobile Device Manager is mentioned in this article as a possible solution for authorizing, tracking, and collecting logs from mobile devices, assuming that you have an Active Directory infrastructure. MDM also requires a number of other products to fully function, including:

• Windows Mobile 6.1 on devices

• Windows Software Update Service (WSUS) 3.0

• Windows Mobile Device Management Server

• Enrollment Server

• Gateway Server

• Active Directory as part of Windows Server

• SQL Server 2005 or above

• Microsoft Certificate Authority

• Internet Information Server (IIS) 6.0

• .NET Framework 2.0 or above

•使用Windows Mobile API来获取内存和文件结构。不要在你得到任何一个句柄之后就直接获取他们。Windows CE 6.x版本(也就是下一个Windows Mobile的发布)使用虚拟内存模型,与之前的版本有不同的处理模型。这就意味着诸如文件句柄和指针之类的结构体并不指向真实的物理地址。基于这种的Windows Mobile程序在下一个Windows Mobile版本中失效。

•假设你拥有Active Directory Mobile Device Manager在本文中是作为授权、跟踪和收集日志的解决方案而提及的。MDM也需要一些其他产品来实现功能,包括:

 Windows Mobile 6.1 的设备

 Windows Software Update Service (WSUS) 3.0

 Windows Mobile Device Management Server

 Enrollment Server

 Gateway Server

 Active Directory as part of Windows Server

 SQL Server 2005 以上版本

 Microsoft Certificate Authority

 Internet Information Server (IIS) 6.0

 .NET Framework 2.0 or或以上版本

 

Windows Embedded

Consider the following guidelines if you are choosing a Windows Embedded technology:

• If you are designing for a set-top box or other larger-footprint device, consider using Windows Embedded Standard.

 If you are designing for a point-of-service (POS) device such as an automated teller machine (ATMs, customer-facing kiosks, or self-checkout systems), consider using Windows Embedded for Point of Service.

 If you are designing for a GPS-enabled device or a device with navigation capabilities, consider using Microsoft Windows Embedded NavReady™. Note that Windows Embedded NavReady 2009 is built on Windows Mobile 5.0, while Windows Mobile version 6.1 is used in the latest versions for Windows Mobile Standard and Professional. If you are targeting a common codebase for NavReady and other Windows Mobile devices, be sure to verify that you are using APIs available on both platforms.

Windows Embedded

如果你选择了Windows Embedded技术,那么就考虑以下指导方针:

•如果你要设计一个机顶盒或者其他大设备,考虑使用Windows Embedded Standard

•如果你要设计一个POS机,例如ATM机,考虑使用Windows Embedded for Point of Service

•如果你要设计一个GPS设备或者具有导航功能的设备,考虑使用Microsoft Windows Embedded NavReady™。注意,Windows Embedded NavReady 2009是基于Windows Mobile 5.0的,而在最新的Windows Mobile Standard and Professional 中,使用的是Windows Mobile 6.1。如果你编写一个通用的代码库,在NavReadyWindows Mobile设备上都能使用,那么必须确保你使用了两种平台都可以调用的API

 

Additional Resources

 For more information on the Windows Embedded technology options, see the Windows Embedded Developer Center at http://msdn.microsoft.com/en-us/embedded/default.aspx.

 For the patterns & practices Mobile Client Software Factory,

see http://msdn.microsoft.com/en-us/library/aa480471.aspx

 For information on the Microsoft Sync Framework,

see http://msdn.microsoft.com/enus/sync/default.aspx

 For more information on the OpenNETCF.Diagnostics. EventLog in the Smart Device Framework see http://msdn.microsoft.com/en-us/library/aa446519.aspx

 For more information on ASP.NET Mobile, see http://www.asp.net/mobile/road-map/

 For more information on adding ASP.NET Mobile source code support into Visual Studio 2008,

See http://blogs.msdn.com/webdevtools/archive/2007/09/17/tip-trick-asp-netmobile-%20development-with-visual-studio-2008.aspx

额外资源

•更多Windows Embedded技术信息,请看Windows Embedded Developer Center

•模式和实践移动客户端软件工厂,请看Mobile Client Software Factory

Microsoft Sync Framework信息,请看http://msdn.microsoft.com/enus/sync/default.aspx

OpenNETCF.Diagnostics. EventLog信息,请看Instrumentation for .NET Compact Framework Applications

•更多ASP.NET Mobile信息,请参考Roadmap for ASP.NET Mobile Development

•更多Visual Studio 2008支持的ASP.NET Mobile源代码,参考:

http://blogs.msdn.com/webdevtools/archive/2007/09/17/tip-trick-asp-netmobile-%20development-with-visual-studio-2008.aspx




本文转自施炯博客园博客,原文链接:http://www.cnblogs.com/dearsj001/archive/2009/01/19/1378533.html,如需转载请自行联系原作者

相关文章
|
6月前
|
存储 关系型数据库 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型,比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本(如region_id代替"Greater Seattle Area"),可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中,需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂,若无Join,需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性,层次模型以树形结构限制了多对多关系处理。为克服层次模型局限,发展出了关系模型和网状模型。
60 6
|
6月前
|
XML NoSQL 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 概念 + 数据模型
【6月更文挑战第5天】本文探讨了数据模型的分析,关注点包括数据元素、关系及不同类型的模型(关系、文档、图)与Schema模式。查询语言的考量涉及与数据模型的关联及声明式与命令式编程。数据模型从应用开发者到硬件工程师的各抽象层次中起着简化复杂性的关键作用,理想模型应具备简洁直观和可组合性。
42 2
|
6月前
|
SQL 人工智能 关系型数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性
【6月更文挑战第8天】网状模型是层次模型的扩展,允许节点有多重父节点,但导航复杂,需要预知数据库结构。关系模型将数据组织为元组和关系,强调声明式查询,解耦查询语句与执行路径,简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据,提供弱模式灵活性,但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系,适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read,写入时不校验,读取时解析,牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
50 0
|
6月前
|
SQL JSON NoSQL
【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型
【6月更文挑战第6天】关系模型是主流数据库模型,以二维表形式展示数据,支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战,如网状和层次模型,但关系模型仍占主导。然而,随着大数据增长和NoSQL的出现(如MongoDB、Redis),强调伸缩性、专业化查询和表达力,关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题,ORM框架缓解但未完全解决。文档模型(如JSON)提供更自然的嵌套结构,适合表示复杂关系,具备模式灵活性和更好的数据局部性。
54 0
|
6月前
|
敏捷开发 存储 缓存
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可维护性
【6月更文挑战第4天】本文探讨了Twitter面临的一次发推文引发的巨大写入压力问题,指出用户粉丝数分布是决定系统扩展性的关键因素。为解决此问题,Twitter采用混合策略,大部分用户推文扇出至粉丝主页时间线,而少数名人推文则单独处理。性能指标包括吞吐量、响应时间和延迟,其中高百分位响应时间对用户体验至关重要。应对负载的方法分为纵向和横向扩展,以及自动和手动调整。文章强调了可维护性的重要性,包括可操作性、简单性和可演化性,以减轻维护负担和适应变化。此外,良好设计应减少复杂性,提供预测性行为,并支持未来改动。
62 0
|
6月前
|
缓存 关系型数据库 数据库
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可扩展性
【6月更文挑战第3天】可扩展性关乎系统应对负载增长的能力,但在产品初期过度设计可能导致失败。理解基本概念以应对可能的负载增长是必要的。衡量负载的关键指标包括日活、请求频率、数据库读写比例等。推特的扩展性挑战在于"扇出",即用户关注网络的广度。两种策略包括拉取(按需查询数据库)和推送(预计算feed流)。推送方法在推特案例中更为有效,因为它减少了高流量时的实时计算压力。
59 0