Also if currently you are probably running Windows 8 on a virtual machine or luckily on a computer, there is not any doubt that this new operating system and especially the metro-style interface is dedicated to touch enabled devices like tablets. The plans of Microsoft infact include the new WOA keywork where the acronym stands for Windows On ARM that is the aim of making available this interface on a wide set of mobile devices that currently embrace this successful processor architecture.
Running on a tablet does not only imply a different input interface like the touch screen, but also it requires a careful use of system resources that are not always large on this kind of device. This is the reason why metro-style applications have an application lifecycle that is mostly similar to the Windows Phone than of classical desktop apps.
It is matter of life or suspension
As a user, when you start a desktop application, you are exactly aware of the boundaries of its life. You click the icon and the application starts, then you use it and finally you hit the close button and the application closes. There are nothing behind this common process but you, as the final user, are responsible to decide how many applications runs at the same time so the management of system resources is completely up to you. Also if the previous sentence oversimplifies the matter, since behind the scenes the operating system manages system resources in an optimal way, if you continue to open a number of apps, at a given point you reach the maximum of resources available and you get an error.
From the metro point of view, this scenario completely changes. The only thing you are exactly aware is the time when you start your application the very first time after you switched on your device, and from this point the lifetime of the application is completely up to the operating system. You can still choose to close a metro-style app but this is not exactly required nor favored. In metro guidelines is strongly stated that your application must not have a "close button" or such a way to close the application, under the penalty of failure of the certification for the marketplace. If the user choose to close the app he has to use a combination of ALT+F4 or the close gesture (swipe the screen from the top to the bottom). The most common way to go away from the current app is by pressing the start button that brings you to the start screen but this not really close the app.
The rule is really simple: you can always have only one application running. You can hit the maximum of two apps running at the same time, only in a few cases, when one is snapped and the other runs as filled. In all the other states Windows only allows a single application to run, so probably this is the most common scenario. What it happens behind the scenes is that when you start an application it get its own space in terms of system resources and becomes the current running application, but when you hit start and move to another one, the application you are leaving is "suspended". This means the OS saves the current execution state and prevent the processor from continue to execute it; in this state the application resides in memory and continue to allocate the space assigned to it but it does not currently run.
To become aware of this process you can do a simple exercise using the Task Manager. First of all go to desktop and open the new Task Manager. Then activate the "Show suspended status" item in the View menu. 
This let you see when an application enters the suspended state. Now return to the start screen and activate some applications. Finally you have to return to desktop by pressing the WindowsKey+D and watch at the task manager. The situation you will see is almost similar to the one in the figure on the side where you have a number of apps in suspended state and a single that results to be running. But waiting 10 seconds also last application enters the suspended state. Windows works in a smart way. When the user leave an application it waits a few before to switch it to suspended because there is a chance the user returns to the application immediately. After 10 seconds passed, the operating system move the app to the suspended state but does not remove it from the memory. This enable the user to switch rapidly from an app to another since Windows only need to activate and deactivate the app without loading it from the disk.
This works fine until the systems has lot of resources. But obviously if you continue to run new apps, you reach a moment when the system needs to free some space to ensure a good feedback to the user. In this case Windows can decide to terminate some of the applications that are currently suspended. After the app has been terminated all the resources are freed and Windows can only starts it again from scratch.
The developer point of view
Since the process I described above may seems completely automatic, there are some points that a developer must know to improve the feedback of the application. After you created your application, it works also if you do anything about the lifetime management. The problem is that, especially in the case of termination, you have to take a decision about the experience you want for your user. If you do not handle this situation what the user will see it that randomly the application suddenly is reset and he loses the work he is doing. Windows is really careful in handling termination of the apps but when it finally goes on this way only the intervention of your code can save a situation that differently is like a complete shutdown.
To handle termination you have to act subtly. When Windows decide for the termination, it immediately releases all the resources without waiting nor notifying the application. As a developer the termination is completely transparent and when it happens it is too late to do anything. Differently you may assume that the termination happens only when the application has been suspended so the best it to act during suspension to save the state of the work as if the application is being terminated.
Starting to speak about code, the Application type is all what you need to handle this situation. As you know the App class defined in App.xaml.cs directly inherits from Application. So in this class you can attach some events to detect state changes:
OnLaunched: it is called every time the application is activated. This event, only available as override, happens when the application start from scratch on the first run or after being terminated. Remember that from the point of view of the operating system both these scenario are identical. The difference comes from the value of PreviousExecutionState you get in the arguments. This may be "NotRunning" or "Terminated".
Suspending: This event may be subscribed to get notified about the suspension of the application. You have to be aware that, when this even has been called you only have a few seconds to act to preserve the current state of the application. If you take long than 5 seconds Windows will assume that the application has crashed so terminate it.
Resuming: The resuming event is raised only when the application is reactivated after being suspended. Pay attention that resuming does not happen if the application is terminated.
OnActivated: This event is raised when the application is not activated normally. Since the normal activation raises OnLaunched, in other cases (a search, share, etc...) this event is called and you can user the ActivationKind enumeration to understand the reason. Also be aware of a number of methods that are specific to a single activation reason: OnSearchActivated, OnShareTargetActivatedm etc...
Reading carefully the events meaning, it becomes clear that there is two points where you have to handle the suspension. The first is the Suspending event. In this event you have to save the current state (loaded documents, fields, position of elements and so on...) to a persistent storage. The ApplicationData store is perfect for this purpose:
1: public App()
2: {
3: InitializeComponent();
4: this.Suspending += new SuspendingEventHandler(OnSuspending);
5: }
6:
7: protected void OnSuspending(object sender, SuspendingEventArgs args)
8: {
9: SuspendingDeferral deferral = null;
10:
11: try
12: {
13: deferral = args.SuspendingOperation.GetDeferral();
14:
15: // save here the application state
16: }
17: finally
18: {
19: deferral.Complete();
20: }
21: }
Thanks to the SuspendingDeferral instance, returned by the call to SuspendingOperation.GetDeferral, you can inform the runtime that the application is saving its data. Then the call to the Completed method confirm that the application is ready to be suspended. The use of the deferral does not give you additional time. The limit of 5 seconds is still valid.
When the application is resumed without being terminated you have nothing to do. In this case the situation is completely handled by Windows. So you have only the responsibility of handle the OnLaunched event an check if the app has been restored by a terminations instead fo begin started from scratch:
1: protected override void OnLaunched(LaunchActivatedEventArgs args)
2: {
3: var rootFrame = new Frame();
4: this.EnsureInitialized(rootFrame, args);
5: rootFrame.Navigate(typeof(MainPageView));
6: }
7:
8: private void EnsureInitialized(Frame rootFrame, IActivatedEventArgs args)
9: {
10: if (args.PreviousExecutionState == ApplicationExecutionState.Terminated)
11: {
12: // restore the state here
13: }
14:
15: Window.Current.Content = rootFrame;
16: Window.Current.Activate();
17: }
Thanks to the IActivatedEventArgs interface the EnsureInitialized method can be used also in case of different activations. As an example, if th app is started by a Search request, you need to threat the application state like in the case it starts normally. You can write the following code:
1: protected override void OnSearchActivated(SearchActivatedEventArgs args)
2: {
3: var rootFrame = new Frame();
4: this.EnsureInitialized(rootFrame, args);
5: rootFrame.Navigate(typeof(SearchGridPageView), args.QueryText);
6: }
Now the point is: how can I persist the state? The right place is the application data store. This store is mostly known as IsolatedStorage in Silverlight and Windows Phone. For metro-style apps this storage has a number of additional features but for now it suffice you know that it can receive your files as a normal filesystem restricted to your app only. For this purpose the best is searching the SDK examples. In most of the XAML examples there is a SuspensionManager class that already implements all you need to save the application state. The important part using this class is to ensure the data you need do store is serializable using the DataContractSerializer. This means to decorate the classes with DataContractAttribute and DataMemberAttribute.
1: [DataContract]
2: public class ApplicationState
3: {
4: [DataMember]
5: public int Number { get; set; }
6: [DataMember]
7: public string Name { get; set; }
8: }
Then you have to add the types to the KnownTypes collection:
1: public App()
2: {
3: this.InitializeComponent();
4: this.Suspending += OnSuspending;
5:
6: SuspensionManager.KnownTypes.Add(typeof(ApplicationState));
7: }
At this point you have to manage to save the state to the SuspensionManager and reload these information when it is required. It is important you avoid to restore the state if you are in the case of a fresh start because the guidelines express indicate it as a worst practice. Instead you have to handle the start from a termination:
1: private void BlankPage_Loaded(object sender, RoutedEventArgs e)
2: {
3: if (SuspensionManager.SessionState.ContainsKey("State"))
4: {
5: ApplicationState state = SuspensionManager.SessionState["State"] as ApplicationState;
6:
7: if (state != null)
8: {
9: this.theName.Text = state.Name;
10: this.theNumber.Text = state.Number.ToString();
11: }
12: }
13: }
14:
15: private void OkButton_Click(object sender, RoutedEventArgs e)
16: {
17: SuspensionManager.SessionState["State"] = new ApplicationState
18: {
19: Name = this.theName.Text,
20: Number = int.Parse(this.theNumber.Text)
21: };
22: }
Finally you have to add the SaveAsync and LoadAsync method calls to the Suspending and OnLaunched events. This methods use the DataContractSerializer to serialize and deserialize the SuspensionManager content and use the Aplication data store to persist it as a file.
Debugging suspension
If you try to observe the lifecycle of an application that is running in debug mode, you will understand that under these conditions there is something different. When an application is debugged it is never suspended, so it is hard to debug the suspension and resume phases. For this purpose in Visual Studio 11 there is a small toolbar useful for this purpose. These buttons can simulate suspension and termination of the application and in this case your breakpoins are honored.
The suspension and resume in Windows 8 is important to give a better experience to the user, thaks to the optimization of the system resources. In the next article in the series I will write about another arpect that has the same direction: the asyncronicity and how to deal with it.