问题
Hardware Volume Control
I'm trying to understand what is best practice for apps that are mostly silent but occasionally produce sound. Such apps can take advantage of the side volume control on iOS devices and avoid the need to design in a NSVolume control widget, which I believe is not as convenient as the hardware side volume control. The approach would apply to apps like MapQuest 4 mobile where you get occasional audio prompts that blend well with other music players (using audio ducking) but are silent for the most part. I'm wondering how others are addressing this same issue.
I have developed such a system that works rather nicely. In my approach I query the audio APIs to determine if other music is playing (iPod, AOL Radio, Pandora, etc.) then start an audio session only if no other audio is playing. This ties the hardware side volume control to the app instead of the ringer (for iPhones). The challenge comes when you go to the background. My approach kills (deactivates) the session in the background only if the app is not using audio. If there is audio playing the session is deactivated at the conclusion of the playback.
The idea behind killing the playback is to restore the user's ability to adjust the ringer volume to their liking should my app continue to run in the background.
This question originates from issues I faced when developing the voice navigation feature on MapQuest 4 mobile on iOS in 2008-2009. In this app we wanted the side volume switch to control the volume of the turn advice at all times while the app was running. I later realized that I could not control my ringer volume after arriving at my destination and sending the app to the background. This was years ago but I believe the app was continuing to run in the background which lead to the problem. It is an interesting case, when the user is navigating but sends the app to the background should you continue the audio session? Is is more likely that the user would like to change the app volume or the ringer volume while the app runs in the background?
My general use case (when I posted this question) involved navigating in the background while running another app in the foreground (commonly a music player). However it is also common for the navigation app to be sent to the background while the user sits on the home screen. This is when it would make sense to deactivate the audio session.
It is not as straight forward as it seems but my approach works for most cases. Still I am wondering if there are other more viable solutions to the problem. What are other people doing? Would it make more sense to just include the volume control in a view that auto slides in/out of place? Are there things that I have not considered? How have you approached the problem? Do you have any general suggestions?
来源：https://stackoverflow.com/questions/7828751/best-practice-for-volume-control-ios