安装和集成



这一时刻终于到来了！经历了设计、编码、重新设计、调试、测试、调整与修订程序，您已经为您的Mac OS X应用程序工作好几个月了。现在，通过最后的编译，您的应用程序应该会以预想的方式出现：一个优雅、稳如磐石的工程壮举，它充满了力量与潜力。
但是且慢。您确信它没问题了吗？它真的适合部署吗？它已达到商用标准了吗？客户可方便地安装并使用它吗？有无您尚未注意到的事情呢？
本章试图帮助您回答这些问题。首先，本章将提供一张在部署您的应用程序前应该完成的重要任务清单（或至少设想完成的）。一些任务属于fit-and-finish范围，而另一些则对一个设计良好的应用程序来说是重要的。其次，本章将讨论如何使您的应用程序能与Mac OS X的各个部分以及其它应用程序最好地集成在一起的问题。最后，本章将叙述在安装应用程序时您能采取的各种方法以及能使用的工具。通过努力工作，您已经开发了一个了不起的应用程序，它具有您的客户们所重视的特性。现在，请花一点时间提供重要的安装和设置技巧，以确保他们会喜欢您的应用程序。
准备用于Mac OS X的软件



对软件开发者来说，Mac OS X是一个非常方便易用的系统。除了与传统相同的（或接近的）方法外，它经常为您提供可选择的方法以完成相同的任务。具有这种可选择的方面包括应用程序打包、资源处理以及文档定型。然而，一个方法经常比另一个更好，有时您可将这些方法组合起来。下节将叙述应用程序设计的各种重要方面，为了获得性能、互用性及强壮性，不仅需要讨论您能做什么，更重要的是讨论您应该做什么。
应用程序及文档FAQ 
由于各种不同的因素影响应用程序和文档的性质、结构以及处理，故在本书的各个部分都有关于应用程序和文档的信息。这些因素包括束、可执行文件格式、文件系统以及Finder。本节通过为开发者概括文档和应用程序的重要部分，以回答问题的形式将这些信息汇集在一起。 
应当为应用程序指定什么样的元数据？ 
为了让用户启动您的（束化了的）应用程序，Finder应用程序应当能够检测出文件夹是一个束，然后它应当能够查明该束是一个应用程序。为了进行这样的判断，Finder首先检查以下两件事情中的一件：
在束文件夹上，束位是否被设置成“开（on）” 
束的扩展名是否是那些为束保留的扩展名中的一种（包括.app） 
若Finder断定该文件夹是一个束，它将读取存储于束的Info.plist文件中的CFBundlePackageType键码；若此键码包含“APPL”的值，则可确定该束是一个应用程序。若该文件未包含此键码，则它将根据束扩展名（应用程序为.app）决定束类型。
就象HFS和HFS 元数据的其它形式一样，由于束位在包括多文件系统的联网环境中很容易被丢失，所以应用程序束保持.app的扩展名是重要的。当您创建一个应用程序时，Project Builder将自动地添加此扩展名，但是其它IDE可能并不如此。任何情况下您都不应该删除该扩展名或是鼓励您的用户这样做。若.app的 “不雅观” 使您感到烦恼，请别担心，Mac OS X Finder会隐藏.app扩展名的显示。尽管Apple不在其应用程序上设置束位，但当您创建应用程序时您可在它的束文件夹上设定此属性。关于更多的此类信息，请参阅“Finder和束”以及“应用程序和文档的处理”。
必须将CFM可执行文件打包在一个束中吗？
简单的答案是“不，但或许应该这样做”。 更详尽的答案请参阅“CFM可执行文件”。 
应该怎样存储应用程序资源？
在Mac OS 9和Mac OS的以前版本中，应用程序将它们的资源存放在应用程序可执行文件的资源分支中。但对于Mac OS X来说，这不再是被推荐的方法。取而代之的是，应用程序应该将它们的资源存放在应用程序束中的独立文件的数据分支中。
此建议的理由与下文中关于文档定型应该有文件扩展名以及Finder元数据的理由相同（请参阅“为何要有扩展名？”）。HFS和HFS 卷格式允许文件具有多分支或数据流。然而，当文件在局域网、企业网或互联网的不同种类计算机系统之间传送时，不在文件数据分支中的任何东西都可能会被容易地丢失。关键是要使资源和所有其它形式的数据在日益互联的网络世界中保持不变。
Carbon应用程序的开发者必须考虑与Mac OS X的资源相关的其它因素，尤其是如果那些应用程序依赖于Code Fragment Manager （CFM）的话。若该应用程序是一个由CFM管理的单文件可执行代码（即，不是一个束化了的CFM应用程序），那么资源应该存放在可执行代码的资源分支中。当打包成单文件CFM可执行代码的应用程序被启动时，将默认地打开它们的资源分支。相反，当打包成束的应用程序被启动时，将默认地打开它们的本地化数据分支资源。
如果Carbon应用程序被打包在束中的话，那么对于资源来说就出现了更多的可能性。您可将某种类型的资源放在它自己的文件内，而不是将资源与资源管理器管理的其它资源结合在一起。例如，若应用程序使用了一个TIFF图像，那么您可将该TIFF图像数据存放在一个具有.tiff扩展名的文件的数据分支中。然后，通过使用合适的束应用编程接口（API），您就可直接地访问该资源。将每个资源存放在它自己的文件中带来很多的益处。例如，这样的方法使“输出”指示在XML属性列表中的资源变得更为容易。Carbon应用程序，不管它们是基于CFM还是基于dyld的，总能使用资源管理器式样的资源。然而，如果将应用程序打包在一个束中（如同被推荐的那样），您就应该把资源存放在束目录的文件中，并且应该只使用这些文件的数据分支。这些文件应该有一个.rsrc的扩展名，它们象任何其它文件一样被当作束资源，并很容易被国际化。尽管.rsrc文件可具有任何基本名称，但如果您给予它们标准名称并将它们存放在资源的标准束位置的话，那么系统束例程将自动地管理资源。它按以下方式工作： 
将非本地化资源存放在一个名为executableName.rsrc的文件中，并将此文件存放在这些资源的束位置处（即，直接存放在Resources目录中）。 
将本地化资源存放在一个名为Localized.rsrc的文件中，将这些文件存放在本地化资源的适当的束位置处（即，.lproj目录中）。 
当应用程序被启动时，系统束例程将自动地打开这些资源并且使它们可供该应用程序使用。
总之，下列选项可供应用程序资源选择：
每个特定类型的资源存放在它自己的文件中，该文件具有一个适合其类型的扩展名。此方法适合于任何应用程序环境中束化了的应用程序。对此“one-per-file”模式例外的是本地化字符串，它们在每次本地化时被收集，并按规定存放在一个名为Localized.strings的文件中；更多信息请参阅“本地化字符串” 。 
束化了的Carbon应用程序可将它们的资源管理器式样的资源存放在文件的数据分支中，每个文件都带有.rsrc的扩展名。这些文件可被存放在非本地化和本地化资源的束位置处。 
未束化了的Carbon应用程序必须将它们的资源管理器式样的资源存放在应用程序可执行代码的资源分支中。 
若希望Finder妥当地处理应用程序及其文档，您就必须将等同于束信息属性列表中的键值对保存为一个类型为 “plst”，ID为0的资源。
关于更多的此类信息，请参阅“束和资源管理器”以及“资源分支”。
如何在Mac OS X中指明文档类型？
在Mac OS X中，通过指定以下两件事情，您可以指明一个文档的类型：
作为文件属性存储的类型和创建者代码（如果它被创建在HFS或HFS 卷上的话） 
与类型相关的一个或多个文件扩展名（例如，.html和.htm） 
Apple推荐您的应用程序使用所有这两种形式来为文档定型。若您的应用程序拥有一种文档，您可在应用程序项目的信息属性列表（Info.plist）中指定它的类型和创建者代码以及文件扩展名（请参阅“信息属性列表”）。Project Builder为输入此信息提供一个工具，可以在用于编译目标的Application Settings设置面板中找到。应用程序应该为其文档强制进行所有有效类型的设置，尤其是设置文档的文件扩展名。请参阅“应用程序应如何保存文件？”。 
对于扩展名有一个最后的说明。一般来说，应用程序应该能够打开那些具有扩展名但是没有类型和创建者代码的文档。对于公共（跨平台）文档类型，例如图像文件、文本文件以及HTML文件，尤其需要此特性。 
可以把插件当作文档吗？ 
插件或任何其它可加载束都是文件包，Finder将它们作为文件呈现。应用程序也可以像处置文件那样，视可加载束为文档。所以，在“如何在Mac OS X中指明文件类型？”中提出的建议也适用于它们。可加载束应该总是带有扩展名，如果适用的话，也应该将类型代码（“BNDL”）和创建者代码写入束中的Info.plist文件中。关于与所有束相关的定型信息，请参阅“必须为应用程序指定什么样的元数据？” 
Finder如何处理文档？ 
Finder使用文件的类型和创建者代码以及文件扩展名来决定此文档的类型和所隶属的应用程序。当Finder在其中的一个窗口显示文件时，它使用此信息寻找适当的图标以表示该文档。当Finder用文件响应用户操作时，即当用户双击图标打开一个文档时，它将文档类型作为键码来查找对应该操作的应用程序。依据定型信息的特征（例如，有扩展名但是没有类型或创建者代码），Finder可能：

[1] [2] 下一页