Scheduling of local windows notification not possible?

[true-perfect-code]

Hi WindowsAppSDK-Team

MAUI applications are based on WindowsAppSDK and not on UWP therefore you have to go using Windows App SDK when implementing local Windows notifications.

Apart from the fact that the WinAppSDK documentation on MAUI notification is incomplete (see topic dotnet/maui#27092 (comment) ), it also seems that it is not possible to schedule the notification!

In UWP this is possible via the Schedule method, here is a short example:

                    new ToastContentBuilder()
                        .AddArgument("conversationId", "9813")
                        .AddToastActivationInfo(null, ToastActivationType.Foreground)
                        .AddText(title, hintStyle: AdaptiveTextStyle.Header)
                        .AddText(body, hintStyle: AdaptiveTextStyle.Body)
                        .SetBackgroundActivation()
                        .Schedule((DateTimeOffset)dateTime.Value, t =>
                        {
                            t.ExpirationTime = dateTime.Value.AddDays(1);
                            t.Tag = identifier;
                            t.Group = Shared.Utility.Appl.AppName;
                            t.Id = identifier;
                        });

Have I missed something, or is scheduling really not possible?

If notifications can't be scheduled, what is the point of having UWP transfer them? It really makes no sense to make a notification about windows within the running application, that would confuse the user extremely. A local notification only makes sense if you want to remind the user of something that the user himself has stored in the application (scheduling, alarm, etc.) and usually when his app is not running on the desktop (which will usually be the case).

My code in MAUI Windows currently looks like this:

            var appNotification = new AppNotificationBuilder()
                    .AddArgument("conversationId", "9813")
                    .AddArgument("action", "ToastClick")  // Optional
                    .AddText("Test", new AppNotificationTextProperties().SetMaxLines(1))
                    .AddText("This is a test notification in Windows")
                    .BuildNotification();

            Microsoft.Windows.AppNotifications.AppNotificationManager.Default.Show(appNotification);

It works of course, parameters are passed to Windows and when the app is closed and you click on the notification, the app is opened and the arguments are passed to app. The issue is that the notification sent to Wiondows is displayed here immediately (because of method Show) and this is usually not what you need for a Notification, because you want to display it to the user with a time delay sometime in 5 days (sceduled) when his stored appointment is due.

Regards
pc

[mominshaikhdevs]

I believe this should be filed as a feature request (as a github issue), for that the AppNotificationManager class is incomplete and it needs a shedule method.

[true-perfect-code]

The following part is addressed exclusively to Microsoft and not to the WindowsAppSDK or MAUI team, which is doing a great job in such a difficult situation.

If the AppNotificationManager is really not complete, then I truly wonder how this is possible considering that we don't really have a choice for Windows Desktop development and have to rely on MAUI (or rather are forced by Microsoft to use MAUI):

We only have three ways to develop Windows Desktop applications:

• Winforms
• WPF
• MAUI Windows

Neither winforms nor WPF will be supported from MS, so we are left with MAUI and anyone starting a new project with a customer should actually use MAUI Windows if they want to develop a Windows desktop app exclusively (no mobile, only win desktop). But how is that supposed to work if Microsoft employs so few people and hopes that many will invest their own time here for free?

But what is the reality after 2 years of MAUI release?

The supporting infrastructure (Visual Studio, WindowsAppSDK, Webview etc.) triggers fundamental errors or is incomplete, plus of course MAUI with an extremely high number of errors that are corrected, then return again, because there are simply too few people involved in projects

This local notification in Windows is a point that I have fully implemented on iOS and Android in a few hours.
With Windows, I don't lose days here, but weeks. What always amazes me is that I have found a few posts from people who have the same problem. I really wonder for the first time, is there anyone out there who still uses MAUI or does the MAUI community only consist of MAUI developers and people like me who are annoyed about MAUI problems and burn their own free time here.

I really wonder what Microsoft's plans are, because no one will go productive with MAUI and I was already feeling embarrassed to suggest WPF to customers last year (old technology).

Besides, as far as I know, WindowsAppSDK should be older than MAUI NET (or in other words MAUI NET came after). Didn't they by c-suite microsoft think that everything from UWP should be completely migrated to windows AppSDK before MAUI was released (I say this in reference to the notification problem of scheduling)?

pc

[mominshaikhdevs]

@godlytalias may be able to assist here.

[castorix]

I don't use MAUI (WinUI 3, Windows App SDK 1.6.241114003 on Windows 10) and this works for me in unpackaged desktop apps : https://learn.microsoft.com/en-us/windows/apps/design/shell/tiles-and-notifications/scheduled-toast
(the package is named Microsoft.Toolkit.Uwp.Notifications, but it works without UWP...)

[castorix]

I just added in a WinUI 3 project, at beginning :

ToastNotificationManagerCompat.OnActivated += ToastNotificationManagerCompat_OnActivated;

in a Button click, the code from the doc, with 60 seconds, to have time to close and re-start the app :

   new Microsoft.Toolkit.Uwp.Notifications.ToastContentBuilder()
                  .AddArgument("action", "viewItemsDueToday")
                  .AddText("ASTR 170B1")
                  .AddText("You have 3 items due today!")
                  .Schedule(DateTime.Now.AddSeconds(60));

and OnActivated event :

    private void ToastNotificationManagerCompat_OnActivated(ToastNotificationActivatedEventArgsCompat e)
    {           
        ToastArguments toastArgs = ToastArguments.Parse(e.Argument);
        var nPID = Process.GetCurrentProcess().Id;            
        foreach (var argument in toastArgs)
        {
            Debug.WriteLine($"Toast argument: {argument}", nameof(OnActivated));

            string sString = $"Toast argument: {argument}";
            sString += (" PID = " + nPID.ToString());
            bool isQueued = this.DispatcherQueue.TryEnqueue(Microsoft.UI.Dispatching.DispatcherQueuePriority.Normal, async () =>
            {                    
                Windows.UI.Popups.MessageDialog md = new Windows.UI.Popups.MessageDialog(sString, "Information");
                WinRT.Interop.InitializeWithWindow.Initialize(md, hWndMain);
                _ = await md.ShowAsync();
            });        
        }           
    }

[true-perfect-code]

Hi @castorix

Unfortunately it doesn't work. I tested it when the app was already open, so I was able to set a break point. The e.Argument ist empty!

App.xaml.cs

        public App()
        {
            this.InitializeComponent();

            ToastNotificationManagerCompat.OnActivated += ToastNotificationManagerCompat_OnActivated;
        }

        private void ToastNotificationManagerCompat_OnActivated(ToastNotificationActivatedEventArgsCompat e)
        {
            ToastArguments toastArgs = ToastArguments.Parse(e.Argument);
            foreach (var argument in toastArgs)
            {
                AppLaunchArguments.LaunchArguments += argument.Value;
            }
        }

pc

EDIT:

• The changes are on github
• I also created a package and installed the app locally on my computer, but it doesn't work either.

[MartyIX]

@castorix Does this feature require some special permissions? Perhaps a vanilla WinUI 3 app has different permissions than a MAUI on Windows app.

[castorix]

@castorix Does this feature require some special permissions? Perhaps a vanilla WinUI 3 app has different permissions than a MAUI on Windows app.

I tested in an unpackaged WinUI3 app, which is a standard Win32 app (on Windows 10 22H2)
The limitations I could meet with some other class/interfaces depended on the Manifest file, compatibility section
I used here :

 <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- A list of the Windows versions that this application has been tested on and is
           is designed to work with. Uncomment the appropriate elements and Windows will 
           automatically selected the most compatible environment. -->

      <!-- Windows Vista -->
      <!--<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" />-->

      <!-- Windows 7 -->
      <!--<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" />-->

      <!-- Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />

      <!-- Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />

      <!-- Windows 10 -->
      <maxversiontested Id="10.0.19041.0"/>
	 <!--<maxversiontested Id="10.0.22000.0"/>-->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

    </application>
  </compatibility>

[true-perfect-code]

@MartyIX

As I have understood it in the last few weeks, since I have been working intensively on this problem, it is because MAUI (WinUI 3) no longer has an OnActivated event. Accordingly, the Windows notification start arguments cannot be passed to the MAUI app.

I really don't want to speak badly of anyone, but I wonder what kind of principle Microsoft has when they advocate backwards compatibility but then change the basics in every possible place?
They present a new technology and decide to delete the "OnActivated" event. Easy to do, but it brings with it the same problems as now and I don't know how many programmers who don't use MAUI because the basic thing like planned notification doesn't work after 2 years of MAUI release (and nobody seems to have noticed because nobody uses MAUI productively)!

If you come up with the crazy idea of ​​removing one or other core concepts like OnActivated here, then in my opinion it would make more sense to remove everything and start new from scratch, because when I add up the time I invested in MAUI just to clarify things like this, it far exceeds the time I would need to learn completely new frameworks (maybe all of them already exist).

pc

[whiskhub]

The only thing that will help is creating feature requests in the repo. Here I created such a request: #5050

[true-perfect-code]

Thanks @whiskhub :)

