Avalonia: Native notifications

[pr8x]

So the native OS notification PR (#3389) is currently on halt due to unclear requirements. I would like to get back to developing on it, but we first need to resolve some questions:

• How should the public API look like? Where should notifications live? How should we identify notifications (for instance when receiving an close/dismiss event)?
• How should the application be registered with the OS? On Windows (10) it's required to install a shortcut that is associated with the "AppUserModelID" of the application. On OSX it's required to install a bundle identifier. In both scenarios we need a way for the user to provide input for this registration process.
• Where should the NativeNotificationManger live? @kekekeks argued that it should be on the TopLevel. I recall that @grokys did not really like this (?).
• What about Windows8/8.1? They both seem to have (partial) support for the ToastNotificationAPI but supporting Windows 10 is certainly easier due to the convenient Microsoft.Windows.SDK.Contracts package.

We should probably figure out the application registration before everything else. Also instead of making a giant PR with all platform support we should start slow with Windows (10) support and ship other OS one-by-one.

Any thoughts?

[kekekeks]

The first thing we should do is to gather info on how notifications work in various OS (including mobile ones). We can't design the API otherwise.

Notifications are either persistent and survive the app restart (most notification APIs) or ephemeral (Linux). The way the system delivers action events (e. g. when notification is clicked) is also different, OSX delivers though app-wide events, Windows has ToastNotification.Activated. It's unclear to me how ToastNotification.Activated gets delivered after app got restarted.

So I suppose that notification events will have to be routed through Application class.

[pr8x]

Activated does not get delivered after a restart. You can however provide this launch attribute in the Toast XML which will be passed to the Application.OnLaunched event once the App was started. That way you can uniquely identify which notification was activated. On both OSX and Windows the notification event handling has to be global somehow and we probably can't subscribe to them with delegates as we cannot serialize them. So we probably need the user to supply a unique ID for the notification types he sends. That id stays stable even after a restart and can be used to match notifications in a global event. We just have to be sure to raise this global event after the user application finished building.

[pr8x]

I am also thinking the public API should not be async. We could use Dispatcher.InvokeAsync in the DBUS implementation to handle the asynchronous service calls.

[kekekeks]

Fire-and-forget approach leads to swallowed exceptions.
Why is everyone so obsessed with sync APIs? You aren't writing winforms code in 2002 anymore.
Anything outside of plain computations is asynchronous in its nature. Writing to disk? Async. Network? Async. GPU rendering? Async. IPC? Async. Communications with the window server? Yes, you've guessed it, they are async too. Some systems try to hide those async APIs behind sync facades which leads to numerous issues like app freeze when attempting to access clipboard.

[workgroupengineering]

Fire-and-forget approach leads to swallowed exceptions.
Why is everyone so obsessed with sync APIs? You aren't writing winforms code in 2002 anymore.
Anything outside of plain computations is asynchronous in its nature. Writing to disk? Async. Network? Async. GPU rendering? Async. IPC? Async. Communications with the window server? Yes, you've guess it, they are async too. Some systems try to hide those async APIs behind sync facades with leads to numerous issue like app freeze when attempting to access clipboard.

Because it simplifies long method calls which would freeze the UI and give the user the impression that the app has crashed.

[maxkatz6]

There is a bit information how notifications work in Windows: https://github.com/microsoft/ProjectReunion/issues/137

[mstr2]

It seems to me that system notifications are quite independent of any UI framework. Maybe such a feature would be better implemented as a third-party library instead?

[pr8x]

@mstr2 Yeah. That could be an option as well. @grokys @kekekeks @MarchingCube What do you guys think? Should native notifications be part of the core framework or shipped as part of a external library?