Anyone who has been building Silverlight and/or WPF applications for some time understands that there is a single UI thread that has special access requirements if you are going to be updating elements. In other words, if I spin off a new thread, I cannot arbitrarily impact the UI unless I get back to the UI thread using a dispatcher.
Fortunately, Silverlight makes it very easy to find your dispatcher, because it is a property on any UIElement that exists, including your own user control. If I need to make sure a thread executes on the UI thread, I simply do something like this:
this.Dispatcher.BeginInvoke(()=>MyFunc());
Things get a little more tricky if you are trying to access the dispatcher from an entity that doesn’t know about the UI thread … for example, a view model.
Let’s say you have a view model that needs to kick of a separate thread to do some work, and then update properties that are bound to the UI. By design, the view model interacts with services and exposes properties but it doesn’t know about the view. We could sell out by giving it a Dispatcher property, but that could get ugly in scenarios such as unit tests where there simply may not be a UI thread.
Once again I’m happy to go back to the C# keywords that make our lives easier. In the past, I would have simply raised an event, “I need this” and passed some arguments, but with Action at our fingertips, it’s so much easier!
In fact, this is all it really takes … note the use of an action that takes a, um, ahem, action:
public class ViewModel
{
public Action<Action> UIAction { get; set; }
public ViewModel()
{
UIAction = ((uiAction)=>uiAction());
}
}
Seems fairly simple, doesn’t it? Any time I am going to update one of my databound properties in a disconncted thread, I simply do this:
UIAction(()=>{ viewModel.Property = "New value";});
Right now, this isn’t doing anything really interesting, because the action delegate simply calls the action we pass … very boring, really. It will pass unit tests and all of that jazz … so why’d I do it?
Because, once I bring the view model into an actual view, then I’ll need to give it the dispatcher. Then, I can do something like this:
ViewModel viewModel = new ViewModel(); this.DataContext = viewModel; // or bind it with MEF to make it more fun viewModel.UIAction = ((uiAction) => Dispatcher.BeginInvoke(()=>uiAction()));
Now we’ve set it up so that when you call the action with an action, the action is to perform the action inside the dispatcher thread (got all that?). Now the view model plays equally well in the view and out of the view. It is still ignorant of what the view is or even that there is a dispatcher, and only needs to know that updating protected properties should be wrapped in the UIAction.
Let’s save the argument over whether we should even be spinning threads from the view model that modify the UI thread for another day, mmmmm kay?
Take advantage of our free assessment and Azure credits.
We understand that evolving your IT can be costly.
We are offering you a unique opportunity to save you money and get you started faster.
Get $2,500 Azure Credits and a Free Architecture Roadmap
Get up to 5 hours of architecture work and $2,500 worth of Azure credits, free of charge.
Assess and Migrate Your Existing Environment
We right-size your systems and move them into an optimized environment.
Improve Your Information Security and Compliance
We work closely with your team to develop the right roadmap.
Atmosera cited by Gartner as a Representative Vendor in the Market Guide for Cloud Service Providers to Healthcare Delivery Organizations
We help healthcare solution providers make the most of the cloud.
We are a Gold certified Microsoft Azure service provider offering a comprehensive set of managed services.
We excel at working with care providers and their ecosystem of solution providers.
We Know Healthcare
We are fortunate to count a number of leading care providers and healthcare vendors as our customers. We continue to grow this segment as companies turn to secure and compliant cloud solutions.
Collaborate with Experts
- Plan out your cloud strategy without having to commit all your applications to the public cloud
- Microsoft has the only viable hybrid strategy and expected to surpass AWS in market share by 2019.
- We specialize in engineering, deploying and operating the right solution for your business by combining public and private Azure.
- As one of the world’s five largest Microsoft cloud solution providers (CSP), we help you identify the optimal environment to run each application including your database and storage.
Migrate Environments
- We have expertise which minimizes redevelopment to move applications and data without recoding.
- We leverage Microsoft Azure Site Recovery (ASR) which provides a simple way to move applications and data without having to redevelop the underlying cloud infrastructure.
- We implement your new environment on a public or private cloud depending on your preferences and business requirements.
- We enable access to complete and accurate PHI for better medical care.