In a WPF application you say App.Exit() and your application terminates. It’s not so simple in Windows Phone. Since there is no Exit() method – it’s hard to know what to do.
I’ll assumption there are valid reasons to exit your application. One example might be too many login attempts. You might have your own scenarios.
If you throw an unhandled exception your application will terminate.
For now, this technique will pass certification (as I have been told).
This will not work
I only mention this because I have mentioned it as a working option in the past. However it fails:
In the code above we clear the BackStack. The BackStack is isolated to your application. It contains any page in your application from which you called the NavigationService’s Navigate() method. Clearing the BackStack allows you to be certain the hardware Back button will Exit your application.
Here’s what is wrong: Calling base.OnBackKeyPress() does nothing. As a result, your Exit method will successfully clear the BackStack, but then it will do nothing.
I apologize: in the past I recommended this approach. My testing was foolishly done in the OnBackPressed override. This method simply does not work. But keep reading if you want a functional snippet.
This will work
In the code above, we are going back when we cannot go back. In fact, the CanGoBack property will be false. Calling the GoBack method when the CanGoBack property is false will result in an unhandled exception. Any unhandled exception will exit a Windows Phone application.
Why do it this way?
Yes, it is the same as throwing an unhandled exception. But, the reason I think this method is worthwhile is because someday an unwrapped “throw” statement in your code may not pass certification. And (IMO) this technique is a viable candidate for an actual Exit() technique someday.
This should be considered “Crashing your Application” – not Exiting it.
This is just Wrong!
Fundamentally, a Windows Phone Application is not supposed to Exit by any means except the hardware buttons (or by system chrome like an incoming phone call). The framework was implemented with no Exit technique implemented.
To that end, Nick Randolph (one of our Windows Phone MVPs and the author of http://builttoroam.com) has made a strong case to me that Exiting a Windows Phone Application is altogether wrong – even using unhandled exceptions. his four points are:
1. Technical Certification Requirements counsels against unhandled exception.
5.1.2 Application Closure
The application must handle exceptions raised by the .NET Framework and not close unexpectedly. During the certification process, the application is monitored for unexpected closure. An application that closes unexpectedly fails certification. The application must continue to run and remain responsive to user input after the exception is handled.Recommendations
When handling exceptions, an application should provide a user-friendly error message. You may present a message that is relevant to the context of the application.2. The Exit() strategy is a hold-over from other mobile operating systems.
3. Exit() is not in the platform so it’s reasonable to follow the leading pattern.
4. There’s always a reasonable work-around for every Exit() scenario.
Kudos to Nick for his purity. Let’s chase this topic of work-around options!
A Work-around
This is a perfect work-around:
In the code above, we still clear the BackStack – this ensures the user does not navigate (using the Back button) to any other part of your application. Then we disable everything – IsHitTest is handy to prevent any touch events you may have wired. Then we disable the ApplicationBar (if you have any buttons).
This work-around probably gives you the same effect you are looking for when you are desiring an Exit() technique.
It’s just not really exiting.
Conclusion
Someday we might have an Exit method. Right now we do not. That said, given the current disposition of the Windows Phone, your application should probably not exit. But, in the end, you are your application’s developer – not me.
Best of luck!