Share via

How to ensure your toast notifications continue to work when converting your win32 app into a Windows Store app using project Centennial

  • Article

Note that if you follow the guidance in the latest documentation for desktop toasts , you don't need to worry about any of this. The compat library takes care of the differences between Centennial and classic Win32.

As you may already know, developer can now bring their existing apps and games to the Windows Store with the Desktop Bridge, known as project Centennial.

For developers who has been integrating with toast notification features in Windows 8 and Windows 10, when you turn your app into a Windows Store app using project Centennial, you may realize that your toast notification does not work as desired - an incorrect/unresolved string will show up in Action Center at where the application title is supposed to be shown. This post summarizes on why it happens and how to fix it with a simple change to your code.

Why does it break?

In Windows 8/8.1, we enabled support for desktop Win32 apps to send local toast notifications – by enabling win32 apps to do 2 things:

  • be able to register with the notification platform and;
  • call WinRT APIs to send toast.

What did we do to enable those respectively?

  • A registration with notification platform requires an app identity, but win32 apps don’t really have modern app identities. This problem is solved by by allowing win32 apps to provide us with a "fake" app identity – through creating a desktop shortcut.

  • The app will then need to call the method overload that takes this manually created application id to indicate which identity is trying to send this notification, as shown:

     ToastNotificationManager.CreateToastNotifier(appId).Show(toast);

Windows Store apps converted through project Centennial on the other side, already come with proper app identities just like any regular UWP app, so if the win32 app is converted without changing any of its previous code, then it will create a conflict as below:

  • The shortcut creation will be skipped for the converted Store app during app deployment because the deployment path is different, however;
  • The app will still call the same overload mentioned above to pass in the fake app id that the OS can no longer resolve, since the shortcut is not there, thus results in unresolved string.

How to fix it?

Any app in this situation will need to simply change a line of their code to call

 ToastNotificationManager.CreateToastNotifier().Show(toast);

without passing in the manually created appId and just let the app identity get resolved by the OS like any other modern apps do.

Why didn't we fix this for you?

The same method overload can also be used by Windows Store apps to send toast notifications on behalf of other apps in the same package. Once a win32 app is converted to Windows Store app through project Centennial, Windows just see it as a regular Store app without knowing its true intention behind calling CreateToastNotifier(appId). To prevent us from getting your real intention wrong and further break some other unexpected scenarios, we ask the developers to make the change here during your conversion process.

Comments

  • Anonymous
    December 30, 2016
    Was this written by an 8 year old or a guy in India? This post has tons of grammatical problems. Also, this doesn't even work. Was this even tested?
    • Anonymous
      January 12, 2017
      @Andrew Barns Hi Andrew, the post was published in rush after we discovered the issue so apologize for the grammar mistakes, I can definitely update the post to fix them. The feature is tested and a few Centennial apps do use toast notifications now. Could you please elaborate on what doesn't work for you?
  • Anonymous
    January 13, 2017
    How can you detect if you are a Centennial app or not at run-time?