Projectreunion: Proposal: Allow apps to listen to notification setting changes.

[Felix-Dev]

Summary

Windows 10 native toast notification settings can be changed by the user in the Windows Settings app (i.e. which app is allowed to send notifications). Apps cannot programmatically change this setting. There are still cases though where an app is interested in tracking the current state of notification permissions granted by the user to this app. Currently, the Windows Runtime only provides a ToastNotifier.Setting API which the app needs to actively poll to notice permission changes.

I believe we can do a lot better than this! This proposal will proceed to make the case for introducing an event which apps can register to in order to get notified when notification permissions for the app are changed.

Rationale

In the following, I'll list two example app cases which would benefit from such an event API.

Case 1:
The app in question is an app with a strong focus on user notifications. As such the app developer wants to show the user in the app UI whether notifications for this app are currently enabled or not. The user should not have to open the Windows Settings app just to retrieve this information.

As we can see in the image above the app shows the current status of the notification setting for the app in a status bar at the bottom (and a link to the Settings app to change this setting). Obviously, this information has to be updated whenever the notification permission is changed by the user.

Case 2:
This time, we have an app which provides several types of notifications to the user. The user can opt-in to or out of each type of notification:

Consequently, when the user has denied the app the permission to send notifications, each in-app notification setting should be disabled:

(In this case, the app probably should also inform the user that they first have to grant this app notification permission in Windows itself before they can change the in-app settings.)

As in case 1, the in-app notification settings UI should reflect the current permission state "live". In other words, if the user changes the setting in Windows, the new permission state should be reflected in the UI as soon as possible.

Both apps would benefit a lot if the Windows Runtime would provide an event the apps can listen to in order to get notified whenever they are impacted by a notification permission change. More precisely, the event will be raised when:

• the system-wide notification setting is changed while the specific app notification setting is enabled (if it is disabled, changing the system-wide notification setting won't enable/disable notifications for the app)
• the notification setting for the app listening to the event is changed

API draft

My idea is to add a NotificationSettingChanged event to the ToastNotifier class as it already contains the ToastNotifier.Setting property. The event arguments will be based on the return value of this property which is a NotificationSetting.

/// <summary>Occurs when the notification setting for this app has changed.</summary>
public event TypedEventHandler<ToastNotifier, NotificationSettingChangedEventArgs> NotificationSettingChanged;

The NotificationSettingChangedEventArgs class:

/// <summary>
/// Provides data for the <see cref="ToastNotifier.NotificationSettingChanged"/> event.
/// </summary>
public class NotificationSettingChangedEventArgs : EventArgs
{
    /// <summary>
    /// Create a new instance of the <see cref="NotificationSettingChangedEventArgs"/> class.
    /// </summary>
    /// <param name="setting">The notification setting for this instance.</param>
    public NotificationSettingChangedEventArgs(NotificationSetting setting)
    {
        this.Setting = setting;
    }

    /// <summary>Get the new notification setting.</summary>
    public NotificationSetting Setting { get; }
}

Given this API, no longer do apps have to actively poll the ToastNotifier.Setting proprty in order to provide "live" updates based on the changed settings. Instead, all they have to do is listen to this event. I strongly believe this is a much improved API surface and as a result makes interacting with Windows Settings and thus the UWP app model very easy for developers.

Scope

| Capability | Priority |
| :---------- | :------- |
| Allow developers to register an event handler to be notified by the system when the notification setting for an app has changed. | Must |

Open Questions

Currently none.

[ranjeshj]

@jesbis Can you please route this to the appropriate team ?

[tfennel]

Thanks for the suggestion and well thought out proposal. I've filed this in my team's ADO (we are the notification platform team in Windows). Sorry it's not publicly viewable, but trust me it's in the backlog!

[Felix-Dev]

@tfennel Seeing as Project Reunion is the new home for these types of requests and now also covers on the notification story for UWP and Win32 (see Notification API spec) could this proposal be transferred to the Project Reunion Github repo and be re-opened?

cc @andrewleader @jesbis

[andrewleader]

Transferring this proposal to the Reunion repo sounds good to me! Just an FYI to set expectations, it's unlikely we'd prioritize this anytime soon as we're already going to have our hands full implementing notifications themselves in Reunion first, but we should still get the issue logged so others can add feedback/requests to it!

[DrusTheAxe]

Please add a link to the task via https://task.ms/nnnnn e.g.

Microsoft-internal task 23447728

That enforces appropriate access control but links the github thread with the ADO task for future reference

[hulumane]

This one is interesting. The platform already has internal APIs to listen for Global Settings changes. However, there is nothing for App specific settings. We will need to add support internally in the platform for individual app settings. For downlevel OS's, it is conceivable that our API implementation simply polls user settings when an internal API isn't available for us to use.
Just some thoughts.