Closed sidevesh closed 2 years ago
It looks like the string that is there in place of app name is actually the AUMID of the app.
@azchohfi would you have any pointers on why this issue is happening ? I went through the relevant Microsoft documentation on this, seems like this issue could happen if a shortcut isn't added to Start with the AUMID, but is for Win32 apps I think and msix apps don't create the shortcuts themselves so that doesn't seem relevant. Also went through source code for the notification plugins as well as your PR adding toast support but with my very limited Windows development knowledge I couldn't figure it out.
@andrewleader could you please advise on what can possibly be happening here?
Ok, I've spoken with @andrewleader, and he told me that the reason this is likely happening is because both libs are using the ToastNotificationManager.CreateToastNotifier with the AUMID, and not the version without parameters of this method, which is what should be used with packaged apps (in the vast majority of cases).
The Windows Community Toolkit implements the required logic to detect if an app is packaged or unpackaged, to call the proper API (but it is all C#, not C++): https://github.com/CommunityToolkit/WindowsCommunityToolkit/blob/3bf88b8e6ea1e30b4bb027d3128345446aea141e/Microsoft.Toolkit.Uwp.Notifications/Toasts/Compat/Desktop/DesktopBridgeHelpers.cs
On Andrew's words: "HasIdentity: True if MSIX or sparse packaged app (if you want to support sparse packaged apps, that throws another layer of complexity onto it) IsContainerized: True only if MSIX packaged (false for sparse and unpackaged) For most cases, all you need to care about is HasIdentity... For deciding whether to use the overloaded method... HasIdentity true = CreateToastNotifier() HasIdentity false = CreateToastNotifier(myAumid)"
I hope this helps.
To summarize, the issue opened here is not an issue on @YehudaKremer's MSIX package, but a misunderstanding of the respective APIs that each of the reported libraries are calling.
Hey @azchohfi , Thanks for helping debug this and as it turns out that does solve the issue for both the libraries. Although after the change I have noticed another issue which wasn't happening before. If I click on the notification, it ends up creating a new window, which wasn't the case before and this happens with both the libraries.
Hey @azchohfi , Thanks for helping debug this and as it turns out that does solve the issue for both the libraries. Although after the change I have noticed another issue which wasn't happening before. If I click on the notification, it ends up creating a new window, which wasn't the case before and this happens with both the libraries.
:information_source: Info
Version:
v3.4.0
:speech_balloon: App name on notifications from msix packaged version is incorrect
The name of the app on notifications seems to be some combination of app identifier, publisher name and some random code, this happens with both win_toast https://github.com/MixinNetwork/flutter-plugins/issues/64 as well as WIP Windows support of flutter_local_notifications
Initially I thought
win_toast
isn't working because its meant for Win32 apps and not msix packaged apps but looks like that's not the case since the same thing happens withflutter_local_notifications
' WIP implementation too.My msix config is:
:scroll: Pubspec.yaml