Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

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

Download

Right click “Save as…”

Slides (view online)
+ My Schedule- My Schedule

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:

Follow the Discussion

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

  • ChrisChris

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

  • 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.

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.