Why does the Widget Sample create a duplicate empty instance after a system restart?

The issue you're experiencing with the Weather Widget sample creating a duplicate empty instance after a system restart is likely related to how the widget's state is managed during the lifecycle of the application. Specifically, you need to ensure that the existing widget instances are correctly restored when the system restarts.

To address this, you should implement logic in the WidgetProvider.cs file to check for existing widget instances during the initialization phase. Here are some steps to consider:

1. Initialize Running Widgets: When your widget provider is initialized, use the WidgetManager.GetDefault method to get the default widget manager instance and call GetWidgetInfos. This will return an array of WidgetInfo objects that represent the currently running widgets. You should copy the widget IDs and other relevant state information into your provider's state management structure.
2. Handle Widget Activation: In the Activate method, check if the widget ID already exists in your state management structure. If it does, you should restore the existing instance instead of creating a new one. This will prevent the duplication of the widget.
3. Update Widget State: Ensure that the widget's state is updated correctly when it is activated or when the system state changes. This includes handling any necessary updates to the widget's data or UI based on the current state.

By implementing these changes, you should be able to prevent the duplication of the widget and ensure that the existing instance is resumed correctly after a system restart.

References:

• Implement a widget provider in a C# Windows App
• App instancing with the app lifecycle API

Hello @Ser Fed ,

By all means, the sample was intended to demonstrate a simple implementation of the widget, so it is not fully optimized for user experience. If the widget process or system restarts, your provider will lose track of the widget IDs and their states.

Handling state persistence would increase the complexity of the sample, which is likely why it was not included. However, I understand your point about the user experience.

If you want to manage state for the widget, you can consider implementing local storage or using application settings to save the state when the widget is closed and restore it when it is reopened.

If you want to improve the sample, you could consider reporting to the official GitHub sample repository: https://github.com/microsoft/WindowsAppSDK-Samples/issues.

While this is a non-Microsoft link, it is the official Github repository of Windows App SDK samples.