硬件音量控制
我试图了解对于大多数静音但偶尔发出声音的应用程序的最佳实践是什么。此类应用程序可以利用 iOS 设备上的侧面音量控制，并避免需要在 NSVolume 控件小部件中进行设计，我认为这不如硬件侧面音量控制那么方便。该方法适用于 MapQuest 4 mobile 等应用程序，您偶尔会收到与其他音乐播放器（使用音频闪避）很好地融合的音频提示，但大多数情况下是无声的。我想知道其他人如何解决同样的问题。
我已经开发了这样一个运行得相当好的系统。在我的方法中，我查询音频 API 以确定是否正在播放其他音乐（iPod、AOL Radio、Pandora 等），然后仅在没有其他音频正在播放时启动音频会话。这将硬件侧音量控制与应用程序而不是铃声（对于 iPhone）联系起来。当你进入后台时，挑战就来了。仅当应用程序不使用音频时，我的方法才会在后台终止（停用）会话。如果正在播放音频，则会话将在播放结束时停用。
终止播放背后的想法是，如果我的应用程序继续在后台运行，则恢复用户根据自己的喜好调整铃声音量的能力。
这个问题源于我在2008-2009年在iOS上的MapQuest 4 mobile上开发语音导航功能时遇到的问题。在此应用程序中，我们希望侧面音量开关能够在应用程序运行时始终控制转弯建议的音量。后来我意识到，到达目的地并将应用程序发送到后台后，我无法控制铃声音量。这是几年前的事了，但我相信该应用程序继续在后台运行，从而导致了问题。这是一个有趣的情况，当用户正在导航但将应用程序发送到后台时，您是否应该继续音频会话？当应用程序在后台运行时，用户是否更有可能希望更改应用程序音量或铃声音量？
我的一般用例（当我发布这个问题时）涉及在后台导航，同时在前台运行另一个应用程序（通常是音乐播放器）。然而，当用户坐在主屏幕上时，导航应用程序被发送到后台也是很常见的。此时停用音频会话是有意义的。
它并不像看起来那么简单，但我的方法适用于大多数情况。我仍然想知道是否还有其他更可行的解决方案来解决该问题。其他人在做什么？将音量控制包含在自动滑入/滑出位置的视图中是否更有意义？还有哪些事情是我没有考虑到的？你是如何解决这个问题的？您有什么一般性建议吗？
None
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
