- Provide a swift review of available async design patterns.
- Introduce a background threads manager using the nice
Introduction to secretly doing bad things without the UI knowing them
Basically, as MSDN informs us, there are two ways of implementing asynchronous operations:
- Using the
- Using events.
Both of them are design patterns easy to implement. But not long ago, a nice class has been provided to us to please our never ending needs for a less work – more results component. It’s called
BackgroundWorker and it’s cool! It allows you to run operations on separate threads, far from the needy UI.
BackgroundWorker in action
Here are the steps you need to take to use
- Create a
- Set its properties
- Add event handlers to its
- Handle those events.
RunWorkerAsyncwith or without a parameter.
Limitations, as provided by MSDN:
- Do not manipulate any UI object in the
DoWorkevent handler. Do any UI manipulation in the
- Events are not marshaled across AppDomain boundaries.
So why would I need a manager?
Well, it mainly depends on your application’s necessities. If you want to load data from a server and present it to the user, then an implementation of the
BackgroundWorker would be more than welcome. I mean, why over generalize stuff? It does no good for developers. But, what if every action a user performs demands the use of asynchronous calls? I don’t want multiple instances of
BackgroundWorker in my code or other semi-professional implementations of it. So, let’s couple the action I need to perform and the methods that help me succeed in loading, processing, and getting the data to the UI (the asynchronous workflow).
It’s a generic class that is supposed to get an enumeration of actions. For example: