利用Flex 4.5 SDK和Flash Builder 4.5开发的web和移动参考应用（一）

要求 

预备知识

 
本文以FlashBuilder 4、FlexSDK 4和Spark 组件集的基础知识为基础。如果读者了解经典MCV（模型-视图-控制器）设计模式或MVP（模型-视图-提供器）设计模式，一定会对学习本文有很大帮助。

 
用户水平

中级

需要下列产品

Flash Builder （下载试用版）

范例文件

Shopping Cart

Sales Dashboard

Expense Tracker

 
需要其他产品

Android 2.2+ 或Android 3.0+设备

仅在发布Flash Builder 4 和Flex 4 SDK 后一年，我们就推出了新版本软件Flash Builder 4.5和Flex 4.5 SDK。这两种软件可以构建面向Google Android、Blackberry Tablet OS和Apple iOS 操作系统的移动应用。另外，Flex 4.5 SDK软件引入了新的Spark组件，并在大型应用开发方面做了改进；而Flash Builder 4.5软件引入几十个新的编码效率特征，能够更快捷地开发ActionScript 和MXML。如果您想了解关于Flex 4.5 SDK的更多最新信息以及该软件在其他哪些方面做了改进，请阅读Deepa Subramaniam撰写的文章。如果您想了解关于Flash Builder 4.5的更多最新信息（包括面向开发人员的新特征及关于Flash Catalyst CS 5.5的新工作流程），请阅读Andrew Shorten撰写的文章。如果您想了解关于Flex 4.5 SDK和Flash Builder 4.5新型移动能力的具体信息，请阅读Narciso Jaramillo的概述一文。

本文涉及如何构建面向传统web和移动部署的应用，介绍了使用Flex 4.5 SDK和Flash Builder 4.5开发的三个参考应用。每种应用都可以以传统web应用的形式在浏览器上运行，也可以在移动设备上运行。这三种应用包括Shopping Cart、Expense Tracker和Sales Dashboard。本文介绍了在开发移动设备和web上的Flex应用时要考虑的具体问题。另外，还介绍了如何建立应用架构，使得web项目和移动项目之间能够共享代码。最后，讨论了在构建各种尺寸外型的应用时所要考虑的性能方面的因素。

建立新的Flex 移动项目

尽管Flash Builder 4能够支持所有项目类型，Flash Builder 4.5还是引入了其他Flex项目类型，包括Flex移动项目和ActionScript 移动项目。这些移动项目都与移动应用的开发相协调。Flex移动项目了解可在移动设备上使用的 “安全”移动Flex组件。另外，Flash Builder 4.5可帮助用户创建新的移动项目，无论是Flex移动项目还是ActionScript移动项目。如果您想创建新的Flex移动项目，请按下列步骤执行：文件>新建>Flex移动项目。Flash Builder 能够创建、配置新的移动项目，包括项目名称及要创建移动应用的类型。Shopping Cart、Expense Tracker和Sales Dashboard等移动应用均使用的是基于视图的应用类型。这表明，应用程序的每个视图均受其视图类的控制，而所有视图又都受ViewNavigatorApplication的控制。

Flash Builder 4.5能够创建基于视图应用的stub视图。用户可以为自己的应用程序添加其他视图。每个Stub视图都来自spark.components.View类。通过视图，可以了解如何显示数据以及如何将信息插入到活动栏中。活动栏是位于每个应用程序顶端的导航UI。这就为现有视图提供上下文信息，包括现有视图的标题以及为用户提供具体应用地点导航的动作按钮。

Shopping Cart移动项目在com.adobe.mobileshoppingcart.view包中组织所有子视图。用户可以在Shopping Cart移动应用中看到为后继视图创建UI的MXML类。例如，一旦用户选择购买某一条目，或ItemDetailsView 作为个别项目的详细视图，CartView.mxml则成为checkout视图（参见图1）。

图1：个别项目的详细视图受ItemDetailsView.mxml类的控制。通过视图，我们可以知道如何将上下文信息插入到活动栏导航条的顶端。在这种情形下，现有视图的标题显示在活动栏中。

实现多屏幕代码复用最大化的架构

Flash Builder 4.5为用户提供了开发面向各种项目目标应用的工作流，包括利用Adobe Flash Player进行配置的web或利用Adobe AIR进行配置的桌面设备或移动设备。我团队决定，在创建Shopping Cart、Expense Tracker和Sales Dashboard应用时，采用一种应用架构。这种应用架构在帮助开发团队组织代码、区别UI代码及服务层代码时表现得很出色。另外，这种架构可帮助我们共享web项目代码和移动项目代码（注：我们没必要采用应用程序架构来共享web项目代码和移动项目代码，但作为分布式开发团队，我们觉得应用程序架构对我们很有帮助）。

我们所选择的架构仅仅是基于经典模型-视图-提供器（MVP）架构。MVP采用被动视图，利用正式控制器在各视图之间传递状态信息和UI信息。通过将所有逻辑代码置于视图文件之外，我们能够在多个项目中重新使用核心应用代码。

