CaltrainTimes从设计到发布(基于Flex的手机应用)
资源下载地址
- Caltrain Times 的 iTunes下载地址
- Caltrain Times的Android Market 下载地址
- Caltrain Times的BlackBerry App World 下载地址
- Caltrain Times的Amazon App Store 下载地址
- 源文件地址
是否有可能开发一款能在不同设备上运行的应用，而这些设备的屏幕分别率，实际物理尺寸大小各异？ 说具体点，“能不能创建一款视觉完美的应用，能够运行于安卓、iOS和黑莓平板iOS的智能手机或平板电脑环境?”， 简而言之，就是我想开发一款高质量能多界面运行的手机应用。
这就是 Caltrain Times应用 诞生的原因。Caltrain Times是什么？ Caltrain Times应用是为加州人每天上下班乘坐的Caltrain 铁路系统（沿经旧金山南湾镇至圣荷西和吉尔罗伊）开发的一个班次时间查阅工具。
本文将讲述我如何开发这款漂亮Caltrain Times手机应用的整个过程。 其中将涉及到整个开发环节，从最初设计一直到最后发布在各个App Stores(手机软件销售平台)。 这篇文章仅作为我自己经验的总结， 绝没有暗示我的做法就是什么灵丹妙药并强迫你们接受的意思。根据你项目的实际情况，你可能（如我下面列出的）在不同的（如流程、测试、开发和优化）环节有更多的选择。尽管这会因不同项目而异， 但如果你刚刚涉足手机应用开发，下面的方法会对你的开发起到很好的引导作用。
由于我是一个开发者，我深知自己在缺乏设计好看图形元素方面的欠缺，于是求助于一个设计公司来出一些Caltrain Times应用的设计。在得到一些关键人物的反馈后，结合我认为这个应该大体是啥样子，如何交互以及功能等给他们提供了一些设计草图。 后来的结果是设计公司提供给我他们对Caltrain Times所作设计的PhotoShop psd文档。这个文件的尺寸是根据iPhone/iPod的非视网膜屏幕的尺寸，即(320x480)。我知道这是我的失误，一开始没有向他们说明我需要的是高分辨率的设计。记住，你需要的永远应该是高分辨率的设计，这样你可以把它缩小而不失真，否则，如果你拿到的就很小，放大后清晰度就很难保证。
注意：你要在设计最初把分辨率调成960x640或者对于较大的平板电脑调成1024x600方能满足视网膜显示标准。同时我觉得在设计最初以智能手机尺寸比例开始是一个不错的主意。这样它很容易扩大到平板电脑尺寸而不用收缩原来的设计。
在准备第二次前往设计公司之前，我其实自己在Photoshop上做了尝试。我在Photoshop打开那个文件， 点击菜单Image > Image Size，调整分辨率为原来的2倍(从72到144)， Photoshop很好的把位图和文字大小放大了，但是对于效果来说，就不是让人非常满意，比如笔触， 这样我不得不打开一些元素，手工调整其中的一些笔触尺寸，不知道为什么。 但这样做就省了我要专门再次去设计公司一程，因为现在总体来说它就是我想要的结果。
下一步就是把设计图分解成不同的部分，并得到在设计中使用的一系列字体和其属性。坦白地讲，我对Fireworks的熟练程度远比Photoshop好得多。基于这个想法，接下来的工作就是把不断地把Photoshop图层隐藏、打开并点击“保存成Web和设备格式”，把全部的组件保存成PNG-24 图形格式，这样我就能得到清晰度无损并保持透明度的图片可以在Fireworks里供切割使用了。在Fireworks中，我对那些需要导出的资源先做一个备份，然后在保持清晰度的前提下把它们导出为文件最小的格式(png8 vs png32 vs jpg)， 导出的图形被保存到3个不同的文件夹里。比如， 我在Fireworks中打开GPSSource.jpg，先导出到文件夹/assets/dpi320， 然后改变尺寸为原来的75%，然后导出到/assets/dpi240，再在原图的基础上改变尺寸为原来的50%，然后导出到/assets /dp160（图2）。
当随时需要对资源作调整或创建新的资源时，我都重复上面的流程把他们按不同的分辨率保存于三个不同的文件夹，同时务必保留高清晰度原格式。 这让我将不同DPI(每英寸上的点数)版本的资源置入代码中，而不是反复于Firework和IDE很多次。现在我就能在不同的设备界面下做测试以确保它在不同的DPI下显示没有瑕疵。接下来就是我的下一个环节：测试！
通过Flash Builder 4.5.1创建的手机项目能让你的应用面对不同的平台发布， 你可以针对每个平台做不同的启动配置。启动配置定义了你的应用在运行和Debug模式下如何在桌面和设备上启动。它同时让你可以为桌面上运行提供手机模板。你可以针对各种手机屏幕分辨率和DPI对这些设备模板做修改。 在我项目的最初， 我分别做了3个启动配置，让桌面作为160,240,和320 DPI的设备模板来运行（如图3）。
我用最少的代码生成基本的应用布局，比如背景图，标题栏，车站选择部分，火车时间列表和运行于不同桌面配置下针对这3个DPI尺寸的切换效果等。 在这个阶段应用还没有和任何真实的数据源相连，但我使用了一些种子数据来测试列表。 接下来使用了另外的启动配置，分别测试了它在安卓和iOS的启动。 如果我不是测试运行效率，我将使用最快的打包方法 ( adt –target ipa-test-interpreter ) 作为面向Apple iOS平台的设备选项（参看图4）。
在考虑item renderer状态等小细节和不同布局调整可能会对性能造成影响之前，我想我应该先把重点处理UI交互。这意味着我要用MXML和 binding等先设计出我期望中的效果，尽管这可能有悖于手机开发的一贯做法。一旦界面在桌面和手机上运行没问题，并且效率让我满意，我接下来就考虑用户体验问题。最后，当所有的UI交互完成并且各元素在能够在不同的DPI尺寸下正确渲染是， 我就开始下一个环节：开发。
这个环节里，所有的数据，服务，GPS功能，twitter整合和最后的帮助界面都将被整合起来。我写了一个专门的Air程序把 Caltrain通用变更规格转换为Sqlite数据库。每一个应用都有一个默认的Sqlite数据库，这些数据库可以通过线路(或者日后软件更新时)得以更新。更新其实就是拷贝一份数据库替换原来旧的数据库而已。大部分功能都可以在桌面做测试，这样debug和修改起来也很方便。但我也经常把那些功能搬到不同的设备上进行测试，以确保它们的完整性和运行正确。
对于GPS功能我不得不在手机上测试，但其实可以通过连接其他手机上的Air来模拟GPS。我使用一个基本的半正矢公式来计算与车站之间的距离，这个方法很不错因为幸好所有的这些车站都相距不远。在接入真实地手机GPS数据之前，我通过设置经纬度的方法对距离算法做了隔离测试，以确保它准确无误。
我在Flex中使用了一些技巧以解决不同屏幕DPI，智能手机和平板电脑尺寸的问题等。针对不同的智能手机和平板的不同情况，包括飞溅窗体和运行时DPI Provider，我准备了一个自定义类去覆盖部分值。对于图形资源，我大量使用了MultiDPIBitmapSource（图5）。
结合CSS media查询、在构造器中设值或者在Application组件的creationComplete事件，我最终选择使用3组值来满足不同的布局和尺寸(图六)。
感觉我好像对这个工程写了3遍，事实上没有那么糟糕。当我一开始准备3套资源，并调整尺寸是，我感觉很奇怪。如果你已经尝试过针对各种设备和所有的屏幕大小或分辨率进行编码时，你就会同意针对此只做3种变化已经好很多了。我发现如果你把Flex里面为你准备的3种DPI值看作是3套不同的设备或者3中不同的皮肤尺寸，你就很容易理解并知道针对那种手机选择那种尺寸的皮肤了。这种只参照Flex的DPI管理的做法让我可以不去管手机实际的DPI，而只是通过 customer runtime DPI provider类就能决定我要的皮肤了。比如说平板电脑属于160 DPI范围，但是使用customer runtime DPI provider我覆盖了这个值把它变成240DPI，这样就让它在平板上运行时有稍微大一点的显示，这样正是我所期望的。所有这些，看起来好像是额外的做了3套应用的资源和布局，我从中得到了什么？我得到的是我能针对不同的手机类型，全面控制让应用产生我想要的结果。
现在我已经把数据和业务逻辑全部整合到应用里了，接下来该是我在不同的设备上操作这款应用，优化性能以及最后的交互微调的关键时刻了。
在这个环节，我开始研究Flex手机游戏开发的最佳做法，第一个需要优化的地方是把我的基于MXML的item renderers换成基于ActionScript的，这个过程没有想象中的难，只是刚开始不习惯而已。你需要告诉自己，我甘愿自己处理所有资源的创建，处理和渲染等。在原来的MXML里边有很多的binding和布局等需要你在ActionScript里面的某个地方明确出来。比如我在它的容器里定义一个宽度为90%的图片， 在MXML里面很简单，如：<s:Image id="img" horizontalCenter="0" widht="90%" />但是在纯ActionScript里边，我必须专门设置x和width值，如：
overrideprotectedfunction layoutContents(unscaledWidth:Number, unscaledHeight:Number):void { super.layoutContents(unscaledWidth, unscaledHeight); img.width = unscaledWidth * 0.9; img.x = (unscaledWidth-img.width)/2; }其实你在MXML里边做的任何事情，都可以在AtionScript中完成。技巧是你要找出MXML为你做了真么，然后弄清楚在你的 ActionScript类的什么地方，如何把它们表达出来。我不断重复MXML组件的转换工作， 直到应用在各个设备上的运行效率都能让我满足为止。现在应用无论从外观上，操作上以及效率上都表现不错， 该是我把它发布到各个手机应用市场的时候了。
Flash Builder可以帮助你轻松实现应用的发布和打包。在项目里，我点击Export > Release Build，然后在弹出的窗体上有你要发布平台的选项。我按照这些对话框一步一步走过，创建了发布证书，配置文件，权限以及针对平台的打包设置。然后点击 “完成“，最后它会生成.apk, .bar和 .ipa后缀的发布文件。
注意：如果你准备发布到Amazon App Store，你需要把Deployment > AIR download URL改变成Amazon指定的地址。
有趣的环节是为各种应用市场的发布准备图标，截图，应用描述等。我把应用提交到Android Market, 亚马逊Appstore, 苹果App Store, 黑莓App World和Nook Marketplace。这些市场要求的缩略图和图标大小均不一样， 结果是我准备了13个缩略图， 8个飞溅窗体界面以及14个图标。为了得到平台特定的飞溅界面，我在设备上运行了应用，然后使用手机上的截图功能把屏幕截出， 然后把它们拷贝在我的电脑上。如果这些图不能用， 我就用Fleash Builder去创建截图。怎么做的呢？ 我创建了基于手机市场要求的指标的新的启动配置（图3），然后用桌面软件截取应用缩略图。
我在这些平台上一个个的创建了开发人员/供应商帐户（有些是我事先做了的）并且提交了应用。然后接下来我就等待得到这些平台的审核。最后在不到一周的时间里，各个平台审核逐一通过，没有半点麻烦，太好了。你可以在各个平台上查找这个应用，你也可以在顶部的例子链接中下载该应用的源代码。
