创建易更新的AIR应用程序的技巧
出自9RIA.com WIKI
创建易更新的AIR应用程序的技巧
(英文原文：Tips for building AIR applications that can be easily updated)
原作者：David Deraedt 翻译者：Helen Huang 更新于：2009年3月29日
我很快便喜欢上Adobe AIR的一个原因是用它来创建一个桌面应用程序是多么简单，特别是像我这样的，有web背景的开发者 -- 你创建一个AIR工程，像web那样写好你的代码，然后创建一个版本，你就能做到了。
然而，随着时间的流逝，我认识到创建AIR应用程序是非常复杂的。桌面应用不同于基于浏览器的应用。最明显地，他们的部署设计都是非常重要的。
幸运地是，Adobe AIR运行环境和它的SDK已经提供工具以便于开发者工作，包括通过更新API或者更新框架来升级你的应用程序的能力。
不同于web应用程序，你不能只仅仅发布一个新版本而不考虑到它在用户系统上的重要性。每个版本创建依赖性，在软件的整个生命周期中你必须考虑的残留文件。如果你不注意这个结果，你可能很快就会遇到问题。巨大的力量产生于巨大的责任，我觉得这是真的。
这篇文章的目的是，当创建并进行一个Adobe AIR应用更新时，去识别你可能遇到的潜在的陷阱，并且学习一些技巧来怎么避免他们。
注意：我假设你已经有了一些关于创建与更新AIR应用程序的基本知识。如果你想知道怎么使用更新框架，请参阅HTML/Ajax,Flash,Flex快速入门或者Mihai Corlan的文章Using the Adobe AIR update framework。
目录 |
更新计划
当你开始创建一个AIR应用时，你不必决定将来是否需要更新。更新的能力来自于AIR应用程序盒子。然而，假设它在某个时刻不得不更新，并在公开发布前准备好这些，这是开发者的责任。
为什么这个问题真的重要，其中一个主要的原因就是安全性。你必须能够为你的应用程序提供一些安全补丁。因为如果你不小心，AIR应用程序会破环用户系统文件，这是非常严重的。没有人愿意背负安全漏洞的责任。
除了安全的问题，你可以很容易想象到很多问题，比如安全补丁、bug、文字错误、丢失知识产权信息等，这可能要求你提供一些非常快的更新。相反，你永远不会知道你的工作如何被接受。也许被认为是一个简单的示例却能够成为一个巨大的成功？
结果是，这个真实问题的答案是否，“我可以让更新成为可能吗？”但“我怎么控制更新的进程？”你不要期待你的用户每天检查你看的网站来查看新版本，一般来说，提供一些自动更新的功能是一个很好的主意。尽管你可以使用AIR SDK更新API来做到，最容易的方式是使用新的更新框架。
然而，你仍然必须做一些决定，比如什么时候检测新版本，或者更新是否是强制的。更重要的是，你必须意识到，在你的应用程序生命周期中，每个版本都只是其中一个步骤。因为，尽可能的越少打扰越好。
应用程序ID的重要性
你可能知道，AIR应用程序是通过运行环境和操作系统国通一个应用程序ID来确认的，这个应用程序ID是一个字符串，它在你的应用程序描述XML文件中提供。这个ID有多个目的：
. 你将应用程序的与所谓的应用存储目录联系在一起
. 它常常用于将应用程序与加密的本地存储联系在一起
. 它在更新过程运行中使用来决定替换什么应用程序
这些就是为什么当你发布一个版本后不能改变应用程序的ID的原因了，除非你想将它当成一个完全新的应用程序。注意，在极少案例中，这可能就是你真实希望达到的，为了让用户独立的安装并使用这些版本。
然而在大多数案例中，你必须在第一次公开发布前选择你应用程序的ID，并且不能再更改它。使用DNS名称相反的如"com.mycompany.myapplication"的方式来计划，在AIR早前的版本中这被认为是一个很好的练习。然而，当应用ID现在与发布ID整合在一起来确认应用程序之后，已经不再需要那样了。
你不用担心在你的软件公开发布后更改商业名称的问题(例如，从法律角度，或因为市场原因)；应用ID不是与名称相关的，当运行时哪个应用将出现在系统中，或者在安装过程中 -- 你应用程序的用户将永远不会看到这个ID。
注意，应用ID不是用来确认应用程序的唯一标准。因为安全原因，两个拥有相同ID但是带有不同签名的应用程序会被视为不同的应用程序，除非一个除非一个正确的迁移程序已经放在那里了。
处理文件依赖性
记住AIR应用程序经常在用户系统上使用甚至创建的文件和目录，这是非常重要的。这些文件可以包括：
1、用户偏好文件；
2、SQLite数据库；
3、应用具体文件类型；
这当然是AIR的主要特征。但是你需要关注到，这些文件可以创建依赖关系。你的应用程序可能依赖某些文件来运行或者执行某些任务。
关注到这点，保留一个描述浙西文件的列表来记住它在用户系统的路径，角色，源目录，还有它创建了哪种依赖性，这是一个很好的主意。这在你决定在下一个版本中是否重写这些文件时也非常必要。例如，每个版本都重写用户偏好文件是不推荐的。
在可能的时候，将版本信息存入到你的文件中。这对于你将来的更新是非常有用的。
应用程序通常也会假设这些文件会丢失。如果某些文件是应用程序必不可少的，那么就需要提供一种机制来(重新)创建他们，或者至少明显地出现适当的错误信息。记住，你没有权利在安装过程中选择将嵌入文件放到用户系统中的哪里。所有嵌入在.air包中的文件将会放在应用目录。将他们拷贝到最终目录也是应用程序的责任(当推荐应用存储目录作为大部分文件的存储目录时，你可以选择将他们创建者别的地方)。
此外，这些文件随着时间的推移可能会改变。例如，用户可以通过使用其他的软件来直接地编辑它。因此，你同样需要假设这些文件可能会变得畸形，并且要提供一个机制来修复或者重新创建它们。
做一个总结，你的程序可以需要计划一下文件依赖启动顺序。当文件丢失可以创建，或者当文件过时可以重写。在这个阶段需要删除过时的文件，但是文件删除是一个最终的处理措施，需要谨慎对待。
有时候，你不得不提供一个更复杂的，特设的机制进行文件迁移。例如，如果你的数据库结构改变了，你需要将所有之前数据库结构中存在的数据转换到一个新的数据库中。
这这个阶段，你需要检测应用程序是否是第一次运行在系统中，或者安装的最新版本是哪一个。Encrypted Local Store是一个存储这些信息的理想地方，因为你会知道在各版本中它是一致的。然而，你需要确认没有使用EncruptedLocalStore.setItem()方法的stronglyBound参数设为true来存储，因为在那种情况下，数据会在程序更新后才被读取。
开发版本 vs 发布版本
当创建一个AIR应用程序时，有一件事要记住的是，一个AIR发布版本被认为是与运行在ADL中的开发版本不同的应用程序。这样有两个非常重要的结果：
1、应用程序存储目录不同。在开发版本中，这个目录是在应用程序ID之后命名的。但是发布版本中的目录命名方案有些轻微的不同：他的名字是由一个应用程序ID后面跟随一个随机数。
2、加密本地存储也完全不同。
记住，应用程序存储目录与加密本地存储这两者都在更新后一样保留，这是个明显的例外项目通过强约束参数存储。
除此以外，加密本地存储始终不能为空，除非因为他的显示关联应用这样做。即使你完全卸载应用程序，加密本地存储仍然保留。这也是预料之中的，因为它使开发人员具备存储信息的能力等，“这个计算机是否已经安装了这个应用程序？什么时候？什么版本？”这样可能帮助你管理你的证书模型。
因为你不能重置加密本地存储，你需要在你的应用程序中创建一个内置机制来清除所有加密本地存储的入口。记住这个问题很严重。最好的行动是在你的代码中保证加密本地存储始终为空，或者不提供你预期的数据。
另外一个开发版与发布版的关键不同点是后者实际上会打包进一个AIR文件。开发版是有ADL执行的，在bin-debug目录中的内容(如果你使用Flex Builder，否则是你的默认输出目录)，但是最终应用程序会在应用程序目录中被执行。
作为一个开发者，你的职责是，当创建发布版本时决定.air包的内容。
应用程序打包与签名
不管你是直接通过命令行还是一个IDE比如Flex Builder来使用ADT，打包与签名可以在一个步骤中完成，也可以先打包应用程序以后再签名。
当然，当执行时不要忘记嵌入你应用程序需要的文件。ADT打包仅需要两个文件：应用程序的SWF或者HTML文件，还有描述的XML文件。它不能检测到你程序所依赖的其他文件的丢失。再次强调，作为一个开发者，你的职责是确保所有的文件都包含在最终的包中。
同样，不要忘记某些文件也可以在你的发布版本中才确定，典型的例子是各种各样应用程序和文件的图标。
注意：如果你使用Flex Builder来打包你的应用程序，你可以需要使用导出发布版本想到来做一些事件。乍一想，你可能认为发布版.air包的内容就是从bin-release目录创建的。这只是部分正确，因为发布版本导出向导给你能力来选择bin-release目录中什么文件和目录会被添加为一部分。
已知的当前Flex Builder版本的限制是，向导面板不允许你浏览外部文件或目录。你需要将外部文件拷贝粘贴到源文件目录或者bin目录以便嵌入它们。
同样，记住有些在项目源目录的文件不能在向导面板中找到，因此不能选择他们嵌入到air包中。Actionscript文件和MXML文件就是有这种状况。你需要手动的将文档包含到bin-release目录中。
在这些情况下，如果你不使用自动发布系统，你需要按照如下步骤发布你的应用程序：
1、编译你的应用程序，并在bin-release目录已经创建时停止；
2、将那些不会自动从你的src目录中自动包含的任何你想到打包到你的.air包中的文件或目录放置到这个目录中；
3、再次编译，使用向导嵌入你刚刚拷贝的文件。
代码签名在打包过程中是一个非常重要的步骤。尤其是两个主题要非常认真的考虑到。
第一个，你需要记住，因为安全原因，认证是通过时间戳的，在某个点会消亡。如果你的认真已经销毁，你将不能再次使用它来标识新的包。然后，以前标识的包仍然有效。
第二个，如果你曾经从一个认证迁移到另外一个认证(例如，你在开发期间借了一个证书)，不要忘记使用迁移程序。这将让你的用户准确无误的从你自己标识的应用程序来升级到你最新的、值得信任的版本。
注意：关于AIR应用程序签名的更多信息，请阅读Oliver Goldman的文章Code signing in Adobe AIR和Todd Prekaski的Digitally signing Adobe AIR applications。
测试新版本
现在可以测试你的应用程序是否达到预期了。这一步通常被认为是功能测试。为此，主要的困难在于确保测试环境符合必须的要求。你需要假设工作在你的开发系统中的什么不需要工作在用户系统中。
理想情况下，这些步骤都需要在Mac OS X,Linux,还有Windows下都执行。不要忘记，尽管AIR是跨平台运行环境，一个特征仍然具有操作系统特殊行为(详情请参阅Charles Ward的文章Developing cross-platform Adobe AIR applications。同样的，如果你的应用程序是本地的，那么也需要在不同语言环境中进行测试。记住，AIR运行环境对话框，例如安装对话框，可以通过应用描述文件实现本地化。
两类主要要考虑的观众是已经存在的用户，他们将从先前版本进行升级，还有新的用户，他们将第一次安装应用程序。
假设在你的测试环境中，你安装过这个应用程序先前发布的版本，你可能需要首先从.air包直接地升级应用程序，因为你在线安装标记在这个阶段还不能更新到。这确保(手动)更新正常工作。
没有简单的方法来测试自动更新，因为更新XML文件和.air包在网络上是由所有用户共享的。你可以在某个地方放一个调试更新文件，但是这可能要求创建一个特殊的"调试发布版本"来载入调试更新文件。(当然，你可以在测试的时候改变在线文件，之后再改回来。然而，那样是相当不专业的。)
下一步，你需要确认你的软件为那些第一次安装这个应用的用户进行了正确地安装。为此，最好是使用一个专门的系统图片。但是如果你采用了测试更新机制相同的测试环境来测试，那么：
1、卸载当前的应用程序。我通常使用我的安装标记中AIR运行应用程序的安装对话来进行卸载。
2、删除应用程序存储目录还有其他你应用程序创建的文件。这也是为什么你需要保持的应用文件依赖独立的另外一个原因。
3、安装新版本。
如果在这个阶段中你遇到任何冲突或问题是你在开发版本中没有遇到的，很有可能是你没有适当地管理好你的文件依赖性。
发布应用程序
仓促的抑制并上载你的应用程序是很难避免的。但是现在你需要测试这个应用程序，你需要确保你的新版本的环境是最新的。
首先，为新版本准备好你网站编辑内容，但是先不要发布。想好特性列表，描述，储备知识，已知问题等等。
典型的过程可能如下：
1、发布你新的.air包到服务器，可能重写之前的版本。
2、修改你更新XML文件来匹配最新版本序号和发布摘要。
3、检查你的安装包是最新的以及功能是符合预期的。将你的页面或者网站设为维护模式以便于让你快速测试它。
4、发布你的应用程序网站编辑的内容。
注意：更多关于安装标识的信息，请参考
你可能希望通知你现在和将来的用户关于新版本的信息，通过blog日志，一个鸣叫，还有其他任何你能想到的方式。
不要低估发布时间。它很有压力，而且它是你应用程序发展必不可少的也是最单调的部分之一。我推荐看一看简单的自动发布系统，像ANT就能帮你实现。最低，写下这些发布步骤，做一个检查列表。
发布协议
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License
关于作者
David Deraedit是Flash平台的一位顾问，精通Adobe Flex和Adobe AIR。他也作为一个授权培训中心Regart.net的培训指导老师，也是很多O'Reilly很多书籍如<the AIR for Flex Developers and AIR fro JavaScript Developers pocket guiders>的法语翻译者。作为Adobe社区的一位活跃发布者，David已经为开发者发布了多个AIR应用，如Lita，一个SQLite数据库管理员工具。祝你访问他的blog愉快，也可以在twitter上follow他。