对于软件开发人员来说，Mac OS X 是一个非常方便和易于使用的系统。除了相同（或接近）的传统方法外，它还经常为您提供完成相同任务的替代方法。具有此类选择的领域包括应用程序打包、资源处理和文档完成。但是，一种方法通常比另一种方法更好，有时您可以将这些方法结合起来。以下部分描述了应用程序设计的各个重要方面，不仅讨论了您可以做什么，更重要的是，讨论了您应该做什么才能实现性能、互操作性和健壮性。
申请和文件常见问题解答
由于各种因素都会影响应用程序和文档的性质、结构和处理，因此本书的各个部分都提供了有关应用程序和文档的信息。这些因素包括软件包、可执行文件格式、文件系统和 Finder。本节通过总结文档和应用程序对开发人员的重要部分，以问题答案的形式汇总这些信息。
应该为应用程序指定哪些元数据？
为了让用户启动您的（捆绑）应用程序，Finder 应用程序应该能够检测到文件夹是一个捆绑包，然后它应该能够确定该捆绑包是一个应用程序。为了做出这一判断，Finder 首先检查以下两项之一：
在捆绑文件夹上，捆绑位是否设置为“开”？
软件包的扩展名是否为软件包保留的扩展名之一（包括 .app）
如果 Finder 确定文件夹是一个包，它会读取包的 Info.plist 文件中存储的 CFBundlePackageType 键；如果此键包含值“APPL”，则它会确定包是一个应用程序。如果文件不包含此键，它会根据包扩展名（应用程序的扩展名是 .app）确定包类型。
与其他形式的 HFS 和 HFS+ 元数据一样，应用程序包保留 .app 扩展名非常重要，因为在涉及多个文件系统的网络环境中，包位很容易丢失。Project Builder 会在您创建应用程序时自动添加此扩展名vb可执行文件的扩展名，但其他 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 资源相关的其他因素，尤其是当这些应用程序依赖于代码片段管理器 (CFM) 时。如果应用程序是由 CFM 管理的单文件可执行文件（即不是捆绑的 CFM 应用程序），则资源应存储在可执行文件的资源分支中。当启动捆绑到单文件 CFM 可执行文件中的应用程序时，默认情况下会打开它们的资源分支。相反，当启动捆绑的应用程序时，默认情况下会打开它们的本地数据分支资源。
如果您的 Carbon 应用程序打包在包中，那么资源将有更多可能性。您可以将某种类型的资源放在自己的文件中，而不是将资源与资源管理器管理的其他资源分组。例如，如果您的应用程序使用 TIFF 图像，您可以将 TIFF 图像数据存储在扩展名为 .tiff 的文件的数据分支中。然后，通过使用适当的包应用程序编程接口 (API)，您可以直接访问该资源。将每个资源存储在自己的文件中有很多好处。例如，这种方法可以更轻松地“导出”XML 属性列表中指示的资源。Carbon 应用程序，无论是基于 CFM 还是基于 dyld，都可以始终使用资源管理器样式的资源。但是，如果您将应用程序打包在包中（建议这样做），则应将资源存储在包目录中的文件中，并且只应使用这些文件的数据分支。这些文件应具有 .rsrc 扩展名，像任何其他文件一样被视为包资源，并且可以轻松国际化。尽管 .rsrc 文件可以具有任何基本名称，但如果您为它们指定标准名称并将它们放置在资源的标准捆绑包位置中，系统捆绑包例程将自动管理资源。它的工作原理如下：
将非本地化的资源放在名为 executableName.rsrc 的文件中，并将该文件放在资源的包位置（即直接放在 Resources 目录中）。
将本地化资源存储在名为 Localized.rsrc 的文件中，并将这些文件放在适合本地化资源的包位置（即 .lproj 目录中）。
当应用程序启动时，系统捆绑例程将自动打开这些资源并使其可供应用程序使用。
综上所述，对于应用程序资源有以下几种选择：
特定类型的每种资源都存储在其自己的文件中，并带有与其类型相适应的扩展名。这种方法适用于任何应用程序环境中的捆绑应用程序。这种“每个文件一个”模式的例外是本地化字符串，这些字符串在每次本地化时都会被收集并存储在名为 Localized.strings 的文件中；有关更多信息，请参阅“本地化字符串”。
捆绑的 Carbon 应用程序可以将其资源管理器样式的资源存储在文件的数据分支中，每个文件都带有 .rsrc 扩展名。这些文件可以放置在非本地化和本地化资源的捆绑位置中。
未捆绑的 Carbon 应用程序必须将其资源管理器样式的资源存储在应用程序可执行代码的资源分支中。
如果您希望 Finder 正确处理您的应用程序及其文档，您必须将相当于捆绑信息属性列表的键值对保存为类型为“plst”且 ID 为 0 的资源。
有关更多信息，请参阅“捆绑包和资源管理器”和“资源分支”。
如何在 Mac OS X 中指定文档类型？
在 Mac OS X 中，您可以通过指定两项来指定文档的类型：
作为文件属性存储的类型和创建者代码（如果它是在 HFS 或 HFS+ 卷上创建的）
与该类型关联的一个或多个文件扩展名（例如 .html 和 .htm）
Apple 建议您的应用程序使用这两种格式来格式化文档。如果您的应用程序有文档，您可以在应用程序项目的信息属性列表 (Info.plist) 中指定其类型和创建者代码以及其文件扩展名（请参阅“信息属性列表”）。Project Builder 提供了一个用于输入此信息的工具，位于构建目标的应用程序设置窗格中。应用程序应该强制执行其文档的所有有效类型的设置，尤其是设置文档的文件扩展名。请参阅“应用程序应如何保存文件？”。
关于扩展名的最后一点说明。一般来说，应用程序应该能够打开具有扩展名但没有类型或创建者代码的文档。这对于常见（跨平台）文档类型（例如图像文件、文本文件和 HTML 文件）尤其有用。
插件可以用作文档吗？
插件或任何其他可加载包都是文件包，Finder 将它们作为文件呈现。应用程序可以将可加载包视为文档，就像它们将文件视为文档一样。因此，“如何在 Mac OS X 中指定文件类型？”中给出的建议也适用于它们。可加载包应始终具有扩展名，并且如果适用，还应将类型代码（“BNDL”）和创建者代码写入包的 Info.plist 文件中。有关与所有包相关的构造型信息，请参阅“必须为应用程序指定哪些元数据？”
Finder 如何处理文档？
Finder 使用文件的类型和创建者代码以及文件扩展名来确定文档的类型及其所属的应用程序。当 Finder 在其某个窗口中显示文件时，它会使用此信息来查找合适的图标来表示文档。当 Finder 使用文件响应用户操作时（即，当用户双击图标打开文档时），它会使用文档的类型作为关键字来查找与该操作相对应的应用程序。根据类型信息的性质（例如，存在扩展名但没有类型或创建者代码），Finder 可能会：
立即使用应用程序打开此文档
显示一个对话框供用户选择应用程序
使用能够识别该文档类型的应用程序之一打开该文档。
如果文件没有类型和创建者代码，也没有扩展名，Finder 会将其视为非文档文件；该文件将以通用图标显示，并且双击它不会在任何应用程序中打开它。
请记住，应用程序可以将可加载包视为文档。双击包将导致应用程序加载它（如果可以识别）。要以其他方式处理它vb可执行文件的扩展名，应用程序需要在其信息属性列表中指定包的扩展名、类型代码、创建者代码、角色和其他信息。在应用程序将可加载包作为文档处理之前，Finder 必须确定它确实是一个包。
更多信息，请参阅“申请和文件处理”。
为什么要延期？
一些 Macintosh 软件开发人员对文件扩展名感到失望。作为指定文档类型和所有权的一种方式，与多分支 HFS 和 HFS+ 卷格式可能生成的类型和创建者代码以及其他丰富的元数据相比，扩展名似乎很原始。使用扩展名似乎是一种倒退。
确实如此，但仅限于一定范围内。Macintosh 用户不再生活在狭隘的 Macintosh 世界中。在互联网时代，文档经常跨异构网络传输，例如从家用 Macintosh 到 Linux 网络服务器，再到企业 LAN 上的 Windows 计算机。该路径上的每台计算机可能不仅对文档类型有不同的概念，而且对文件构成也有不同的概念。许多计算机系统仅根据众所周知的扩展名来定义文档类型，例如 .jpg、.mp3 和 .html。它们可能不知道如何处理无扩展名的文件，可能会将其视为未知类型。它们还可能忽略 HFS+ 元数据，或者更糟的是，将其完全删除，从而无法挽回地丢失。
应用程序应如何保存文件？
应用程序应将其文档保存为某种类型，并且应用程序应仅以编辑器的角色处理此类型的文档。当应用程序保存文档文件时，Apple 建议它应关联适当的文件扩展名以及任何定义的类型和创建者代码。用户可以稍后更改或删除扩展名（这样做需要付出代价），但在应用程序保存其文档后，应用程序应始终应用所有有效的文档样式方法（包括使用扩展名进行样式设置）。（有关其背后的原因，请参阅“我们为什么要有扩展名？”）
当应用程序可以以一种或多种类型保存文档时，Apple 建议它在“保存”对话框的弹出菜单中显示这些类型（任何“本机”文档类型都是预选类型）。然后应用程序按以下方式处理扩展：
如果用户没有在文件名字段中输入扩展名，则将扩展名添加到其中。
如果用户输入了错误的扩展名，请将其删除并添加正确的扩展名。
如果用户输入正确的扩展名，则接受它。
另一种可能的方法是显示一个添加了正确扩展名的“无标题”文件名，但只有基本文件名可修改；例如，在“Untitled-1.txt”中，只有“Untitled-”可修改。
CFM 可执行文件
前面提到，Mac OS X 是一个非常便捷、易用的操作系统，支持多种文件系统、多种应用程序环境、多种编程模型、多种图形库、多种网络协议栈，还支持多种运行环境和可执行文件格式。具体来说，Mac OS X 可以执行以下几种类型的二进制代码：
由动态链接编辑器 (dyld) 管理的 Mach-O 代码模块
由代码片段管理器 (CFM) 管理的 PEF 代码片段
Java虚拟机管理的Java类文件
在上述三种可执行格式中，Mach-O 最为突出。它是其他类型最终依赖的本机格式。CFM 和 PEF 技术是 Mac OS 9 中突出的库管理器和可执行格式，是通往 Mach-O/dyld 技术的桥梁，就像 CFM-68K 是通往 PowerPC 的桥梁一样。换句话说，Mach-O 和 dyld 是 Mac OS X 的本机可执行格式和库管理器，这意味着所有系统框架，甚至 Carbon 框架，都是以 Mach-O 格式的二进制代码创建的，并由 dyld 管理。但是，CFM 是传统的 Macintosh 库管理器，而 PEF 是代码片段的传统可执行格式，因此目前有许多 Macintosh IDE 为这种运行时环境（包括 Classic 兼容环境）生成应用程序可执行文件。
正如“库管理器和可执行格式”一节中所述，为 Mac OS X 应用程序创建 Mach-O 可执行文件有充分的理由。其中最重要的原因是性能。CFM/PEF 运行时环境位于 dyld/Mach-O 运行时环境之上；因此，基于 CFM/PEF 的代码必须经过额外的软件层才能执行。
但是，没有什么可以阻止您将应用程序创建为由 CFM 管理的二进制文件。这样的二进制文件可以在 Mac OS X 上顺利运行，包括在 Classic 应用程序环境中。
事实上，有时您可能希望 CFM 应用程序在 Classic 环境中运行，而不是在 Carbon 环境中运行；例如，当应用程序依赖于尚未完全移植到 Carbon 的插件时。在这些情况下，Finder 的信息窗口将显示一个选项，让用户在 Classic 中启动所选的 CFM 应用程序。如果您想覆盖此选项并让应用程序始终在 Carbon 中启动（或始终在 Classic 中启动），您可以在信息属性列表中指定适当的启动服务关键字。如果您选择将应用程序部署为 CFM 可执行文件，则必须决定是否将其打包在应用程序包中。在考虑打包时，有三种不同类型的应用程序（Java 除外）可以在 Mac OS X 上运行。表 13-1 显示了可能的类型。
表 13-1 Mac OS X 支持的应用程序类型
捆绑包中的库类型单个文件
CFM/PEF 支持
dyld/Mach-O 不支持 支持
理想情况下，您应该将 CFM 可执行文件打包到应用程序包中。通过这样做，您的应用程序将获得捆绑的所有好处，这些好处在“应用程序就是包”一节中详细描述。捆绑的 CFM 应用程序可以在 Mac OS X 和 Mac OS 9 上轻松启动，但方式不同。在 Mac OS X 上，用户双击包文件（其内容被隐藏），Finder 会启动该应用程序。在 Mac OS 9 上，用户打开 .app 文件夹并双击其中包含的 CFM 可执行文件的别名。还请记住“我应该使用 CFM 还是 Dyld？”一节中给出的建议。理想情况下，从性能的角度来看，应用程序包应该有两个可执行文件：一个最适合在 Mac OS 9 上运行，另一个最适合在 Mac OS X 上运行。目前，没有用于创建捆绑的 CFM 应用程序的开发技术；您必须使用“包”和“应用程序打包”章节中的信息手动创建包。幸运的是，有一条捷径。如果您有权使用 Project Builder，则可以使用它创建一个空应用程序，并将生成的包重新用于您的 CFM 应用程序。即使使用此快捷方式，在创建 CFM 应用程序包时也必须记住以下事项：
捆绑目录本身应定义类型“APPL”并设置捆绑位（如果可能）。它还应具有 .app 扩展名。
CFM 可执行文件应放置在名为 MacOSClassic 的目录中，即 Contents 目录的下一级。
在软件包目录的顶层，创建 CFM 可执行文件的虚拟文件（同名）。以下清单说明了这一点：
MyApp.app/MyApp /* Contents/MacOSClassic/MyApp 的别名 */Contents/MacOSClassic/MyApp…
创建一个名为 Info.plist 的 XML 属性列表文件；在此信息属性列表中，指定“信息属性列表”部分中所述的所有必需的键值对。然后，立即将文件保存在 Contents 目录中。
注意：您可以使用属性列表编辑器应用程序 (/Developer/Applications/PropertyListEditor) 来帮助您创建属性列表。如果您使用其他编辑器创建属性列表，并在文本中包含非 ASCII 字符，请确保编辑器可以以 UTF-8 编码保存文件。您还可以使用现有应用程序的 Info.plist 文件作为模板。
按照“应如何存储应用程序资源？”部分中的说明，将应用程序资源放入包中。
如果您愿意，您可以将 CFM 可执行文件部署为单文件应用程序，并将其 Explorer 样式的资源存储在其资源分支中。如果您这样做并希望 Finder 正确处理应用程序及其文档，则必须将应用程序信息属性列表的内容保存为 ID 为 0 的“plst”类型的资源。如果单文件可执行文件没有“plst”资源，则它被视为只能在 Classic 环境中运行的应用程序。您还可以通过 Finder 信息窗口选项强制 CFM 应用程序在 Classic 环境中启动。
用户界面问题
在应用程序准备部署之前，您可能需要考虑几个用户界面问题。首先，您应该确保您的应用程序遵循“Mac OS X 内部：Aqua 人机界面指南”中的说明。您可以从 Apple Developer Connection 网站获取本书的 PDF 版本，该网站列出了以下 Mac OS X 技术文档：
http://developer.apple.com/documentation/macosx/
其次，您应该确保您的应用程序针对所有语言和地区进行了适当的国际化和本地化；作为国际化的一部分，您应该确保您的应用程序在单个文档上支持多种语言。有关这些方面的信息，请参阅“国际化”一章。以下各节讨论了与开发相关的应用程序用户界面的其他方面。
图标
应用程序或文档图标必须是“icns”资源，它包含在扩展名为 .icns 的文件的数据分支中。Apple 提供了两个应用程序（位于 /Developer/Applications 中）来帮助您创建和管理图标：
Icon Composer 接收大多数标准位图格式（包括 TIFF、PICT、JPEG 和 GIF）的输入图像，并将其转换为一组像素大小为 16 x 16、32 x 32、64 x 64 和 128 x 128 的图标。它还会为前三种尺寸创建位掩码。为了获得最佳效果，您应该为这四种尺寸分别创建不同的图标版本；此外，输入图像的高度和宽度应该相等。该应用程序将图标保存在扩展名为 .icns 的文件中。
Pixie：以不同的放大倍数显示屏幕的各个部分，并允许将这些放大的图像复制到剪贴板或保存为 TIFF 文件。
/Applications/Utilities 中的 Grab 应用程序也可以用于图标设计，因为它可以捕获（作为 TIFF 文件）整个屏幕或其中的一部分。
用户可以为文档指定自定义图标，就像在 Mac OS 9 中一样。为此，他们必须将自定义图标的副本粘贴到当前图标存储的位置，该位置显示在 Finder 的信息窗口（文件 > 显示信息）中。要使用户能够执行此操作，您必须丢弃 Finder 元数据中的默认文档图标。
自定义控制和系统外观
如果您创建了一个可自行绘制的自定义控件，则必须确保它在视觉上与用户在“系统偏好设置”应用程序的“常规”设置窗格中选择的 Aqua 外观一致。当前外观（应用于按钮、菜单和窗口的颜色）为蓝色或石墨色。
为了使Carbon自定义控件与系统外观一致，自定义控件的定义必须使用Appearance
暂无评论内容