Proposal: Allow Mvvm's ObservableObject's PropertyChanged event to fire on the thread that added the event handler

[gus33000]

Summary

In some cases, mainly UI frameworks, it is required to fire events on the thread that added the event handler. For example, a multi window application may use and reuse the same view model on different User Interface Threads. Updating the UI would require the event to be fired on the correct thread in order to work.

A good example of an UI framework needing this, is Windows.UI.Xaml (details about a proposal to change its behavior here: https://github.com/microsoft/microsoft-ui-xaml/issues/2795)

Details

This functionality cannot be added by an app developer without having to fork the library. Further more, forcing such functionality on every developer could break existing code behaviors, as well as add a performance impact on existing code which isn't needed.

A solution to this problem would be to make the behavior opt in, either by the use of a flag in the class, or by having another distinct class like SynchronizedObservableObject providing this functionality.

The former might require less code changes than the later, but would prevent an app developer from mixing both behaviors at will.

[Updated]

Aside from Windows.UI.Xaml the issue could be happening in other UI frameworks as well. Relying on the UI frameworks to change this behavior will always be the preferred option but unfortunately like in the case of Windows.UI.Xaml, changes may never come to previous versions of the framework that are supported on other platforms.

Further more

Some discussion has happened on this subject on the UWP Community Discord, about this problem and a potential way to solve it, more details here: https://canary.discord.com/channels/372137812037730304/669640275500466197/908427474747158588