A few weeks ago I received an email from Michael Aird with a question about the way MadProps.MvvmLight uses the Dispatcher. He had some hairy issues around testing a Silverlight app, and asked if I might instead be able to use the SynchronizationContext class as a way to dispatch events back to the primary thread.
After some back-and-forth, Michael discovered that there's an easy way to get around the problem, and that's to use MVVM Light's DispatcherHelper class. That abstracts all the nastiness away.
I discussed the idea with Brendan, who (if you remember) contributed to the project recently, and we decided to give it a shot.
As a result, MadProps.MvvmLight's
ActivitiyProcessor class no longer accepts a
Dispatcher object as a constructor parameter, and instead will always use the
DispatcherHelper class to dispatch back to the UI thread.
There are three things you need to know:
Since we changed a public constructor signature, I have bumped the version up to 2.0.0 even though there are no new features.
Because we're using the DispatcherHelper, you will need to add a reference to GalaSoft.MvvmLight.Extras to your project. If you used NuGet to add MVVM Light, you'll already be referencing it.
Lastly, the DispatcherHelper class needs to be initialized once on the UI thread. That means calling
App.OnStartup()method. For more information, see this post from Laurent.
If, like me, you wire up your application with an inversion-of-control container like Autofac, then you probably won't need to change anything in your app apart from adding the call to initialize the DispatcherHelper.
Lastly, the important links:
Last revised: 06 Oct, 2011 10:52 PM History
- Dew Drop – October 7, 2011 | Alvin Ashcraft's Morning Dew | http://www.alvinashcraft.com/2011/10/07/dew-drop-october-7-2011/
- MadProps.MvvmLight 2.0.0 « Mas-Tool's Favorites | http://mas-tool.com/?p=4417
- rimonabantexcellence site title | http://www.rimonabantexcellence.com/t.php?ahr0cdovl21hdhroyw1pbhrvbi5vcmcvbwfkchjvchmtbxz2bwxpz2h0lti/cmv2axnpb249mg==