Help users resume your app seamlessly after a Windows update

Help users resume your app seamlessly after a Windows update

Windows PCs require a restart to apply each month’s security updates. Today we’re offering tips and best practices that can help you make sure your applications seamlessly resume after a restart and keep your app users happy.

Some users manage Windows updates (and restarts) for themselves. Others prefer that their PCs automatically restart when not in use. In either case, users typically prefer to find their applications exactly as they left them after an update. Their flow on Windows is more productive and fun when apps restore their state, position and pending operations following an update.

What does this mean for you as an application developer? If your app is documentation-focused, you might want to help people remember where in the document they were editing most recently. If your app helps people modify images, consider saving their “undo” stack and/or creating a temporary copy of their workspace. For game developers, it might be helpful to implement a quick “save” and ask players where they would like to resume. Ultimately, your apps can offer seamless continuity following a restart – for updates or otherwise – by following a few best practices:

• Save the user’s state.
• Remember how their previous views were positioned.
• Relaunch the app following the update.

In this post, we will explore native APIs you can use to help you save an app user’s work and resume an app state following a restart.

Universal Windows Platform (UWP) apps

Universal Windows Platform (UWP) provides lifecycle management capabilities to applications. While a UWP app doesn’t need anything special to be restarted and resumed after a system update, it is recommended to save the app states periodically.

Win32 apps

If you are developing a Windows desktop app, you can use the Application Recovery and Restart (ARR) APIs to register your app for restart. Specifically, registering for restart helps applications cleanly close upon system restart and relaunch after restart with pre-defined arguments.

Whether you are building Win32 apps or you’re using Windows app SDK, you can find ARR API usage samples on GitHub.

In addition to registering apps for restart, you should consider how an app can best resume its previous workload and recover the previous state. Common strategies include saving often to disk and providing context to resume state in the arguments used when registering via ARR API. Here is a code example:

// Register for restart with the current value of app text box

RegisterApplicationRestart(counterTextBlock().Text().c_str(), RESTART_NO_PATCH | RESTART_NO_REBOOT);

// Update registration before crash with the new value of the app counter text box

RegisterApplicationRecoveryCallback(APPLICATION_RECOVERY_CALLBACK([](PVOID recoveryData){


     BOOL canceled;

     if (SUCCEEDED(ApplicationRecoveryInProgress(&canceled)) && !canceled)

     {

          const auto counter = static_cast<uint32_t*>(recoveryData);

          RegisterApplicationRestart(to_hstring(*counter).c_str(), RESTART_NO_PATCH | RESTART_NO_REBOOT);

     }

     ApplicationRecoveryFinished(true);

     return (DWORD)0;

     }), &_counter, RECOVERY_DEFAULT_PING_INTERVAL, 0);

.NET apps

Similar to Win32 apps, .NET apps can register for restart by using the ARR APIs. The only difference is using p/Invoke to wrap the native API calls. You can find .NET sample code using ARR APIs on GitHub.

// Best effort to register for crash and hang restart.

RegisterApplicationRestart(_counter.ToString(), REGISTER_APPLICATION_RESTART_FLAGS.RESTART_NO_PATCH | REGISTER_APPLICATION_RESTART_FLAGS.RESTART_NO_REBOOT);

// Best effort to register recovery callback to update restart arguments with the latest seconds counter value.

RegisterApplicationRecoveryCallback(new APPLICATION_RECOVERY_CALLBACK(p =>

{

     ApplicationRecoveryInProgress(out BOOL canceled);

     if (!canceled)

     {

          RegisterApplicationRestart(_counter.ToString(), 
REGISTER_APPLICATION_RESTART_FLAGS.RESTART_NO_PATCH | 
REGISTER_APPLICATION_RESTART_FLAGS.RESTART_NO_REBOOT);

     }

     ApplicationRecoveryFinished(true);

     return 0;

}), null, 5000, 0);

Apps with critical workloads can use power APIs to keep the system running and prevent a restart, but this isn’t permanent. Both users and administrators need devices to stay secure and a system will eventually be forced to restart after an update. Further, keeping the system powered on can drain battery or use excess power.

We encourage you to read more about how to effectively use Power APIs for system services and long-running critical applications.

Share your feedback

Have suggestions or ideas for API improvement? Still have questions about how your app and Windows Update can work together? Please share your thoughts by submitting them via Feedback Hub (Windows key + F)!
Source: Help users resume your app seamlessly after a Windows update