Mac应用程序编程指南(一)

注:原文引用Mac开发官方文档,鉴于Mac开发文档较少,本人主要做一下梳理,同时记录学习过程。


Mac应用环境

(1)设计易于使用的环境

使用Cocoa为OS X编写应用程序。

*用户不必手动保存工作。Cocoa中的文档模型提供了保存用户基于文件的文档而无需用户交互的支持;请参阅文档架构免费提供许多功能

*应用程序应在登录时恢复用户的工作环境。Cocoa提供对归档当前状态的应用程序界面的支持(包括未保存文档的状态),并在启动时恢复该状态;请参阅用户界面保存

*应用程序应该支持自动终止,以便用户永远不必退出。自动终止意味着当用户关闭应用程序的窗口时,应用程序似乎退出,但实际上只是静静地移动到背景上。优点在于随着应用程序简单地回到前台,随后的启动几乎是即时的。请参阅自动和突然终止应用程序改善用户体验

*您应该考虑通过实施用户界面的全屏版本为用户提供身临其境的全屏体验。全屏体验消除了外界的分心,并允许用户关注其内容;请参阅实施全屏体验

*支持触控板手势,在您的应用程序中进行适当的操作。手势为常见任务提供简单的快捷方式,可用于补充现有的控件和菜单命令。OS X通过正常的事件处理机制提供对您的应用程序报告手势的自动支持;参见可可事件处理指南

*考虑最小化或消除用户与原始文件系统的交互。通过打开和保存面板将整个文件系统公开给用户,通过iPhoto和iTunes的方式,一些应用程序可以通过专门为应用程序内容设计的简化浏览器中呈现用户内容,从而提供更好的用户体验。OS X使用一个定义明确的文件系统结构,可以轻松放置和查找文件,并包含许多访问这些文件的技术;请参阅文件系统

*对于支持自定义文档类型的应用程序,请提供Quick Look插件,以便用户可以从您的应用程序外部查看文档;请参阅快速编程指南

*应用程序应该支持OS X用户体验的基本功能,使应用程序优雅直观,例如直接操作和拖放。用户应该保持控制,收到一致的反馈,并且能够探索,因为该应用程序是宽容的动作;请参阅macOS人机接口指南

所有上述功能都可以由Cocoa支持。


(2)运行环境的低级细节

*并发和线程

每个进程都以单个执行线程开始,并可根据需要创建更多的线程。虽然可以创建直接使用POSIX和其他更高级别的接口线程,最好是间接创建它们使用块对象GCD操作对象,通过Cocoa并发技术NSOperation类。

GCD和操作对象是简化或消除通常与线程编程相关的许多问题(如同步和锁定)的原始线程的替代方法。具体来说,它们定义了一个异步编程模型,其中只指定要执行的工作和要执行的顺序。系统然后处理在当前硬件上尽可能有效地安排必要的线程和执行任务所需的繁琐工作。不应该使用GCD或操作进行需要时间敏感数据处理(例如音频或视频播放)的工作,但您可以将其用于大多数其他类型的任务。

有关使用GCD和操作对象在应用程序中实现并发性的更多信息,请参阅并发编程指南

*文件系统

Finder不会将整个文件系统暴露给用户,而是隐藏普通用户不需要使用的任何文件和目录,例如低级UNIX目录的内容。应用程序仍然可以访问他们具有有效权限的任何文件和目录,无论它们是否被Finder隐藏。

创建应用程序时,您应该了解并遵循与OS X文件系统关联的约定。知道放置文件的位置以及如何从文件系统中获取信息可确保更好的用户体验。文件系统中的每个文件都有其位置,应用程序需要知道将它们创建的文件放在哪里。通过App Store分发应用程序,这尤其重要。

列出了应用程序通常进行交互的目录。

Applications directory

应用程序的安装目录。但是,全局应用程序目录的路径是/Applications每个用户目录可能包含一个包含用户特定应用程序的本地应用程序目录。不需要直接使用此路径。要访问应用程序包中的资源,使用NSBundle对象。

Home directory

应用程序的配置决定了应用程序看到的主目录的位置:对于在OS X v10.7及更高版本的沙箱中运行的应用程序,主目录是应用程序的容器目录。有关容器目录的更多信息,请参阅钥匙串

对于在沙箱外运行的应用程序(包括在10.7之前运行的OS X版本的应用程序),主目录是/Users包含用户文件的用户特定子目录。要检索到主目录的路径,请使用该NSHomeDirectory功能。

Library directory

Library目录是用于存储私人应用程序相关数据和首选项的顶级目录。有几个Library目录分散在整个系统中,但是您应该始终使用位于当前主目录内的Library目录。

不要将文件直接存储在Library目录的顶层。相反,将它们存储在此表中描述的特定子目录之一中。

在OS X v10.7及更高版本中,Finder默认隐藏用户主文件夹中的Library目录。因此,不应该将该文件存储在您希望用户访问的目录中。

