Building an MVVM-Based Architecture That Works for Windows Store Apps

Download this episode

Download Video

Description

This session shows how you can set up the architecture for your Windows Store App in a way that works well, both from a development point of view and from a designer point of view. Adopting the MVVM pattern is a step in the right direction, but unforutnately it isn't enough. Getting the most out of the tools requires the architecture to play nice, and working without the support of the tools is hard, so getting the architecture right is paramount.

For more information, check out this course on Microsoft Virtual Academy:

Tags:

Windows, Breakout

Day:

2

Session Type:

Breakout

Code:

DEV-B304

Room:

Room 276

Embed

Format

Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • User profile image
      ericsk

      May I know if it would cover the Blend tool? Thanks.

    • User profile image
      Chris

      Hi Eric!
      No, this talk will unfortunately not cover Blend at all. This is all code and architecture...
      Cheers,
      Chris

    • User profile image
      Stephen_​Cleary

      I enjoyed the session, but I must disagree with your assertion that async/await is more complex than callbacks.

      First, there is an exception in the Task: Task.Exception. Conceptually, the Task<T> type can represent either success or error; it has both a Result and Exception property, which are roughly analogous to the two parameters for your callback.

      Secondly, an implementation of IProgress<T> is already provided (Progress<T>), which you can instantiate with a delegate as such: "new Progress<int>(value => { ... })". In an MVVM app there's no need to create your own.

      Those are the only real drawbacks to async/await that you mentioned. However, async/await also has several advantages over callbacks:

      1. You mentioned one drawback to chains of asynchronous operations: the lambda nesting can get unwieldy. Await avoids this completely.
      2. Another thing you mentioned is that it can be easy to accidentally ignore exceptions in callback code. The Task<T> type prevents this by encapsulating the result.
      3. Await and Progress<T> both use SynchronizationContext automatically in an intelligent way. This makes any kind of thread marshaling or dispatcher service completely unnecessary, cleaning up service/VM code. 
      4. Error handling is easier. With callbacks, exceptions must be propagated explicitly. Await will naturally propagate them, keeping the original exception type and call stack even if the thread context changed. This is quite difficult to do yourself with portable code.
      5. Await makes more complex asynchronous operations much easier to deal with. E.g., retrying on error, or doing multiple operations at once. With callbacks, these kinds of operations quickly become difficult and commonly require actual callback methods instead of lambdas. With async/await (plus TaskEx.WhenAll / TaskEx.WhenAny), they're quite easy to do.

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you canĀ Contact Us.