Recently I have heard of a couple of cases in which apps submitted to the Windows Phone Marketplace were rejected because they continued running when an incoming phone call arrived. While the Windows Phone 7 Application Certification Requirements don’t specifically state than an application must pause when a call arrives, it seems that certain actions do trigger increased scrutiny from the certification folks. In one case, the app was rejected because it used the phone’s vibration controller and didn’t stop the vibration when the phone rang.
There is no specific API in Silverlight for Windows Phone for detecting incoming phone calls, but there is a pair of events in the PhoneApplicationFrame class named Obscured and Unobscured. Many developers mistakenly assume that these events are only raised when the screen locks and unlocks. In fact, they’re raised anytime your application is obscured by a piece of the UI shell, including when the phone receives a call. Regardless of whether your app is designed to run under a locked screen, you can use these events to make sure that your app behaves properly when it’s interrupted by a phone call or anything else that brings the shell to the foreground.
A page can register handlers for Obscured and Unobscured events through the application’s RootFrame property. The following code snippet registers handlers for both events and calls VibrateController.Stop when the application is obscured by the shell:
(Application.Current as App).RootFrame.Obscured += OnObscured;
(Application.Current as App).RootFrame.Unobscured += OnUnobscured;
void OnObscured(object sender, ObscuredEventArgs e)
void OnUnobscured(object sender, EventArgs e)
The Windows Phone 7 Application Certification Requirements do state that an application “must not delay or prevent the ability of the user to initiate a call, answer an incoming call, or end a call.” If you write an app whose actions could violate that dictum, use Obscured and Unobscured events to devise a fix.