Correct way to get the CoreDispatcher in a Windows Store app

Question

I'm building a Windows Store app, and I have some code that needs to be posted to the UI thread.

For that, i'd like to retrieve the CoreDispatcher and use it to post the code.

It seems that there are a few ways to do so:

// First way
Windows.ApplicationModel.Core.CoreApplication.GetCurrentView().CoreWindow.Dispatcher;

// Second way
Window.Current.Dispatcher;

I wonder which one is correct? or if both are equivalent?

Both are *kind* of correct, but it will be null if you're not accessing it from something that already *has* access to the Dispatcher. If you want to use it in, say, a ViewModel or Controller, then you'll need to store off the Dispatcher, generally as a static Property in your App.xaml.cs or IOC controller, and set it from the first page that you have load. — Nate Diamond, May 10 '13 at 17:01

score 155 · Accepted Answer · edited Nov 17 '16 at 07:08

155

This is the preferred way:

Windows.ApplicationModel.Core.CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync(CoreDispatcherPriority.Normal,
() =>
{
    // Your UI update code goes here!
});

The advantage this has is that it gets the main CoreApplicationView and so is always available. More details here.

There are two alternatives which you could use.

First alternative

Windows.ApplicationModel.Core.CoreApplication.GetCurrentView().CoreWindow.Dispatcher

This gets the active view for the app, but this will give you null, if no views has been activated. More details here.

Second alternative

Window.Current.Dispatcher

This solution will not work when it's called from another thread as it returns null instead of the UI Dispatcher. More details here.

edited Nov 17 '16 at 07:08

Eriawan Kusumawardhono

4,796
4
46
49

answered Aug 28 '13 at 10:25

MAXE

4,978
2
45
61

I tried this but when I trace the code, the delegate code is still executing on a Worker thread and not the "Main Thread". – Robert Oschler Feb 03 '14 at 17:48
3

Please note that (at least in Windows 8.1) DispatcherPriority is now CoreDispatcherPriority – Illidan Apr 06 '14 at 10:32
2

This would work as long as we have single ASTA (application single-threaded apartment). In case we introduce "sharing target" feature, there are multiple ASTAs (each one with its own dispatcher). And then CoreApplication.MainView can be null (because its ASTA is not initialized yet). Be aware! – Yury Schkatula Nov 23 '17 at 13:06
I have seen CoreApplication.MainView cause my program to hang when called from a non-UI thread. I had to stash the CoreApplication.MainView.CoreWindow.Dispatcher at startup in order to access it later. – sjb-sjb Jan 07 '18 at 06:29
This worked for me in UWP app as long as I used discard operator. _ = Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => someMethod("abc")); – Gregory Bologna Oct 29 '21 at 18:13
1

@GregoryBologna interesting...but I think yours is just a syntax issue...any lamba expression can be used in {} form: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/lambda-expressions – MAXE Nov 02 '21 at 15:02

Brett Pennings · Answer 2 · 2018-05-02T02:42:46.120

16

For anyone using C++/CX

Windows::ApplicationModel::Core::CoreApplication::MainView->CoreWindow->Dispatcher->RunAsync(
    CoreDispatcherPriority::Normal,
    ref new Windows::UI::Core::DispatchedHandler([this]()
{
    // do stuff
}));

edited May 02 '18 at 02:42

answered Jun 07 '16 at 18:29

Brett Pennings

1,489
14
19

1

"For authoring and consuming Windows Runtime APIs using C++, there is C++/WinRT. This is Microsoft's recommended replacement for the Windows Runtime C++ Template Library (WRL) and C++/CX." [C++/WinRT](https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/index) – Richard Chambers May 02 '18 at 14:59

score 2 · Answer 3 · answered Jun 08 '15 at 23:10

2

await CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync(
            CoreDispatcherPriority.Normal,
            () => { // your code should be here});

answered Jun 08 '15 at 23:10

apramc

1,346
1
15
30

score 1 · Answer 4 · answered Dec 11 '19 at 22:57

While this is an old thread, I wanted to draw attention to a possible issue developers may run across which impacted me and made it extremely difficult to debug in large UWP apps. In my case, I refactored the following code from the suggestions above back in 2014 but would occasionally be plagued with the occasional app freezes that were random in nature.

public static class DispatcherHelper
{
    public static Task RunOnUIThreadAsync(Action action)
    {
        return RunOnUIThreadAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, action);
    }

    public static async Task RunOnUIThreadAsync(Windows.UI.Core.CoreDispatcherPriority priority, Action action)
    {
        try
        {
            await returnDispatcher().RunAsync(priority, () =>
            {
                action();
            });
        }
        catch (Exception ex)
        {
            var noawait = ExceptionHandler.HandleException(ex, false);
        }
    }

    private static Windows.UI.Core.CoreDispatcher returnDispatcher()
    {
        return (Windows.UI.Xaml.Window.Current == null) ?
            CoreApplication.MainView.CoreWindow.Dispatcher :
            CoreApplication.GetCurrentView().CoreWindow.Dispatcher;
    }
}

From the above, I had used a static class to allow the calling of the Dispatcher through-out the application - allowing for a single call. For 95% of the time, everything was fine even through QA regression but clients would report an issue every now and then. The solution was to include the call below, not using a static call in the actual pages.

            await Windows.ApplicationModel.Core.CoreApplication.MainView.CoreWindow.Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Normal, () =>
            { 

            });

This is not the case when I need to ensure the UI Thread was called from App.xaml.cs or my Singleton NavigationService which handled pushing/popping on to the stack. The dispatcher apparently was losing track of which UI Thread was called, since each page has it's own UI thread, when the stack had a variety of Messages triggering from the MessageBus.

Hope this helps others that may be impacted and it is also where I think each platform would do a service to their developers by publishing a complete project covering the best practices.

score 0 · Answer 5 · answered Jul 11 '17 at 14:01

Actually, I would propose something in the line of this:

return (Window.Current == null) ? 
    CoreApplication.MainView.CoreWindow.Dispatcher : 
    CoreApplication.GetCurrentView().CoreWindow.Dispatcher

That way, should you have openend another View/Window, you won't get the Dispatchers confused...

This little gem checks whether there is even a Window. If none, use the MainView's Dispatcher. If there is a view, use that one's Dispatcher.

Correct way to get the CoreDispatcher in a Windows Store app

5 Answers5

Linked