The application lifecycle for desktop applications is a fairly simplistic flow .   You can be launched or closed.   The system may go to sleep or shutdown, or the user might logout   while you are running.   There could be an unhandled exception.   Really though, most apps just care about launching and terminating.

On Windows Phone, things are a bit different.   The user can launch your application, but they can never directly kill it, and the app can never close by itself.   While your application is running, the user can navigate to different pages, or press hardware buttons to launch the camera, the system search page, or the system Start page.   Unlike the desktop though, if an application isn't in the foreground, it's not running.   If the user presses the camera button - even if the application itself launches the camera - the application will terminate.   It's a very different model, and it takes some getting used to.

The Back-Stack

What makes it challenging, is that there's a hardware back button.   If the user presses the back button after exiting your application, it will reappear.   To the user, it just looks like they switched back to the application, but in reality it's being restarted and expected to return to the exact state in which it was left.   It's all to create the illusion of multitasking.

Windows Phone applications use the concept of application pages - not windows or forms.   Pages can contain controls, including user controls.   In order to move between pages, there is a call to navigate to the appropriate page's xaml.   As the user moves between pages of an application, system search, the start menu, and other applications, they are building up a back-stack, like in a web browser.

Picture it this way:

When the user presses the hardware Back button from the Search page, they expect to be brought back to the application's page 3.   How does this happen though?

Navigation takes place using the NavigationService object:

NavigationService.Navigate(new Uri("/Page3.xaml", UriKind.Relative));

Every application has an entry point which is an implementation of the Application class.   This class has events that fire based on launching, navigating, and more.   A very important thing to remember, is that the first step is the constructor of your Application implementation - by default, the App class.   Your application has around ten seconds to initialize.   While you do this, a splash screen will be shown automatically (SplashScreenImage.jpg).   If you exceed ten seconds, you will be unceremoniously terminated!   Keep things as minimal as possible in the constructor.   Anything more lengthy should be performed in the Launching or Activated events, and ideally delegated to background threads.

Anytime your application is directly launched by the user from its icon, the Launching event will fire.   Anytime the application resumes by the user pressing the back button, the Activated event will fire.   When the user navigates away from the application by using the Camera, Start, or Search buttons, the Deactivated event will fire.   If the user presses Back until the Start screen appears, your application is completely terminated and the Closing event will fire.

Every instance of PhoneApplicationPage has its own events that fire based on what is happening.   When a page is entered, its OnNavigatedTo method is invoked (override it to do something).   When a page is left, the OnNavigatedFrom method is invoked.

protected override void OnNavigatedFrom(NavigationEventArgs e)
{
    base.OnNavigatedFrom(e);
}

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    base.OnNavigatedTo(e);
}

Best practices dictate that you save all relevant state as close to when that state changes, rather than while deactivating or closing.   Since you only have ten seconds to prepare for termination, it's best not to take chances.   Note that the user does not need to wait these ten or so seconds for an application to close.   The requested action occurs right away.   Windows Phone actually places your application in the background for this to happen.   Don't get any ideas though!   There is simply no way to work in any meaningful way while in the background for these few seconds.

If the user presses the hardware Back button and your application is on the back-stack, your application will be started again, but using the events that indicate an activated, rather than a launch.   It's up to you to have state saved that enable you to present a consistent experience to the user so it doesn't look like the app was ever closed.   Here's the full lifecycle of pressing back through the screens from the Search screen: