Why Deactivated is not the same as Tombstoned

With the transition from the Beta WP7 Dev tools to the RTM, an important and subtle change was introduced to the way launchers and choosers work.  In the beta, it was a given that every time we launched a launcher or chooser from Silverlight, the current application would be tombstoned and the Deactivated event would be thrown on the current PhoneApplicationService object.

With the RTM tools, this is no longer always the case.  Five tasks break this rule: CameraCaptureTask, EmailAddressChooserTask, MediaPlayerLauncher, PhoneNumberChooserTask and PhotoChooserTask.  In each case, while the application may be tombstoned, it also may not be.  In fact, most of the time, it will simply be paused and no tombstoning will occur – the application will not be terminated.  

We can assume that the typical workflow for a chooser task is the following (the images below demonstrate the PhoneChooserTask in action):

phonechooserback

A user performs an action that initiates a task.  The task window opens. The user either completes the task (in this case by selecting a contact) or presses the Back button to cancel the action.  The user is returned to the previous page.  In this case, it makes sense that no termination occurs.  Instead, the app is left in a Paused state much as an app is paused during incoming and outgoing calls – timers are suspended, no events are handled.

[Note: in the RTM, no event is fired when an application goes into a paused state.  At best, you can handle RootFrame.Obscured and RootFrame.Unobscured for incoming and outgoing calls.]

However, the user may also decide to press the Start button at the third step.   At that point it makes sense for termination to occur as it is less likely that the user will backpress back to the app.phonenumberchooser

So when should we handle the deactivated event for the second case where the user moves on and doesn’t complete a chooser task?  We actually can’t handle it when tombstoning occurs because our app is paused and will not respond to any events.

Instead, the PhoneNavigationService.Deactivated event is fired when chooser task (or MediaPlayerTask) is initiated.  This despite the fact that we don’t know (and can’t know) at this point whether the app will actually be tombstoned.

So far so good.  We may unnecessarily be writing objects to storage if the app isn’t ever tombstoned, but it’s better to be safe than sorry.

What is peculiar is that when we return to the app – either through the first scenario above or through the second deviant scenario – PhoneNavigationService.Activated is always thrown.  There’s a symmetry to this.  If the Deactivated event is called and we back into the application, then the Activated event will be called. 

The somewhat annoying thing is that the PhoneApplicationService should have enough information to avoid firing false Activated events unnecessarily.

No matter.  There is a simple trick for finding out whether an Activated event is real or fake – whether it truly follows a tombstoning of the application or is simply thrown because Deactivated was previously called.

Use a flag to find out if the App class was newed up.  It only gets newed up in two situations – when the application is first launched and when it is recovering from tombstoning.  Set the flag to false after the App class has finished loading.  If a chooser is launched and the application is paused but not tombstoned, the flag will still be false.  If tombstoning occurs, the flag will be reset to true.

private bool _isNewApp = true;

private void Application_Launching(object sender
    , LaunchingEventArgs e)
{
    _isNewApp = false;
}

private void Application_Activated(object sender
    , ActivatedEventArgs e)
{
    if (_isNewApp == true)
    {
        // a real tombstone event occurred
        // restore state
    }
    _isNewApp = false;
}

If you are handling tombstoning at the page level, you can similarly use a flag to determine whether the page was re-newed or not.

bool _isNewPage = true;

public MainPage()
{
    InitializeComponent();
}

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    if (_isNewPage)
    {
        //restore state
    }
    _isNewPage = false;
}

The important thing to remember, though, is that the Deactivated / Activated events are not synonymous with tombstoning.  They simply occur alongside of tombstoning – and in the special cases described above occur when no tombstoning happens at all.

Back-Chaining in WP7

Customizing App.xaml.cs

The Windows Phone 7 navigation system has certain limitations from a development perspective.  Chief among these are an inability to inspect the navigation backstack, an inability to remove items from the backstack, and an inability to navigate multiple pages on the backstack.

Because we are only able to programmatically back-navigate one page at a time, a technique has been devised in the developer community called back-chaining.  Back-chaining simply involves setting certain flags in your pages so that, if anyone ever backs into the page, it will continue to navigate backwards.  In this way, we can chain several back navigations together until we arrive at the page we want to stop at.

Here is a basic implementation that forces any back-navigation to always return to the first page in an application when this code is placed in every PhoneApplicationPage:

bool done;

protected override void OnNavigatedTo(
        NavigationEventArgs e)
{
    if (done && NavigationService.CanGoBack)
        NavigationService.GoBack();
}

protected override void OnNavigatedFrom(
    System.Windows.Navigation.NavigationEventArgs e)
{
    done = true;
}

Instead of repeating this code in every page, however, we can centralize it in the App class.  Additionally, we can provide extra methods for more complex navigation such as going back a certain number of pages or going back to a particular page wherever it is on the backstack.