FXP vs FXPL

在多个项目（就我开发团队而言，是指web项目和移动项目）之间共享的核心应用程序代码是指包含在Flex Library 项目（FXPL）中的所有代码。例如，MobileShoppingCart.fxp、ShoppingCartTablet.fxp和ShoppingCartWeb.fxp都链接在ShoppingCartLib.fxpl中。ShoppingCartLib.fxpl包含web版本和移动版本的所有相关共享代码，包括服务层和有用类。类似地，DashboardMobile.fxp和DashboardWeb.fxp均链接在DashboardLib.fxpl和DashboardChartLib.fxpl中。这些FXPL包含Sales Dashboard web和移动应用中用于处理图表组件和数据管理的共享代码。最后，CRUDMobile.fxp和CRUDWeb.fxp链接到共享library项目CRUDLib.fxpl。

在Flex Library项目的使用中，一般的经验法则是数据模型、控制器、服务、事件和有用类都包含在内。Flex 移动项目的作用是像MobileShoppingCart.fxp那样添加移动专用的UI代码，像ShoppingCartWeb.fxp那样添加浏览器（或桌面）专用UI代码。这种做法能够确保封装良好以及不同格式参数普通代码的复用。

提供器

提供器是应用架构的重点。应用程序的每种功能状态均含有一个提供器类。提供器实例插入视图文件中，或者利用Swiz等框架进行元数据插入（引自Singleton模型），或者穿过提供器进入构造器中。在上述项目实例中，主要类的提供器实例引自Singleton模型，而条目提渲染器的提供器是在控制器类中实时创建的。例如，MobileShoppingCart.fxp中的ItemDetailsView.mxml指的是第36行的提供器变量，来自于提供器对象，此应用的业务逻辑是视图引用的。类似的，每个web应用及移动应用中的List组件均显示提供器对象列表。MobileShoppingCart.fxp的MainView.mxml中的 List控件显示用户正在查看的条目列表。这些数据项是视图显示的提供器对象。

提供器中含有视图显示的所有属性。提供器借助各种事件与视图进行通信。这就是每个提供器类扩展EventDispatcher的原因。查看ShoppingCartLib.fxpl项目中包含的ItemPresenter类（com.adobe.shoppingcart.presenter）。注意ItemPresenter是如何扩展EventDispatcher的，以及发生任何变动时，是如何调度事件的。借助这种方式，提供器暴露通过视图可以访问的公共API方法，从而合理地显示UI。

提供器存储IeventDispatcher对象实例，在本例中指的是用于调度事件的控制器实例。这是提供器联络应用程序业务逻辑部分的方式。提供器不存储控制器实例，或对链路进行功能调用。为实现封装，提供器仅调度事件。事件是提供器和控制器之间的协议。

控制器

控制器控制不同应用程序之间的通信，决定应用程序的状态。在应用程序启动时，创建一个控制器实例。在实例项目中，查看WebShoppingCart.mxml和MobileShoppingCart.mxml。这是web版本及移动版本Shopping Cart应用程序创建的位置。控制器创建提供器对象实例，并将其存储在模型中。另外，控制器还设置模型中的所有属性。

控制器还对提供器中的事件进行监听。当提供器释放事件时，比如改变当前屏幕，控制器就负责处理事件。然后，控制器做出逻辑决定，确定应该如何处理提供器的请求。控制器可访问服务层，直接设置提供器的属性。

有时，需要将保存在多个同步提供器中的属性存储在模型中，但是在大多数情况下，每个提供器仅存储自己的状态和属性信息。用户一定能够按照MVP的指示，将模型的状态和广播状态变更存储到提供器中，但是按照我们的经验，这仅仅是增加了一个具有复杂度的层，而没有获得太多收益。

有时，我们会发现由于项目目标不同，对控制器的要求也有所不同。在这种情况下，我们对控制器进行扩展，覆盖需要自定义执行的方法。扩展后的控制器是特定项目类型重要初始化期间我们所列举的类。

视图

通常，两个项目之间不共享视图代码。另外，Flex 移动项目包含移动UI，而Flex 项目包含非移动UI。对于应用程序运行的外型尺寸，要对用户接口进行微调。

为应用程序需要支持的屏幕目标创建新的Flex或ActionScript项目。类似的屏幕目标，如移动phones和tablets，可使用同一项目，这取决于用户的使用需求，尽管Flex支持面向smart phones vs tablets的UI创建。

视图UI代码（MXML文件、CSS样式表、图像及字体等资源）应在各个项目中创建。尽管大多数视图代码的创建是根据项目特定的外形尺寸创建的，用户却可以共享核心应用程序代码。用户在项目中创建的新视图能够借助提供器与其他应用程序进行通信。由于视图中不含逻辑代码，所以用户对在项目之间复制视图代码的需求很小。用户只需将属性绑定在提供器上，对提供器进行方法调用，就可以回应客户的要求。

