Universal Windows Apps need careful lifecycle management to maximize battery life and memory use

Applications have at least two states in which they are used. They can either be running or not running. For Universal Windows Apps, however, the processes can have a third state: Suspended. The suspended state allows the app to continue running paused in the background while users interact with other content on their devices. While the application is suspended, it goes into a hibernation mode to free up resources and can be recovered without any data lost to the user. When developers don’t utilize these correctly, apps with poor lifecycles can leak memory and use battery unintentionally.

There are multiple ways that an application can be terminated by the user or the device. They can use a gesture or click the x, select an exit option from within the app itself, force it closed via processes or task manager, or it can have an error and crash. But when an app is in suspension and is determined to be using too many resources, it will switch to terminated leaving the user’s data to be completely wiped. Developers s can catch this problem at the pass by handling the Application.Suspending event and overriding the Application.OnLaunched event. Editing these will enable the program to make a temporary save with the user’s data as the program is switched to suspended, and then recovered upon launch.

A recent blog post from the Windows team goes into more detail about the lifecycle of a Universal Windows Application and how developers can alleviate the drain of resources while in Suspended mode. Along with some examples and coding tips, the article gives insight on methods to debug and test your projects. Handling the flags between Suspending and Launched will enable applications not only to conserve battery and memory but will make it easier for users to access their data without even knowing the difference.