要获取此目录的NSLibraryDirectory路径,请使用NSUserDomainMask域的搜索路径密钥。

Application Support directory

应用程序支持目录是您的应用程序存储支持应用程序的任何类型的文件,但该应用程序不需要运行的文件,例如文档模板或配置文件。文件应该是特定于应用程序的,但不应该存储用户数据。该目录位于Library目录下。

不要将文件存储在此目录的顶层:始终将它们放在为您的应用程序或公司命名的子目录中。

如果资源适用于系统上的所有用户,例如文档模板,请将其放入/Library/Application Support。要获取此目录的NSApplicationSupportDirectory路径,请使用NSLocalDomainMask域的搜索路径密钥。如果资源是用户特定的,例如工作区配置文件,请将它们放在当前用户的~/Library/Application Support目录中。要获取此目录的NSApplicationSupportDirectory路径,请使用NSUserDomainMask域的搜索路径密钥。

Caches directory

缓存目录是存储缓存文件和其他临时数据的位置,您的应用程序可以根据需要重新创建。该目录位于Library目录下。

不要将文件存储在此目录的顶层:始终将它们放在为您的应用程序或公司命名的子目录中。您的应用程序负责在不再需要时清除缓存数据文件。系统不会从此目录中删除文件。

要获取此目录的NSCachesDirectory路径,请使用NSUserDomainMask域的搜索路径密钥。

Movies directory

电影目录包含用户的视频文件。要获取此目录的NSMoviesDirectory路径,请使用NSUserDomainMask域的搜索路径密钥。

Music directory

音乐目录包含用户的音乐和音频文件。要获取此目录的NSMusicDirectory路径,请使用NSUserDomainMask域的搜索路径密钥。

Pictures directory

图片目录包含用户的图像和照片。要获取此目录的NSPicturesDirectory路径,请使用NSUserDomainMask域的搜索路径密钥。

Temporary directory

临时目录是您存储不需要在应用程序启动之间持续存储的文件的位置。您通常将此目录用于临时文件或与应用程序持久数据无关的其他类型的短命名数据文件。该目录通常从用户隐藏

您的应用程序应尽快从此目录中删除文件。在系统启动时,系统还可以从该目录中清除滞留文件。

要获取此目录的路径,请使用该NSTemporaryDirectory功能。

清单1-1显示了如何检索Application Support目录的基本路径,然后向其附加一个自定义应用程序目录的示例。

清单1-1获取Application Support目录的路径

NSFileManager * fileManager = [NSFileManager defaultManager];

NSURL * appSupportDir = nil;

NSArray * urls = [fileManager URLsForDirectory:NSApplicationSupportDirectory inDomains:NSUserDomainMask];

if([paths count]> 0){

appSupportDir = [[url objectAtIndex:0] URLByAppendingPathComponent:@“com.example.MyApp”];

}

有关如何访问公知系统目录中的文件的更多信息,请参阅“文件系统编程指南”

与文件系统交互

*区分大小写

HFS +文件系统是不区分大小写的,但也可以区分大小写。因此,在代码中指定文件名和目录时,最好假定区分大小写。

*路径建设

使用NSURLNSString类的方法构造路径。NSURL由于能够指定本地文件系统中的路径,而是指定网络资源的路径,因此该类优先于路径构建。

*文件属性

可以使用类的getResourceValue:forKey:error:方法检索许多与文件相关的属性NSURL。您还可以使用NSFileManager对象来检索许多与文件相关的属性。

*文件权限

使用访问控制列表(ACL)和BSD权限管理文件权限。系统尽可能使用ACL来指定文件和目录的精确权限,但是当没有指定ACL时,它会回退到使用BSD权限。

默认情况下,您的应用程序创建的任何文件都由当前用户拥有并提供适当的权限。因此,您的应用程序应始终能够读写明确创建的文件。此外,应用程序的沙箱可能允许它在特定情况下访问其他文件。有关沙箱的更多信息,请参阅应用程序沙箱和XPC

*跟踪文件更改

无法使用文件协调界面的应用程序(请参阅使用其他进程协调文件访问)跟踪文件和目录的更改可以改用FSEvents API。该API提供了一个用于跟踪文件系统交互的下级界面,并且在OS X v10.5及更高版本中可用。

有关如何使用FSEvents API的信息,请参阅“文件系统事件编程指南”


安全

OS X中的安全技术可帮助您保护由应用程序创建或管理的敏感数据,并帮助最大限度地减少恶意代码成功攻击造成的损失。这些技术会影响您的应用程序与系统资源和文件系统的交互。

应用程序沙箱XPC

您可以按照安全编码指南中推荐的做法来保护您的应用免受恶意软件的攻击。但攻击者只需要在您的防御中找到一个洞,或者与您链接的任何框架和库中找到一个孔,以获得对应用程序的所有权限的控制。

如果恶意代码利用您的应用程式,App Sandbox可以防止被盗,损坏或已删除的用户数据的最后一道防线。App Sandbox还可以最大限度地减少编码错误造成的损害。其战略有两个方面:

