Asynchronous Programming in Silverlight

Many developers new to Silverlight are surprised to find that an asynchronous programming model is enforced for all network communications. It doesn't matter which API you are using (WCF, Sockets, WebRequest, etc.), only asynchronous versions of those APIs are available. Why? Traditionally, browser-based plug-ins and technologies have had a poor reputation with end users, often perceived as being unresponsive and unstable. By enforcing an asynchronous programming model for all network communications Microsoft have ensured that common network issues such as a slow connection cannot cause the browser itself to become unresponsive.

How does this affect me?

The asynchronous network programming model imposes a significant architectural constraint on your applications, changing the way you approach many development activities such as UX design, state management, error handling, and testing. As developer you will need to learn new patterns and practices, and leverage new libraries such as Microsoft Reactive Extensions for .NET (Rx).

How can iMeta help me?

iMeta are committed contributors within the community, and have released an open source framework for easing the burden of many common asynchronous programming tasks. We also offer training, consultancy and bespoke solutions. Here are a few of the most common Asynchronous programming related areas we have helped our customers with:

• Framework Adoption (e.g. Microsoft Rx, iMeta.Threading)
• Testing Asynchronous Code (Microsoft CHESS)
• Asynchronous Patterns (Event-based, IAsyncResult, Task)
• UI Integration Patterns (Synchronisation, State Management)