硬件音量控制
我试图了解什么是最常见的应用程序，这些应用程序大部分都是静音但偶尔会产生声音。这样的应用程序可以利用iOS设备上的侧音量控制，并避免在NSVolume控件小部件中进行设计，我相信这不像硬件侧音量控制那么方便。这种方法适用于像MapQuest 4 mobile这样的应用程序，在这些应用程序中偶尔会有音频提示与其他音乐播放器很好地混合（使用音频闪避），但大多数情况下都是静音。我想知道其他人是如何处理同样的问题的。
我开发了这样一个运行得相当好的系统。在我的方法中，我查询音频API以确定是否正在播放其他音乐（iPod，AOL Radio，Pandora等），然后仅在没有播放其他音频时才开始音频会话。这将硬件侧音量控制与应用程序联系起来，而不是与铃声（对于iPhone）相关联。当你走到后台时，挑战就来了。仅当应用程序未使用音频时，我的方法才会在后台终止（停用）会话。如果有音频播放，则在播放结束时停用会话。
杀死播放背后的想法是恢复用户根据自己的喜好调整铃声音量的能力，如果我的应用继续在后台运行的话。
这个问题源于我在2008-2009期间在iOS上的MapQuest 4手机上开发语音导航功能时遇到的问题。在这个应用程序中，我们希望侧面音量开关在应用程序运行时始终控制转向建议的音量。我后来意识到，在到达目的地并将应用程序发送到后台后，我无法控制我的铃声音量。这是几年前，但我相信应用程序继续在后台运行导致问题。这是一个有趣的案例，当用户正在导航但是如果您继续音频会话将应用程序发送到后台？当应用程序在后台运行时，用户是否更愿意更改应用程序音量或铃声音量？
我的一般用例（当我发布此问题时）涉及在前台运行另一个应用程序（通常是音乐播放器）时在后台导航。然而，当用户坐在主屏幕上时，导航应用程序被发送到后台也是常见的。这是停用音频会话有意义的时候。
它并不像看起来那么直截了当，但我的方法适用于大多数情况。我仍然想知道是否还有其他更可行的解决方案。其他人在做什么？将音量控制包含在自动滑入/滑出的视图中会更有意义吗？有没有我考虑过的事情？你是怎么解决这个问题的？你有什么一般性的建议吗？