User Tools

Site Tools


Lifecycle in UWP

Page Lifecycle

After the page constructor finishes, the page goes through the following events:

  • OnNavigatedTo
  • SizeChanged
  • LayoutUpdated - invoked when elements are added or removed from the visual tree or the layout is changed
  • Loaded - occurs only once during the lifetime of a Page

Every FrameworkElement derivative has a Loaded event. The Loaded events occur in a sequence going up the visual tree, ending with the Page derivative.

Example: Handle the Loaded event using an anonymous method:

public MainPage()
    Loaded += (sender, args) =>
        // ..

App Lifecycle

When a user closes an app, the app suspends and after 10 sec it terminates. On the next launch, you can get the PreviousExecutionState from the LaunchActivatedEventArgs.

                                |             |
                                v             |
NotRunning --> Activated --> Running --> Suspended --> Terminated --> NotRunning
                                |             ^
                                |             |

When your app is activated, Windows shows your app's splash screen. While the splash screen is visible, Windows invokes your app's Main method and runs through all the activation steps. One of the last things your app does after initializing is activate its window by calling Windows.UI.Xaml.Window's Activate method. If your app does not call this method within 15 seconds, the OS terminates your app and returns the user to the Start screen. While the OS gives your app 15 seconds to activate its window, your app must actually activate its window within 5 seconds in order to pass Windows Store certification. So you really should design your app to complete its initialization and activate its window within 5 seconds, not 15 seconds. If your app needs more than 5 seconds to initialize, you can implement an extended splash screen.

The Application base class offers a Resuming event. It is raised when an app is resumed and allows you to refresh data in your app. To find out how long your app was suspended, query the time in the Suspending event and subtract this value from the time obtained in the Resuming event; there might be no need to refresh data if only a small amount of time passed. There is no time restriction placed on the Resuming event's callback method. Many apps do not show real-time data, so they have no need to register with the Resuming event.

The Application base class also offers a Suspending event. It is raised just before an app's threads are suspended and allows you to persist the app's state to a file. Windows gives your app 5 seconds to complete its suspension; if you take longer than this, Windows terminates your app. Although Windows gives you 5 seconds, your suspension must actually complete within 2 seconds to be certified for the Window Store. All you have to do in your suspension code is create a file on disk and serialize your data into it. You'll also need to call your Frame object's GetNavigationState method, which returns a string that has an encoded collection of page history, and serialize this string to the file as well.

If you need more time than 2 seconds to complete your suspension, use the Window's VisibilityChanged event. This event is raised whenever a window becomes visible or invisible. A window always becomes invisible first before the app is suspending and its Suspending event is raised.

While your app is suspended, the OS might terminate it to free up memory for other apps. If the OS chooses to terminate your app, your app is given no additional notification.

Note that the user can close your app by typing Alt+F4, dragging your app's window from the top of the screen to the bottom and holding for a few seconds, or right-clicking your app in the task list and selecting Close. In addition, the OS closes all apps when the user logs off or shuts down the machine.

In all the above scenarios, the OS raises the Window's VisibilityChanged event, followed by the App's Suspending event, giving your app a chance to save its state. However, in the future, when your app is launched, you should not restore your app's state because the user has explicitly taken action to close your app as opposed to the OS implicitly terminating your app. If you check the PreviousExecutionState property, you'll see that in all these scenarios, it returns ApplicationExecutionState.ClosedByUser.

UWP apps are not supposed to close themselves or offer any kind of UI that allows the user to close the app. If your app violates this rule, it will not pass Windows Store certification. The CoreApplication class offers an Exit method and an Exiting event. These members are for use in debug scenarios during app development only. When you submit your app to the Windows Store, your app must not use these members.

Example: Use deferral when writing to a text file in a Suspending event:

Application.Current.Suspending += async (sender, args) =>
    SuspendingDeferral deferral = args.SuspendingOperation.GetDeferral();
    await PathIO.WriteTextAsync("ms-appdata:///local/data.txt", "some text to save");
notes/uwp/lifecycle.txt · Last modified: 2020/08/26 (external edit)