One of the most important things in mobile application developer is management of the page stack. You can give your user all the fancy glitzy effects you want but, at the end of the day, like and website your ease of navigation is tremendously important. Users will want to go back and will not take kindly to going to pages that are unnecessary or redundant.
I do this in Android all the time with login pages. When my app first starts, if I don’t detect any kind of pre-existing authentication, I ask the user to log in. When the user initiates the login task, I place the request on a separate thread and use a progress dialog control to hold the user on the login screen until the operation. Often you would see something like this in the result code:
1: private void completeLoginOperation(String token) {
2: myPreferences().setAuthToken(token);
3: myPreferences().setStoredUsername(txtUsername.getText().toString());
4: startActivity(new Intent(this, MainActivity.class));
5: finish();
6: }
On the last line we call the method finish(). What this does is kill the activity. What does this mean? This activity will be “finished” and removed from the stack. Hitting back immediately after arriving on MainActivity will cause the application to exit.
This is a very nice, clean effect and will allow the application to function as the user expects. One of the important tips for getting the effect to work properly is to pick the start up screen correctly. In the case of the application above I used a “splash screen” which made the determination which pages to go to on the start. You could have also done the check, in Login, just remember to do it on a separate thread and inform the user what is happening, otherwise you will get ANRed.
This same principle is vital in Windows Phone 7 as well. However, the application development model differs considerably from Android. Where as Android feels like an application, WP7 tends to feels like developing a website.
Since all WP7 apps are required to have a splash screen, you can do most of the load in App.xaml. I am still trying to work out how you could navigate to a certain page from App.xaml. For now, make your startup page your login screen. Use the Loaded event in your login page to check if the application is authenticated. If it is, redirect to your main page. In this way you are preventing the login screen from ever being displayed if the application is authenticated.
Windows Phone 7 states in its design requirements that Silverlight application are not permitted to exit programmatically. To kill an application the user must either hit the ‘Start’ button or hit ‘Back’ when no other pages exist in the stack. While this makes sense, it is somewhat of nuisance is you are coming from an environment like Android. Nevertheless, with the release of Mango an additional API call was added to allow manipulation of the back stack.
For each page in my application, I inherit from a common base class. Any page that requires authentication, I derive from this common base to support authentication checks. This was a common pattern I used when developing web applications so as not to duplicate the security check on each page. The code for the security check is below:
1: protected override void OnNavigatedTo(NavigationEventArgs e)
2: {
3: // if the user is not authenticated, send them back for authentication
4: if (!CurrentContext.IsAuthenticated)
5: NavigationService.Navigate("/Visual/Login.xaml");
6:
7: // if the user has just come from Login
8: // remove it from the stack so they dont hit when pressing back
9: var entry = NavigationService.BackStack.FirstOrDefault();
10: if (entry != null && entry.Source.OriginalString.Contains("Login"))
11: NavigationService.RemoveBackEntry();
12: }
The logic here is, if the page being displayed is navigated to from the login page, we will call NavigationService.RemoveBackEntry(). This call will remove whatever the last entry in the BackStack is, in this case the login page. This is a new call allowable by the Mango upgrade. In effectively simulates the “finish” from Android, though quite as cleanly.
The end result is the login screen is effectively removed from the stack and is never shown to the user, even though it is the application start page.
I like Windows Phone 7, but you can clearly see the differences between it and a more mature OS like Android. I have confidence, though, that as Microsoft continues to evolve their OS and open more API calls to developers. Right now, it seems they are trying to prevent developers from writing apps that would create problems that damage the experience they are trying to provide. For example, apps that do everything on the UI thread and cause lock ups and freezes. As a more proficient developer my experience causes me to view these sorts of measures as headaches. But I understand their reasons and hope that they lead to wider adoption of the OS.