{"id":1468,"date":"2014-11-05T20:57:10","date_gmt":"2014-11-05T19:57:10","guid":{"rendered":"http:\/\/doena-journal.net\/en\/?p=1468"},"modified":"2021-09-27T15:44:13","modified_gmt":"2021-09-27T13:44:13","slug":"wpf-mvvm-responsive-ui","status":"publish","type":"post","link":"http:\/\/doena-journal.net\/en\/1468\/wpf-mvvm-responsive-ui","title":{"rendered":"WPF: MVVM & Responsive UI"},"content":{"rendered":"

Deutsche Version<\/a><\/p>\n

A few days ago I wrote about my first tumbling steps into the world of WPF & MVVM<\/a>.<\/p>\n

Now a friend of mine – who’s been working in that very field – has challlenged me:<\/p>\n

a) My GUI should remain responsive while the merge is being executed.<\/p>\n

b) I should not re-evaluate the entire GUi after every single user action.<\/p>\n

<\/p>\n

These two challenges have very real-world reasons. The user doesn’t like to have the feeling the program hung up. That’s why you’re supposed to write an UI that tells the user: “No, I did not crash, I’m just not done yet!”.<\/p>\n

And the second one is something that’s just not noticable on small demo apps such as this one but becomes a problem with bigger GUI: The evaluation of every control after every action can cost a lot of time and performance.<\/p>\n

Both can be summarized under the acronym UX which stands for “User eXperience”.<\/p>\n

OK, it’s relatively easy to solve challenge a) with the Task Library that comes with .Net Framework 4.5. And even before that you would have simply used a BackgroundWorker thread.gel\u00f6st.<\/p>\n

But once you moved a job into a background thread you suddenly have a problem that wasn’t there before: The user can suddenly continue to use the program and click the same button twice before the first task is completed.<\/p>\n

Now you have to think about what the user is allowed to do while the task is still running. Fortunately, in my case that’s really simple: Nothing. The UI shall just not appear frozen while the task is working.<\/p>\n

To deliberately prolong the running time of the task, I added a sleep of 5 seconds in the model so one can actually see something happening. Otherwise the mode stays the same in comparison to the first implementation.<\/p>\n

In the ZIP file linked below you’ll find the code change to use a Task in MVVM_responsive.<\/p>\n

Opposed to many other examples you’ll find on the internet, you shouldn’t use Task.Factory.StartNew() unless you have really good reasons for it. Just use Task.Run() instead. “>Here is explained why.<\/a><\/p>\n

You also need to consider the fact that we’re now working in a multi-threaded environment. So we should carefully encapsulate our access to the UI. Thankfully we already interface’d all accesses in the previous implementation. Check out the changes in UIServicesWPF.cs.<\/p>\n

But now for part b) of the challenge.<\/p>\n

If you steer away from the global CommandManager you’re once again responsible to determine dependencies between controls and their values and states and to update them.<\/p>\n

In my case the merge button shall only be active if the text boxes are filled in. I.e the state of Button.Enabled is dependent on the value of TextBox.Text.<\/p>\n

In MVVM_NoRequery and MVVM_NoRequery_alternate I’ve shown two ways to do it.<\/p>\n

As always, the complexity depends on how many controls are dependent on each other in how many ways.<\/p>\n

The solution for bigger and more complex ViewModels is shown on StackOverflow<\/a>.<\/p>\n

MVVM_responsive.zip<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Deutsche Version A few days ago I wrote about my first tumbling steps into the world of WPF & MVVM. Now a friend of mine…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,870],"tags":[1454,1453,1730,1729],"class_list":["post-1468","post","type-post","status-publish","format-standard","hentry","category-misc","category-software","tag-net","tag-c","tag-mvvm","tag-wpf"],"_links":{"self":[{"href":"http:\/\/doena-journal.net\/en\/wp-json\/wp\/v2\/posts\/1468","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/doena-journal.net\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/doena-journal.net\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/doena-journal.net\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/doena-journal.net\/en\/wp-json\/wp\/v2\/comments?post=1468"}],"version-history":[{"count":8,"href":"http:\/\/doena-journal.net\/en\/wp-json\/wp\/v2\/posts\/1468\/revisions"}],"predecessor-version":[{"id":1478,"href":"http:\/\/doena-journal.net\/en\/wp-json\/wp\/v2\/posts\/1468\/revisions\/1478"}],"wp:attachment":[{"href":"http:\/\/doena-journal.net\/en\/wp-json\/wp\/v2\/media?parent=1468"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/doena-journal.net\/en\/wp-json\/wp\/v2\/categories?post=1468"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/doena-journal.net\/en\/wp-json\/wp\/v2\/tags?post=1468"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}