Porting iOS Apps to Windows 8 (4): Application Lifecycle Differences

Article
11/19/2012

Author: Rafe Wu

Channel 9 https://channel9.msdn.com/Blogs/OneCode/How-to-Port-iOS-apps-to-Windows-Store-apps

Technically speaking, both the iOS and the Windows Store applications allow only one application to execute in the foreground at a time. The foreground application owns the screen and receives the touch events. They both support multitasking and fast application switch. However, the execution model of iOS apps are still slight different from Windows 8 applications.

Multitasking in iOS and Windows Store

With iOS4, it introduced multitasking, with the ability to do fast application switching. When the user clicks the home button, instead of terminating, the currently executing application is put into background running state. In this state, the application is expected to save data. If the user switches back to this application, after using another application, the background application transit to foreground and is made active again, at which time the user can resume where he/she was. Additionally, iOS4 also supports other forms of multitasking, such as task completion or background execution for applications using audio, location or VOIP. This is very similar as Windows 8 scenarios based multitasking

Windows Store applications suspend any invisible processes. The suspended process still stays in the memory but can’t get CPU time unless it gets resumed. It means that by default any task will be stopped if the application is switched out. But we still allow the application to perform actions even when it is not in the foreground. It allows the application to play background audio, transfer files, execute scheduled tasks and notifications such as alarms and reminders without launching the application.

Windows Store Application State Transitions

Following graph illustrates the transitions between app execution states. When you click the tile of an application, the application is activated from “not running” state to “running” state. Then the application exclusively owns the entire screen. The application will suspend when the user switches away from it and resume when the user switches back to it. Once the suspend event is fired, your app has 5 seconds to store off state. In the suspend mode, your main thread of execution is suspended but the app is still held in memory. The user may come back to your app shortly, and then the thread is resumed and the state that you stored is never used. But, at some point, Windows may have too many saved applications in the memory and need to terminate a process. If your app is terminated, then you can use the state that you stored to restore your app to the way it was when it was terminated on the next time it runs.

Figure: Windows Store Application Life Cycle

Life Cycle of a Windows Store Application

The following events take place during the life cycle of a Windows Store application. Windows Store application developer needs to take appropriate actions in response to each of these events:

Suspend

In general, Windows Store applications stop running when the user switches to another app. Windows suspends your app when it is not in the foreground. When your app is suspended, it is frozen in memory. It can’t run in this state, but Windows can instantly resume it when the user returns to it. In this way, Windows gives the foreground app better use of system resources and ensures apps in the background can’t drain the user’s battery.

When your app moves out of the foreground, Windows waits for a few seconds to allow quick switching back to the app, then tries to suspend the app. Your app must be registered for the suspending or checkpoint (JavaScript) events, which it receives when Windows wants to suspend it. This is an important time for your app; use this opportunity to save app data that must be kept in persistent storage. Usually, your app is resumed as is, and you won’t need your persisted data because they are still in memory. But you need to store this data in case Windows terminates your app to free system resources. Save enough app data to bring users back to the place in your app where they were when the app was suspended. This way, your customers perceive your app as always alive and running.

If your app doesn’t return from its suspending event handler within 5 seconds of receiving the suspending event, Windows will terminate it. It’s important not to do any heavy operations in your suspending event handler. Save your app data and return quickly.

Resume

When your app is resumed, it continues from the state that it was in when Windows suspended it. To be specific: app data and state are kept in memory while the app is suspended, so when it’s resumed, everything is as it was when the app was suspended. You don’t need to restore any saved data explicitly when receiving the resuming event.

But you want your app to appear to be always alive. For this, it has to be connected and display the latest data. It is possible that your app stays in a suspended state for quite a long time before it is resumed. Data or network connections could become stale and may need to be refreshed when your app resumes. When a user brings your app back to the foreground, your app receives a resuming event. You can refresh the app content and reconnect network resources when your app receives this event.

Activation

Activation is all about how your app gets launched. It serves many purposes in a Windows Store app. Windows can terminate your app after it has been suspended for a number of reasons. For example, the user manually closes your app, or signs out, or the system is running low on resources (some apps, such as games, can be pretty resource intensive!). If the user launches your app after Windows terminated it, it receives an activated event and the user sees your app’s splash screen until the app is activated. You can use this event to determine whether your app needs to restore the data it saved when it was last suspended, or if you must load your app’s default data.

Comparing Life-cycle Methods

The table provides mapping between iOS callbacks/delegates and Windows Store application events related to the application lifecycle. For example, applicationDidEnterBackground that is called when the app is in background in iOS should be replaced with Application.Susending event handler to save app state. applicationWillEnterForeground should be replaced with Application.Resuming event handler.

Please note, some Delegates are not directly mapped to Windows 8 events. For example, applicationWillResignActive happened when the foreground app is interrupted. On the other hand, applicationDidBecomeActive will be called if user ignores interruption. We don’t have the replacement in Windows 8 for these 2 delegates because you can handle these events in Suspending and Resuming events as well.

Summary

In this chapter we had a look at the different states of application life cycle in iOS and Windows 8. We also compared methods for saving application state data in iOS and Windows 8.