模型

模型用于存储提供器实例。提供器实例引自控制器及视图。模型存储提供器实例，这样，控制器和视图就可以使用同一个实例。

视图不能引用模型属性。相反，视图也只了解提供器（状态枚举或某些声明）。直接来自视图的模型对象参考破坏了封装类型。简言之，视图应该了解的唯一协议是提供器中的内容。

如果用户正在使用Swiz等框架，就可以将提供器插入视图中，而不再将其存储在模型中。Swiz框架能够为用户创建、管理提供器实例。

服务层

强烈建议用户使用界面定义的服务代理，这样就可以在不变更任何应用程序代码的情况下轻易实现不同服务执行方式的转换。如果用户在应用程序开发的初始阶段开发仿制品或尚未完成的服务，尤其有效。

对于我们所使用的架构，控制器存储着服务对象实例。控制器访问服务对象，监听响应。我们利用AsyncToken作为服务协议监听结果，在这种情况下，故障是很容易被发现的。

应用程序UI的设计与执行

用户可与设计人员一起工作，提议外观、感觉及使用UI的交互类型，无论是面向web、移动还是桌面。用户与设计人员共同合作来设计各个视图，尤其是移动项目视图。设计人员集中思考用户如何与应用程序运行的移动设备进行交互、不同设备的屏幕尺寸及每英寸的密度、用户在使用移动设备时习惯的导航范例。利用这些信息以及Flex提供的便利条件，我们就能够确定在视觉上赏心悦目、易于采用Flex执行的设计。

与设计人员共同工作

拥有好的用户体验的设计人员及可视化设计人员可以使应用程序从好做到惊人的好。设计人员和开发人员之间良好的沟通需要样式和功能的平衡，最终使得应用程序不仅易于使用而且外观很好、性能较高。按照我们的经验，许多组织常采用可视化设计来混淆用户体验设计。很多时候，常常忽略拥有客户体验的设计人员的作用，将任务分派到可视化设计人员或开发人员手中。拥有用户体验的设计人员花时间分析如何与应用程序进行互动，包括数据及应用状态的显示及导航等。按照我们的经验，如果项目中有专注于用户体验的专职设计人员或专业人士，就能开发出性能更佳的软件。

在我们的项目中，web项目中含有许多由可视化设计人员在Adobe Illustrator CS5或Adobe Fireworks CS5中创建的线框。依据可视化设计人员提供的线框，通过使用Flash Catalyst CS 5.5或开发人员手工制作的Spark皮肤，即可将线框转换为功能性Flex代码。另外，Flash Builder线框主题运行良好，可对单一UI进行扩展，从而应用在早期阶段中。如果您想了解更多关于如何使用Flash Builder 4.5和Flash Catalyst CS 5.5来开发项目表皮及资源的内容，请查看Jacob Surber的文章。

皮肤

Flex 4引入的皮肤架构使得自定义视图变得容易起来，无论是面向移动项目还是web项目。如果您想了解新的皮肤架构Spark，请查看概述一文。

Flex 4.5 SDK以面向所有移动组件及功能的Spark为基础。Flex SDK 4.5移动项目使用的所有优化组件均包含特殊移动皮肤。出于性能考虑，这些皮肤在ActionScript中创建。这些移动皮肤质量较轻，不含默认Flex 4皮肤等外露式皮肤。对于大多数移动项目，我们在ActionScript3中创建了新的皮肤，但在某些位置我们可以使用MXML皮肤。一般经验法则是Flex移动项目中基于MXML的皮肤比较好，尤其是在保守使用的情况下。如果用户发现任何性能问题，请切换至ActionScript皮肤，以实现更高性能。对于大多数Shopping Cart、Expense Tracker和Dashboard 移动项目而言，在创建移动组件的新皮肤时，我们对与默认MXML皮肤相对应的默认移动ActionScript皮肤进行了扩展。

很多时候，在皮肤文件中书写可编程绘图代码是将可视化设计解释为Flex的最佳途径。刚开始您似乎感觉这种方法很乏味，但是很快就会变成第二性质。这也就意味着用户可以获得更佳的性能！大多数情况下，在皮肤文件中使用手绘的代码比嵌入式资源的皮肤要漂亮。即便用户不想使用纯粹的ActionScript，但可以使用FXG。一般来讲，我们建议将FXG用在Flex移动项目中。请注意Shopping Cart移动项目中的大多数皮肤是如何利用FXG创建的。在应用程序的生命周期内，用这种方式创建的皮肤比较小、也比较容易维护。

对于利用FXG不易重新创建的方案，用户需要使用外部资源。虽然Flex支持多种类型资源的加载和嵌入，但某些格式倾向于比其他格式的工作性能要好。对于静态向量资源，FXG是最佳选择。对于静态位图，JPG格式的文件最小，也最容易使用。如可能，应将具有透明度的位图重新创建为矢量图。这个建议很好，能够提高性能。总体而言，就是要鼓励可视化设计人员少用位图。