We can do all of this from the App class because of an event on the PhoneApplicationFrame called Navigated that allows us to centrally hook into every navigation event in our applications.

In the default Windows Phone Application template, the PhoneApplicationFrame is instantiated in the App.InitializePhoneApplication method in the App.xaml.cs file.  We can declare our new handler for the event somewhere in there:

//boilerplate code
RootFrame.Navigated += CompleteInitializePhoneApplication;
//new code
RootFrame.Navigated += RootFrame_Navigated;

Next, we need to create some infrastructure code.  For convenience, we want to use static methods and properties in order to make our methods accessible off of the App class.  App.Current, which can be called from anywhere in your application, will return an Application type, which is the base class for App.  Consequently, to access the App class’s RootFrame property (which is boilerplate if you use one of the default project templates), you have to write code like this:

var rootFrame = ((App)App.Current).RootFrame;

A static member of the App class, on the other hand, can conveniently be called like this:

App.DoSomething();

Because we are spreading logic between several page navigations and consequently several calls to RootFrame_Navigated, our infrastructure will need to keep track of what we are trying to accomplish between all of these navigations.

The current implementation will include five methods for back navigation, a simple GoBack, GoBack for a number of pages, GoBack to a named page, GoBack to the first page, and GoBack past the first page.  The last is equivalent to exiting the application (it also doesn’t work, by the way, and I’ll talk more about that later).

Here is the implementation for the first back navigation — which is simply a standard one page back navigation placed in a more convenient place – as well as a property to expose CanGoBack:

public static void GoBack(string pageName)
{
    CurrentMode = GoBackMode.BackToPage;
    BackPageStop = pageName;
    GoBack();
}

private static bool CanGoBack
{
    get
    {
        var navFrame = App.Current.RootVisual
            as PhoneApplicationFrame;
        return navFrame.CanGoBack;
    }
}

GoBack can now be called from anywhere in a Silverlight application like this:

App.GoBack();

Our infrastructure code also requires an enum to keep track of these navigation types:

private enum GoBackMode
{
    Default = 0,
    BackNumberOfPages,
    BackToPage,
    Home,
    Quit
}

private static GoBackMode CurrentMode 
{ get; set; }

To implement going back a given number of pages, we will create a static property to track how many pages we need to go back and expose a method to start the GoBack chain:

private static int GoBackPageCount
{ get; set;}

public static void GoBack(int numberOfPages)
{
    CurrentMode = GoBackMode.BackNumberOfPages;
    GoBackPageCount = numberOfPages;
    GoBack();
}

The magic is what happens in the RootFrame_Navigated method, which is triggered every time we arrive at a new page in the application.  We check to see how many pages we have traversed through the backstack.  If we have gone far enough, we stop.  If not, we call App.GoBack():