应用程序沙箱可让您描述应用程序如何与系统进行交互。系统然后授予您的应用程序所需的访问权限,以完成其工作,而不再需要。为了让您的应用程序提供最高级别的损坏遏制,最佳做法是尽可能采用最严格的沙箱。

应用程序沙箱允许用户通过打开和保存对话框,拖放和其他熟悉的用户交互方式透明地授予您的应用程序附加访问权限。

您可以通过在Xcode中设置权限来描述您的应用程序与系统的交互。的权利是一个键值对,在定义属性列表文件,赋予特定的功能或安全许可的目标。例如,有权利密钥表示您的应用程序需要访问摄像机,网络和用户数据,如地址簿。有关OS X中可用的所有权利的详细信息,请参阅授权密钥参考

当您采用App Sandbox时,该系统提供了一个特殊的目录供您的应用程序使用,并且只能由您的应用程序称为容器。您的应用程序对容器进行了无限制的读/写访问。POSIX层上方的所有OS X路径查找API都相对于容器而不是用户的主目录。其他沙盒应用程序无法访问您的应用程序的容器,如代码签名中进一步描述。

iOS注意:由于不是用户文档,OS X容器与iOS容器不同,iOS容器在用户文档中是唯一的位置。作为用户文档的唯一本地位置,iOS容器通常被称为应用程序的Documents目录。

此外,iOS容器还包含该应用程序本身。这在OS X中不是这样。

iCloud注意:如iCloud Storage所述,Apple的iCloud技术也使用名称“container”。iCloud容器和App Sandbox容器之间没有功能连接。

您的沙盒应用程序可以通过以下三种方式访问​​其容器外的路径:

在用户的特定方向

您可以使用特定文件系统位置的权限(如Movies文件夹)配置应用程序

当路径在某些目录中是世界可读的时

与用户进行交互以扩展沙箱的OS X安全技术称为Powerbox。Powerbox没有API。例如,当您使用NSOpenPanelNSSavePanel类时,或用户在应用程序中拖放时,您的应用程序会透明地使用Powerbox。

一些应用程序操作更有可能成为恶意利用的目标。示例是对通过网络接收的数据的解析以及视频帧的解码。通过使用XPC,您可以通过将这些潜在危险的活动分成自己的地址空间来提高App Sandbox提供的损害容限的有效性。

XPC是通过启用特权分离来补充App Sandbox的OS X进程间通信技术。特权分隔反过来是一种开发策略,您可以根据每个部分需要的系统资源访问将应用程序分割成多个。您创建的组件被称为XPC服务。有关采用XPC的详细信息,请参阅“守护进程和服务编程指南”

有关App Sandbox及其使用方法的完整说明,请参阅“应用程序沙箱设计指南”

代码签名

OS X采用称为代码签名的安全技术,允许您证明您的应用程序确实由您创建。应用程式代码签署后,系统可以侦测到应用程式的任何变更 - 无论是意外引起变更,还是恶意代码。各种安全技术,包括App Sandbox和家长控制,都取决于代码签名。

在大多数情况下,您可以依赖Xcode的自动代码签名,这只需要在项目的构建设置中指定代码签名身份。在Mac的“工具流程指南”中的代码签名应用程序中描述了采取的步骤。如果您需要将代码签名合并到自动构建系统中,或者将应用程序与第三方框架相链接,请参阅代码签名指南中所述的步骤。

当您采用App Sandbox时,您必须对您的应用程序进行编码。这是因为授权(包括启用App Sandbox的特权)内置于应用程式的代码签名中。

OS X强制应用程序的容器和应用程序的代码签名之间的关系。这个重要的安全功能确保没有其他沙盒应用可以访问您的容器。该机制的工作原理如下:系统创建一个应用程序的容器后,每次启动具有相同软件包ID的应用程序时,系统会检查应用程序的代码签名是否与容器预期的代码签名相匹配。如果系统检测到不匹配,则会阻止该应用启动。

代码签名的应用程序中沙箱的情况下一个完整的解释,阅读的深度应用程序沙箱中的应用沙盒设计指南

钥匙扣

钥匙串是用于存储用户密码和其他秘密的安全加密容器。它旨在帮助用户管理他们的多个登录,每个登录具有自己的ID和密码。您应该始终使用钥匙串来存储应用程序的敏感凭据。

有关钥匙串的更多信息,请参阅钥匙串服务编程指南中的钥匙串服务概念

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 156,757评论 4 359
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,478评论 1 289
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 106,540评论 0 237
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,593评论 0 203
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 51,903评论 3 285
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,329评论 1 210
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,659评论 2 309
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,383评论 0 195
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,055评论 1 238
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,337评论 2 241
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,864评论 1 256
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,227评论 2 251
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,820评论 3 231
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,999评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,750评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,365评论 2 269
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,260评论 2 258

推荐阅读更多精彩内容