While working on a Windows Phone 7 application recently, I discovered some limitations of the platform that were rather frustrating. The application allowed audio to be recorded and played back, and it was expected that recording would pause if an incoming phone call was received on the phone. The app was already designed to pause recording when the app was deactivated, and initially I thought an incoming phone call would cause deactivation. I was surprised to discover that it did not. Instead, the app continued to run uninterrupted while a phone call was taken. If the app was recording at the time, recording would continue throughout the phone call. Interestingly, the XNA Microphone class appeared to be muted during the phone call, with that portion of the recording being blank, neither side of the conversation captured.
A little searching confirmed that an incoming phone call does not deactivate a WP7 app. Instead, the app is “obscured”, and the only way to detect the phone call is by subscribing to the Obscured event of the PhoneApplicationFrame class. Unfortunately, the Obscured event simply indicates that something from the OS is obscuring the visual of your app (“the shell chrome is covering the frame”, in the words of the MSDN docs), without providing any detail about the source cause. As a result, many things can cause Obscured to fire, including an incoming phone call, locking of the screen, an incoming text message, a calendar event notification, and a MessageBox. There are no events fired specific to the different types of OS interruptions that can occur, nor any properties in the ObscuredEventArgs to indicate the source cause. There is an IsLocked property within ObscuredEventArgs that can be used to detect if locking of the screen caused Obscured to fire, but otherwise no other useful information is given.
This presented a problem for our application, and I could imagine it being a problem for others as well. In our app we wanted to handle incoming phone calls differently than other types of OS interruptions, such as incoming text messages or calendar event notifications. The former should pause recording, while the latter should not. (Pausing recording in response to something as innocuous as a calendar notification would be an awful experience within our app, as the user could easily be unaware recording had stopped, causing potentially important audio to be missed.)
Even the ability to discriminate a screen lock as the source of the Obscured event is of limited value. We’ve set up our app to continue running (and recording) under lock screen, and at first glance it seems like it would be helpful to ignore the Obscured event if a screen lock was the cause. Unfortunately, once the screen is obscured, no other OS interruptions fire the Obscured event until the screen is once again unobscured. Although we did not want to pause recording in response to the lock screen, we did want to pause recording in response to an incoming phone call, including when the screen was locked. The Obscured event is not fired in response to the incoming phone call if the screen is locked, however. It would be impossible for us to have consistent behavior both while the screen is locked and unlocked.
As a result of these limitations, we decided to ignore the Obscured event altogether, and simply allow recording to continue while a phone call was taken. Most users will likely dismiss incoming phone calls while recording, but if they take the call, at least their conversations will not be recorded. (Instead a blank gap appears in the recorded audio.) Hopefully future versions of WP7 offer more information about OS interruptions, so apps can respond in an intelligent manner dependent upon the source of the interruption.