static void RootFrame_Navigated(object sender
    , NavigationEventArgs e)
{
    switch (CurrentMode)
    {
        case GoBackMode.BackNumberOfPages:
            if (CanGoBack && --GoBackPageCount > 0)
            {
                GoBack();
            }
            else
                CurrentMode = GoBackMode.Default;
            break;

The setup code for going back to a named page tracks the targeted page name rather than the number of pages traversed:

private static string BackPageStop
{ get; set;}
public static void GoBack(string pageName)
{
    CurrentMode = GoBackMode.BackToPage;
    BackPageStop = pageName;
    GoBack();
}

The code fragment in the switch statement in RootFrame_Navigated parses the name of the page we have arrived at (e.Content returns the full class name along with its namespace but does not return the “.xaml” extension) and then compares it against the page we are trying to reach:

case GoBackMode.BackToPage:
    var pageName = e.Content.ToString();
    var periodPosition = pageName.LastIndexOf(".");
    if (periodPosition > -1)
        pageName = pageName.Substring(periodPosition + 1);
    if (CanGoBack && pageName != BackPageStop)
        GoBack();
    else
        CurrentMode = GoBackMode.Default;
    break;

The syntax for returning to MyPhoneApplication.Page1.xaml looks like this:

    App.GoBack("Page1");

If there are multiple instances of Page1 on the backstack, this implementation will stop at the last one.  If Page1 does not exist on the backstack, the routine will not stop until it finds the first page of the application.

GoHome is fairly straightforward.  It continues stepping backwards until the CanGoBack property returns false.  CanGoBack returns false on the first page of the application but returns true for every other page:

public static void GoHome()
{
    CurrentMode = GoBackMode.Home;
    GoBack();
}
    case GoBackMode.Home:
        if (CanGoBack)
            GoBack();
        else
            CurrentMode = GoBackMode.Default;
        break;

Finally, it would be really nice to be able to implement a Quit method.  Hypothetically, we could just navigate past the first page of an application to exit.  Taking advantage of the infrastructure we have written, the code would look like this:

public static void Quit()
{
    CurrentMode = GoBackMode.Quit;
    GoBack();
}
    case GoBackMode.Quit:
        GoBack();
        break;

Sadly, however, this doesn’t work. We cannot programmatically back navigate past the first page of an application.  When we try, the navigation is automatically cancelled and a NavigationFailed error is thrown. 

Since back-chaining as an exit strategy does not work, an alternative way to exit a Silverlight application is outlined here: How to Quit a WP7 Silverlight Application .  Unfortunately, the marketplace guidelines say that an application cannot have unhandled exceptions.  I’m not currently clear on whether this would apply to throwing an exception that is understood an controlled (hence handled) but at the same time intentional.

A word of caution:  Back-chaining causes flickering, and the more pages you navigate through, the worse the flickering gets.  This is because every page tries to display itself as you navigate past it.   A quick fix for the flickering problem is to set the RootFrame’s Opacity property to zero when you begin and complex back navigation and then set it back to one when you complete the navigation [thanks go to Richard Woo for pointing this out to me.]

For copy/paste convenience, here is the entire back-chaining code base:

RootFrame.Navigated += RootFrame_Navigated;
#region go back methods

private enum GoBackMode
{
    Default = 0,
    BackNumberOfPages,
    BackToPage,
    Home,
    Quit
}

private static GoBackMode CurrentMode 
{ get; set; }

public static void GoBack()
{
    var navFrame = App.Current.RootVisual
        as PhoneApplicationFrame;
    navFrame.GoBack();
}

private static void ShowRootFrame(bool show)
{
    var navFrame = App.Current.RootVisual
        as PhoneApplicationFrame;
    if (show)
        navFrame.Opacity = 1;
    else
        navFrame.Opacity = 0;
}

private static int GoBackPageCount
{ get; set;}

public static void GoBack(int numberOfPages)
{
    CurrentMode = GoBackMode.BackNumberOfPages;
    GoBackPageCount = numberOfPages;
    ShowRootFrame(false);
    GoBack();
}

private static string BackPageStop
{
    get;
    set;
}
public static void GoBack(string pageName)
{
    CurrentMode = GoBackMode.BackToPage;
    BackPageStop = pageName;
    ShowRootFrame(false);
    GoBack();
}

private static bool CanGoBack
{
    get
    {
        var navFrame = App.Current.RootVisual
            as PhoneApplicationFrame;
        return navFrame.CanGoBack;
    }
}

public static void GoHome()
{
    CurrentMode = GoBackMode.Home;
    ShowRootFrame(false);
    GoBack();
}

public static void Quit()
{
    CurrentMode = GoBackMode.Quit;
    ShowRootFrame(false);
    GoBack();
}

static void RootFrame_Navigated(object sender
    , NavigationEventArgs e)
{
switch (CurrentMode)
{
    case GoBackMode.BackNumberOfPages:
        if (--GoBackPageCount > 0 && CanGoBack)
        {
            GoBack();
        }
        else
        {
            ShowRootFrame(true);
            CurrentMode = GoBackMode.Default;
        }
        break;
    
    case GoBackMode.Home:
        if (CanGoBack)
            GoBack();
        else
        {
            ShowRootFrame(true);
            CurrentMode = GoBackMode.Default;
        }
    break;
    case GoBackMode.BackToPage:
        var pageName = e.Content.ToString();
        var periodPosition = pageName.LastIndexOf(".");
        if (periodPosition > -1)
            pageName = pageName.Substring(periodPosition + 1);
        if (CanGoBack && pageName != BackPageStop)
            GoBack();
        else
        {
            ShowRootFrame(true);
            CurrentMode = GoBackMode.Default;
        }
        break;
    case GoBackMode.Quit:
        GoBack();
        break;

    }
}

#endregion

20, 50, 90, 400 and 2

the-count

There are certain numbers every Windows Phone developer should be familiar with: 20, 50, 90, 400, and 2.

20 MB is the maximum size of a XAP file that can be downloaded over the air.  XAPs larger than this must use Wi-Fi or the Zune desktop app to be downloaded to a device.

50 MB is the maximum size of additional content that can be downloaded after installation to make the application functional.  If more than 50 MB is needed to make the application functional, this must be noted in the marketplace submission and a notification should be provided to the end-user of the fact.

90 MB is the memory usage limit for your app assuming the device has the min-spec 256 MB of RAM.  Of course, another way to look at this is that Windows Phone 7 reserves 166 MB of RAM for itself – your app can use the rest.  If the device has 512 MB of RAM, then your app gets 256 + 90.

400 MB is the max allowable size for your XAP. 

2 Gigs is the total size your app can grow to.  This includes the XAP as well as any data you throw into isolated storage — though some people have proposed that the 2 Gig limit applies only to isolated storage usage.  (If you check the isolated storage quota programmatically, it appears to be unlimited which, obviously, isn’t the case). 

The 2 Gig limit seems to have been lifted.  To read more about this, see the old MSDN forums.