A small note upfront: this blog post does not contain catchy images or videos, but it is truly worth reading! Try to hang in there, or if you don’t care about any memory leaks in your app, this is the time to leave.
You have probably heard about weak events before. This blog post is not about the issue of the cause of weak events, there are lots of articles about that. This article is about the solution to it. Shortly said, when you do this in every class (just for the sake of explaining the problem, don’t start thinking this code has no business value):
1: var log = Log.Instance;
2: log.LogReceived += OnLogReceived;
As you can see, the log is a singleton, so there is only one living instance of the Log class. It will probably live as long as the app itself. Now you might be thinking: what’s wrong with this code? Nothing, until the app starts growing and growing and your users start complaining about memory issues.
What happens here is that you subscribe to the LogReceived event of the Log class. This subscription contains 2 things:
- What class do I need to call (null for static, otherwise the instance of the class)
- What method do I need to call
So, in fact now the Log class knows about the instance of the class that just subscribed to it and holds a reference to it (how else can it deliver the event, if it doesn’t know the address). Thus, the classes that subscribe to the Log and that do no unsubscribe will never be collected by the garbage collection.
I truly hope you understand the issue. If not, I recommend to read this excellent article, it dives into the issue a bit better.
Previous attempts
Lots of people tried to solve the puzzle before. So I thought it would be pretty easy to find a class that could help me use weak events for WPF, Silverlight and Windows Phone 7. However, none of them actually worked or supported all the scenarios I had in mind. Below are a few articles I wrote before I started writing my own weak event handler:
The closest one is the first, which uses the Silverlight toolkit implementation and improved it. However, it requires the developer to use static event handlers. Say that again? Only static event handlers? 99 % of my handlers are not static! So, I started tweaking the solution until I found out I completely rewrote it.
The golden grail
So, I think I found the golden grail, just like the others before me. You might be thinking: oh no, not again. But just wait and see, and maybe I can convince you just in time to improve the memory management of your app!
You can find the full code attached at the bottom of this blog post (including unit tests!), but here are the most important parts.
Open instance delegates
The key feature behind this implementation of the weak event pattern is open instance delegates. You are probably wondering: what the hell are open instance delegates? Well, good question, and I will try to explain it. An open instance delegate is just as a regular delegate, it points to the method of a specific class, but the biggest difference is that it does not bind to a specific instance. This means that it can be described as: I know you live on that street (method), but I have not clue in which city (instance) that is. The instance can be specified later. The delegate for a regular event handler looks like this:
1: public delegate void OpenInstanceHandler(TTarget @this, object sender, TEventArgs e);
The @this is nothing special, it allows us to use the this keyword so everyone knows that the target should be passed there. As you can see, it contains 3 parameters. The first one is the target (the city), the second and third parameters are the parameters of the regular event handler.
Weak references
The weak event listener creates an open instance delegate and stores both the source and target in a WeakReference class. As soon as one of these references are no longer valid, the class is unbound. The good side of this approach is that this weak event listener does not leak when the event never fires.
So, what can it handle?
The following use cases are supported:
- Instance source (event) and instance target (handler)
- Static source (event) and instance target (handler)
- Instance source (event) and static target (handler)
So, actually it handles everything that can cause a memory leak via event subscriptions!
Quality assured!
Well, as far as I can guarantee the quality. I wrote the code with care and wrote several unit tests to make sure that all situations I could think of succeed:
So, what can’t it handle and what are the downsides?
This weak event listener follows the rules of the .NET framework. So, it cannot subscribe to private events. If you want private events, do your own hacking (the source is available, you only have to change the DefaultEventBindingFlags at the top of the class).
There are a few downsides about using a weak event listeners in general:
- It’s notation is ugly, the “original” .NET way looks way better
- You have to name the event by string, that sucks (if you know a better way, contact me!)
- It can only handle events with a handler of EventHandler<TEventArgs>
- You become a lazy developer not caring about subscriptions
Enough! Show me how to use it!
I like to distinguish event subscriptions into 4 categories, all described below.
Instance to instance
This is the situation where an instance target subscribes to an instance event. The events are unbound as soon as either the target or source are collected.
1: var source = new EventSource();
2: var listener = new EventListener();
3:
4: var weakEventListener = WeakEventListener<EventListener, EventSource, EventArgs>.SubscribeToWeakEvent(listener, source, "PublicEvent", listener.OnPublicEvent);
Instance to static
This is the situation where a static target subscribes to an instance event. The events are unbound as soon as the source is collected.
1: var source = new EventSource();
2:
3: var weakEventListener = WeakEventListener<EventListener, EventSource, EventArgs>.SubscribeToWeakEvent(null, source, "PublicEvent", EventListener.OnEventStaticHandler);
Static to instance
This is the situation where an instance target subscribes to a static event. The events are unbound as soon as the target is collected.
1: var listener = new EventListener();
2:
3: var weakEventListener = WeakEventListener<EventListener, EventSource, EventArgs>.SubscribeToWeakEvent(listener, null, "StaticEvent", listener.OnPublicEvent);
Static to static
This is not supported because you shouldn’t be using a weak event listener here. Static events with static event handlers simply cannot cause memory leaks because both the source and the target have no instance. However, it might be possible that you subscribe to an event too many times and the event fires too many times. But again, no memory issues here.
Oh… one more thing
Please, promise me that when you use this class, you won’t scatter it all over the place. In fact, I truly believe the best way to prevent memory leaks is to know what you are doing and unsubscribe when you are not longer interested in an object.
Only when you have no idea about the lifetime of a specific object, I recommend to use weak events.
WeakEventListener.zip (14.49 kb) [Downloads: 68]
Subscribe