The good management of the back button is really important: for example,
a valid application must quit when you press the back button when you are on its start page. Other constraints must be respected like when you press the back button when a dialog is open (like a ListPicker control), you have to cancel the back behaviour and close the dialog...
For some applications, there's not necessary to think about it because the default behavior is well suited. But for other applications, it will sometimes be necessary to make some changes.
I will show an example of my application (
Blind Friends)... If an user wants to play, he will go through these pages:
| > |
| > |
| > |
|
Imagine that the user presses the "back to main menu" at the end of the game, I'll use NavigationService.Navigate(Uri source) to bring him back to home. That will work but if the user presses the back button once he is on the home page, the application will go to the score page because this is the previous page in the navigation stack... My application can be validated with this issue because it must be closed when the user presses the back button on this page.
To regain the normal behaviour, I have modified the URI in NavigationService.Navigate(Uri source):
1: NavigationService.Navigate(new Uri("/Pages/MainPage.xaml?homeFromPageScore=true", UriKind.Relative))
And in the codebehind of my home page:
1: protected override void OnNavigatedTo(NavigationEventArgs e)
2: {
3: base.OnNavigatedTo(e);
4:
5: if (e.NavigationMode == NavigationMode.New && NavigationContext.QueryString.ContainsKey("homeFromPageScore"))
6: {
7: NavigationService.RemoveBackEntry();
8: NavigationService.RemoveBackEntry();
9: NavigationService.RemoveBackEntry();
10: NavigationService.RemoveBackEntry();
11: }
12: }
With this workaround, you clean the navigation stack as many times as necessary (neither too much nor too little...). In my case, I'm sure on the number of time I have to remove an element in the navigation stack and the behaviour requested by Microsoft is respected.