[true-perfect-code]

If anyone wants to try UWP.Notification + MAUI, here is an example project on Github:
https://github.com/true-perfect-code/MauiApp1_UWPNotifications/tree/master

Please note that the planned notification works without any problems in MAUI and that is not a problem. The problem is that we do not get the parameters passed to Windows back from Windows because MAUI no longer has an OnActivated method and UWP needs it.

So the question is how do you read the Windows Notification parameters with UWP Notifications + MAUI when the app is closed and the app is restarted via Windows notification?

pc

[whiskhub]

The main problem is that your MAUI app is unpackaged. That's why the activation isn't working properly. I don't really know how WASDK works with unpackaged apps/what the instructions are there.

But you could switch your MAUI app to MSIX packaged: https://learn.microsoft.com/en-us/dotnet/maui/windows/setup?view=net-maui-9.0#convert-an-unpackaged-net-maui-windows-app-to-packaged

[true-perfect-code]

@whiskhub

Unfortunately it doesn't work with the package and a client installation either. I created the package folder on github (see MauiApp1_UWPNotifications_1.0.11.0_Debug_Test) and uploaded package files to gitHub. Maybe you'll have more luck trying it out.

Note:
MauiApp1_UWPNotifications_1.0.11.0_x64_Debug.msix is ​​>25MB and cannot be uploaded via browser but only via github desktop. Since I don't want to install github desktop, I can't upload the file either, which isn't a big deal because you can also create a release yourself.

pc

[whiskhub]

After a lot of testing, this is the line that causes all arguments to get removed:
.AddToastActivationInfo(null, Microsoft.Toolkit.Uwp.Notifications.ToastActivationType.Foreground)

Remove that and you will get command line arguments.

[true-perfect-code]

It works !!!

I will add your workaround for MAUI to all posts.

pc

[true-perfect-code]

If someone needs scheduled notifications for MAUI, then you have to use UWP.Notifications Nuget (as of January 2025) and there is a workaround from @whiskhub to get the ID sent by Windows. However, we all hope that the WinAppSDK team will implement a complete migration from UWP.Notification to windowsAppSDK so that WinAppSDK can be used for local notification in MAUI (as is also planned by Microsoft)

You can find a working example here: https://github.com/true-perfect-code/MauiApp1_UWPNotifications

pc