|
3.10
无线打印（AirPrint）
用户可以通过AirPrint无线打印应用中的内容，还可以使用打印中心应用检查打印任务。
你可以使用内置的支持程序来打印图片和PDF文件，或者可以使用特定的打印程序接口来做自定义的格式设置和渲染设置。iOS会处理打印机的发现，任务的排序以及在指定打印机上执行打印任务。
通常来讲，用户想要打印文件的时候，只需要点击应用中的标准动作按钮（Action button）。当他们选择了要打印的条目后，可以选择打印机，设置打印属性，最后点击打印按钮开始打印。
打印中心应用是一个只有在处理打印任务时才可见的后台系统应用，用户可以用它来查看打印任务。用户可以在打印中心浏览当前打印队列，查看某个打印任务的详情，还可以取消某个任务。
只需添加少量代码就可以支持基本打印功能（想要学习在代码中添加打印功能，请查看Drawing and Printing
Guide for iOS）。想要确保好的打印体验，可以遵循以下几点：
使用系统提供的动作按钮。用户对系统提供的按钮的含义和行为都很熟悉，所以尽可能的使用系统动作按钮。如果你的应用没有工具栏或导航栏，那就要另当别论了。在这种情况下，你就需要自己设计一个可以出现在应用主界面的打印按钮，因为动作按钮只能在工具栏和导航栏中使用。
在当前情境下打印操作是基本功能时才显示打印项（Print item）。如果当前情境并不适合打印，或者用户并不想打印，就不要将打印项显示出来。
在合适的时候给用户提供更多打印选项。例如，让用户设置打印页码范围或打印份数。
如果用户不能打印，则不要显示特定的打印页面。在向用户展示有打印项的界面前，确保用户的设备是支持打印的。学习如何在代码中实现，请查看UIPrintInteractionController
Class Reference。
3.11 访问用户数据（Accessing User Data）
位置服务允许应用获取用户当前大致的地理位置，设备指向的方向以及用户移动的方向。其他系统服务，例如通讯录、日历、备忘录和相册等，同样也允许应用访问用户存储在里面的数据。
虽然获取了用户数据的应用能带来一定的方便，但还是需要为用户提供维持信息私密性的功能。例如，用户喜欢应用自动给内容加上位置标签，或者可以找到附近的好友，但用户也需要能在不想分享位置的时候关闭这些功能。（想要学习如何给应用增加获取位置功能，请查看Location
and Maps Programming Guide。）
以下几点可以帮助您以用户不反感的方式获取用户数据。
确保使用户理解分享私人数据的原因。如果没有明显的需要，用户自然会对私人信息的请求感到怀疑。为了避免用户反感，确保在用户使用明显需要个人信息的功能时再进行提醒。例如，即使没有打开位置服务用户也可以使用地图，但是在用户使用定位或导航功能时就会有提醒。
应用需要个人信息的原因不明显时向用户做出解释。你可以在提醒框中给出文字性的描述，例如“这个应用需要访问你的通讯录”或者“是否允许应用获取你的地理位置？”。这些文案最好明确且有礼貌以让用户无压力的理解为什么需要访问他们的信息。
讲述原因的文案应该：
不要包含你的应用名称，因为系统提供的提醒框已经包含了。
清楚地描述你的应用为什么需要这些数据。如果可以的话，你也可以解释不会用这些数据做什么。
使用以用户为中心的术语并且进行本地化。
在易于理解的情况下越短越好。尽可能避免超过一句话。
使用句式大小写（sentence-style capitalization）。（句式大小写指的是第一个单词大写，除了专有名词和专有形容词以外的词都小写。）
只有当你的应用没有用户数据就无法提供基础服务时，才在一开始就征求用户的许可。如果你的应用在知道了用户私人信息后才能提供主要功能是显而易见的话，用户不会因此觉得烦扰。
避免在用户选择需要数据的功能之前调用触发提醒框的程序。这样，就可以避免用户疑惑为什么在使用不需要私人数据的功能时有请求提醒。（注意，检查用户位置服务的设置并不会触发提醒。）
检查位置服务的设置来避免触发没必要的提醒。你可以使用核心位置的程序接口来实现（想要学习如何做，请查看Core
Location Framework Reference）。使用这些知识，可以尽可能地在使用需要位置信息的功能时才进行提醒，或者完全避免提醒。
3.12 快速查看（Quick Look）
使用Quick Look，用户可以在你的应用内预览文件，即使你的应用是打不开这个文件的。例如，你可以允许用户预览一些从网站上下载或从其他来源收到的文件。
想要学习如何在应用中加入Quick Look文件预览功能，请查看Document Interaction
Programming Topics for iOS。
用户在应用中预览文件之前，可以在你自定义的视图中查看文件的信息。例如，用户从一封邮件中下载了附件之后，邮件应用（Mail）会在邮件中以自定义的视图展示文件的图标、标题和大小。用户可以通过点击它来预览文件。
你可以在应用中用一个新的视图来显示文件预览，使用全屏或者模态视图。展示的形式取决于你的应用运行在什么设备上。
在iPad上可以使用模态视图显示文件预览。iPad的大屏幕很适合在一个方便用户离开的沉浸式环境中展示文件预览。缩放操作（zoom
transition）很适合显示预览。
在iPhone上可以使用专用的视图，最好是导航视图来显示文件预览。这样可以使用户在应用情境中通过导航进入文件预览。虽然也可以在iPhone应用中使用模态显示，但并不推荐这样。（注意缩放操作在iPhone上并不适用。）
当然，在导航视图中显示文件预览可以在导航栏上放置特定的预览控件。（如果你的视图有工具栏，Quick
Look会将预览控件放在工具栏上。）
3.13 声音（Sound）
无论声音是你的应用的主要内容的一部分，还是锦上添花的元素，你都需要知道用户对声音的期望以及与如何满足这些期望。
3.13.1 理解用户期望（Understand User Expectations）
人们可以使用设备控件来改变声音，也可能使用有线或无线的耳机和听筒。人们也会对于他们的行为如何作用于他们听到的声音有各种各样的期望。虽然你可能发现有一些期望很让人意外，但它们都会遵循用户控制的原则，即应是用户而非设备掌控听到声音的时机。
用户会依据需要将设备静音：
1.避免被突兀的音效打断，比如手机铃声和信息接收音等
2.避免听到作为用户操作副产品的音效，比如键盘或其他反馈音、偶然的声音或应用启动的声音
3.避免听到那些玩游戏时不必要出现的声音，如音效和配乐
例如，在剧院中，用户将他们的设备调至静音以避免打扰剧院中的其他人。在这一情境下，用户仍然希望能在他们的设备上使用应用，但他们不希望被无预期或突兀的声音所打断，如手机铃声或新消息音。
在用户进行单纯操作和有明确期望的操作时，铃音/静音开关（或静音开关）不会屏蔽这些操作所导致的的声音。例如：
1.独立媒体应用中的媒体播放是不会被静音的，因为媒体播放是用户明确要求的。
2.闹钟不能被静音，因为闹钟是用户明确设置的。
3.语言学习应用中的音效素材不能被静音，因为用户进行了明确的操作希望听到它。
4.音频对话应用中的对话不被静音，因为用户打开这个应用的唯一目的就是进行音频对话。
用户使用设备的音量键调整所有音效的音量，包括歌曲、应用音效和设备声音。用户能使用音量按钮屏蔽所有声音，无论铃声/静音（或静音）的开关在什么位置。使用音量键调整应用当前所播放的音频时同样调整了全局系统的音量，只有铃声音量除外。
对于iPhone：当没有音频播放时使用音量键可以调整铃声音量。
用户使用耳机可以私密地接听声音并解放他们的双手。不管这些配件是有线或无线的，用户都对用户体验有特定的期待。
当用户插入耳机或连接无线音频设备时，他们意图继续收听当前的音频，但是是以私密的状态。由于这一原因，他们希望当前正在播放音频的应用能继续不中断地播放。
当用户拔出耳机或断开与无线设备的连接时（抑或设备超出范围或关闭时），他们不希望他们刚刚收听的内容被自动地与他人分享。基于这一原因，他们希望正在播放音频的应用暂停播放，并可以允许他们在愿意时能容易地重新开启播放。
3.13.2 定义应用的音频行为（Define the Audio Behavior
of Your App）
如果必要的话，你可以调整相关的、独立的音量水平以在你的应用音效输出端制造出最好的混音。但是，最终音效输出的音量也应该能被系统音量所控制，无论是通过音量键还是音量滑条进行调节。这意味着应用的音频输出的控制权仍在它所属的用户手中。
确保你的应用适时的显示音频路径选择。（音频路径（audio route）是指音频信号的电子通路，例如源于设备的耳机或是设备的扬声器。）即使人们没有物理性的插入或拔出音频设备，他们也仍希望能选择一个不同的音频路径。为了实现这一功能，iOS能自动显示一个控件来允许用户选择一个输出音频路径（使用MPVolumeView类能允许这个控件显示在你的应用中）。由于选择不同的音频路径是用户主动的行为，用户期望当前播放的音频能继续不中断。
如果你需要显示音量滑条并使用MPVolumeView类时，确保使用系统原生的音量滑条以保证可用。要注意，当激活的音频输出设备不支持音量控制时，要使用合适的设备名称来替代音量滑条。
如果你的应用只产生一些与其功能无必要关系的界面音效时，（尽量）使用系统音效服务（System Sound
Services）。系统音效服务是iOS系统下产生警示音、界面音效和调用振动的技术；它不适合任何其他用途。当你使用系统音效服务来产生音效时，你无法干涉你的音频与设备的音频的交互方式，也无法干涉设备配置变化和干扰的响应方式。如想了解如何使用这一技术，参阅Audio
UI Sounds (SysSound)中的范例项目。
如果音效在你的应用中扮演重要的角色，使用音频会话服务（Audio Session Services）或是AVAudioSession类。这些程序接口不产生音效；相反，它们会帮助你了解你的音频应该如何与设备的音频进行交互以及如何响应设备配置的干扰与变化。
对于iPhone：无论你使用什么样的技术来制作音频，无论你如何定义来它的行为，手机总是可以中断当前运行的应用。这是因为任何应用都不应该阻止人们接收来电。
在音频会话服务中，音频会话（audio session）执行了你的应用与系统之间音频中介的功能。音频会话中最重要的方面之一就是类目（category），它定义了你的应用的音频行为。
为了实现音频会话服务带来的好处并能提供用户期望的音频体验，你需要选择可以完美描述应用音频行为的类目。具体情况取决于你的应用只在前台播放音频还是也要在后台播放音频。在你做这一选择的时候，遵循以下这些原则：
1.依据其语义而非精确的行为来选择音频会话类目。通过选择目的清晰的类目，你可以确保你的应用能表现得符合用户期望。除此之外，当以后行为的精确集合被重新定义时，它可以为你的应用提供最佳的机会使其合理运行。
2.在极少数情况下，可以添加属性到音频会话中以修正一个类别的标准行为。一个类别的标准行为代表多数用户的期望，因此在你改变那个行为之前你应该仔细地考虑。例如，你可能要添加“闪避”属性以确保你的音频声音能比其他所有的音频都大（除了手机音频），如果你的用户对你的应用是如此期望的话。（欲了解更多关于音频会话属性的内容，
请参见Audio Session Programming Guide中的Fine-Tuning the
Category章节。）
3.依据设备当前的音频环境来考虑你的类目选择。这也许意味着，例如，用户在使用你的应用时可能听着其它的音效而非你的配乐。如果你这样做，要确保避免当你的应用启动时，迫使用户停止收听当前的内容或要需要额外地在两者之间做出选择。
4.通常来说，要避免在你的应用运行时改变类目。改变类目的首要依据是你的应用是否需要在不同的时机支持记录和播放。在这种情况下，更好的选择是依据需要在录音类目与播放类目之间转换，而非选择播放和录音类目。这是因为选择录音类目可以确保正在录音时不会听到警告音，比如来信提示音。
表31-1列举了你可以使用的音频会话类目。不同的类目可以允许通过铃声/静音开关或静音开关（或设备锁）来实现静音、与其他的音频混合或者控制应用在后台播放。（欲了解编程界面上所呈现的的类目和属性的准确名称，参见Audio
Session Programming Guide。）
表31-1 音频会话类目及其相关行为
*如果你选择音频处理类目并且你希望在后台运行音频进程，你需要在完成音频处理之前防止你的应用被暂停。欲了解如何实现这一功能，参见《iOS应用编程指南》中的执行长时间运行的后台任务。
以下是一些示例情境，其中指示了如何选择音频会话类目以提供用户喜欢的音频体验。
情境1：一个帮助人们学习新语言的教育类应用。你需要提供：
用户点击特定控件时播放反馈音效
当用户想听到正确发音的示例时播放字词的记录
在这个应用中，声音对于主要功能是十分重要的。人们使用这个应用来听他们正学习的语言的词语与短语，因此即使当设备锁定或者被调至静音时也要能播放声音。因为用户需要清晰地听到声音，他们会期望其他他们可能播放的音频都被静音。
为了满足用户对于该应用所期望的音频体验，你应该使用播放（Playback ）类目。虽然这一类目可以被定义为与其他音频混合，但该应用应该使用默认的行为以确保其他的音频不会干扰那些用户明确选择听到的教育性内容。
场景2：网络电话应用。你需要提供：
接收音频输入的能力
播放音频的能力
在该应用中，声音对于主要功能是十分重要的。人们经常会在使用另一个应用时使用该应用与他人进行交流。用户期望能在他们将设备调至静音或设备被锁定时接听电话，他们希望在来电期间其他音频被静音。他们也希望应用在后台运行时也能继续打电话。
为了满足用户对于该应用所期望的音频体验，你应该使用播放和录音（Play and Record）类目，并且你要确保只有在你需要时才会激活你的音频会话，以便用户可以在打电话过程中使用其他音频。
场景3：允许用户通过不同任务引导角色的游戏。你需要提供：
不同的游戏运行音效
配乐
在该应用中，声音会在很大程度上提升用户体验，但对于主任务并没有那么重要。而且，用户可能会希望能在玩游戏时静音或听他们乐单中的歌曲而不听游戏配乐。
最好的策略是在你的应用启动时确定用户是否在收听其他音频。不要要求用户选择他们是要收听其他音频或是你的音效。而应该使用音频会话功能中的AudioSessionGetProperty来询问kAudioSessionProperty_OtherAudioIsPlaying属性的状态。依据所询问的答案，你可以选择环境（Ambient）或是个人环境（Solo
Ambient）类目（这两种类允许用户静音玩游戏）：
如果用户正在听其他音频，你应该假设他们想要继续听并且不想被强迫收听游戏音效。在这种情境下，你最好选择环境（Ambient）类目。
如果用户在你的应用启动时没有在收听其他音效，你最好选择个人环境（Solo Ambient）类目。
情境4：一个为用户到达目的地提供准确、实时导航指示的应用。你需要提供：
每一步旅途的语音指示
一些反馈音效
支持用户继续收听他们自己的音频的能力
在该应用中，无论应用是否是在后台运行，语音导航指示都表现为主要任务。基于这一原因，你最好使用播放（Playback）类目，它允许你的音频在设备被锁定、静音或是在后台运行时仍可以播放。
你可以通过添加kAudioSessionProperty_OverrideCategoryMixWithOthers属性来实现允许人们在使用你的应用时收听其他音频。但是你也想要确保用户在他们正在播放其他音频时能听到语音提示。你可以为音频会话添加kAudioSessionProperty_OtherMixableAudioShouldDuck属性来确保你的音频比其他音频的声音更大，除了iPhone上的电话以外。这些设置允许应用在后台运行时也可以恢复音频会话，可以确保用户能获得实时更新的导航。
情境5：一个允许用户上传文本和图片到网站上的博客应用。你需要提供：
简短的启动音效文件
用以补充用户行为的各式各样的短音效（例如当邮件被上传后播放的音效）
发送失败播放的警示音
在该应用中，声音提升了用户体验，但也不是必需的。主任务与音频并没有关系，用户也不是必须要通过收听声音来成功使用应用。在这一情境中，你最好使用系统声音服务来产生声音。这是因为应用中所有声音的音频情境都应符合本技术的目的，这意味着要遵循用户意愿制造服从于设备锁定和铃声/静音（或静音）开关的界面音效和警示音。
3.13.3 管理音频中断（Manage Audio Interruptions）
有时候，当前播放的音频会被来自于不同应用的音频所打断。例如，在iPhone上，来电会持续中断当前应用的音频。在多任务情境中，这种音频中断的频率会很高。
为了提供用户喜欢的音频体验，iOS系统依赖于你来：
识别可能会引起应用中断的音频类型
当应用在音频中断结束后继续运行时进行合理地反馈
每个应用需要识别会引起音频中断的类型，但不是每个应用都需要决定如何在音频中断结束后进行反馈。这是因为多数类型的应用应在音频中断结束后恢复音频。只有那些主要或部分（即那些提供媒体播放控制的应用）的媒体播放应用，才必须才用额外的步骤来决定合适的反馈。
从概念上讲，基于中断音频与中断结束后用户所期望的特别的应用反馈，有两种类型的音频中断：
可恢复性中断是（resumable interruption）被一些音频引起的，那些音频被用户视为他们主要听觉体验的的插曲。在可恢复性中断结束后，显示媒体播放控件的应用应该恢复它被中断前的任务，无论是在播放音频还是保持暂停。没有音频播放控件的应用则应该恢复播放音频。例如，试想用户在iPhone上使用应用播放音乐时，电话在歌曲的中间接入。用户接起了电话，期望在他们通话时播放的应用能静音。在通话结束后，用户希望播放的应用自动恢复播放歌曲，因为音乐而非电话才是他们的主要听觉体验，而他们在电话接入前也没有暂停音乐。另一方面，如果用户在电话接入前暂停了音乐播放，他们将希望电话结束后音乐仍保持暂停。其他能引起可恢复性中断的应用的例子包括那些具备闹钟、音频提示（例如语音方向指示）或其他间歇性音频功能的应用。
不可恢复中断（nonresumable interruption）是由那些被用户视为首要听觉体验的音频所引起的，比如媒体播放用用的音频。在不可恢复中断结束后，显示媒体播放控件的应用不应该恢复播放那个音频。而没有媒体播放控件的应用应该恢复播放音频。例如，假设用户正在收听一个音乐播放应用（音乐应用1），此时另一个音乐播放应用（音乐应用2）打断了它。用户终止后决定收听音乐应用2一段时间。在退出音乐应用2之后，用户不想要音乐应用1自动恢复播放，因为此时他们主动将音乐应用2作为首要的听觉体验。
下列准则可以帮助你决定支持什么信息以及如何在音频中断之后继续:
确定你的应用引起的音频中断的类型。在你的音频结束时，你可以通过以下两种方式中的一种禁用你的音频会话来实现这一功能：
如果你的应用引起了一个可恢复性中断，使用AVAudioSessionSetActiveFlags_NotifyOthersOnDeactivation标识禁用你的音频会话。
如果你的应用引起了一个不可恢复中断，不用任何标识就可以禁用你的音频会话。
倘若不这样，标识会在适宜的情况下允许iOS系统赋予被中断的应用自动恢复播放它们的音频的能力。
决定是否应该在一个音频中断结束后恢复音频。你应依据你应用中所提供的音频用户体验来做这一决断。
如果你的应用呈现了用户用于播放或暂停音频的媒体播放控件，你需要在一个音频中断结束后检
AVAudioSessionInterruptionFlags_ShouldResume标识，如果你的应用接受应该恢复（Should
Resume）标识，你的应用应该：
1.如果你的应用被打断时在主动播放音频，恢复播放音频；
2.如果你的应用被打断时没有在主动播放音频，不需要恢复播放音频。
如果你的应用没有呈现任何用户可用于播放或暂停音频的媒体播放控件，你的应用应该在音频中断结束后总是保持恢复之前播放的音频，无论是否呈现了“应该恢复”标识。例如，播放音效的游戏应该在中断后自动恢复播放音效。 |
