There are lots of things that take a long time - a politician's apology, dance recitals, and sometimes C# operations. if you don’t want your UI to freeze during these operations, it is important to make them asynchronous.
Option 1: The Event Pattern
In the code above, look at MyLongActivity(). It’s not really a long activity, I just make it sleep for 5 seconds to simulate a long process. Now look at StartProcess(). StartProcess() is a wrapper that lets us call MyLongActivity() asynchronously. It starts MyLongActivity() on a background thread, then release control back to the caller.
See that BackgoundWorker? This is a great control. 1) It is available across every device and framework (making your implementations more consistent), 2) it is very simple to use, 3) it completes on the UI thread. That last part kills most developers.
Remember: we execute asynchronously on a non-UI thread so the UI continues moving. But, we can’t touch the UI thread from this background thread. If we try, we get this!:
First, the BackgroundWorker makes “returning to the UI thread” moot – it does it for you. But what if you want to anyway? Serious?! You nerds always want the details, don’t you? Okay. In Silverlight, we do this with the Dispatcher’s BeginInvoke() method:
Practice Safe Threading
Option 2: Callback PatternI am starting to like this pattern best. There are no events with callbacks. When the async operation is complete the callback is invoked. Since a callback is simply a method, your after-it’s-done logic is nicely packaged there (yes, like the completed event handler).
However, using a callback means you don’t have to differentiate multiple completed events with a user state object. When a callback is invoked, the context is known and sure. The only drawback is that it is somewhat more complex, at first. Only at first:
In the code above, just look how much less code there is and how much more control you get over the context. See Callback()? That method is invoked at the end of the async operation. There are no events, no event arguments. Just simple methods.
ConclusionYou must choose an asynchronous strategy. Silverlight requires it for resource requests and your users will require it for a good experience. My preference is starting to be the callback pattern, but I have used the event pattern for years. You have to pick one. Well, no you don't. You can use them both. Best of luck!