What is the "Weak Event" pattern used in WPF applications?

Question

The WindowsBase DLL defines the IWeakEventListener event with summary:

Provides event listening support for classes that expect to receive events through the WeakEvent pattern and a System.Windows.WeakEventManager.

This vague description doesn't describe what the 'WeakEvent pattern' actually is.

So, what is this pattern, why is it used and is it useful outside of WPF applications?

EDIT Some good answers already, but no one has talked about whether this pattern is useful outside of WPF applications. It seems to me that the weak event pattern, like dependency properties, is inextricably linked to the WPF APIs and DLLs. Is there an equivalent implementation available for non-WPF applications?

Alcibiades

I would think weak references is a more generalized approach to the problem and can be used outside of WPF. It seems like the WeakEventManager is a specialized case of weak references for WPF event handling. – Exhaustive

Answer 1

The important bit is in the remarks:

The principal reason for following the WeakEvent pattern is when the event source has an object lifetime that is potentially independent of the event listeners. Using the central event dispatching of a WeakEventManager allows the listener's handlers to be garbage collected even if the source object persists

So if you have publisher and subscriber objects, then normally after subscriber has subscribed to publisher's event, subscriber can't be garbage collected. The weak event pattern makes the link between the two "weak" (as in WeakReference) so that there isn't this dependency. (The alternative is to unsubscribe from the event when subscriber wants to become eligible for garbage collection, but that gets messy.)

Mithridate

How exactly does it get messy? – Josefina

@zvolkov: Because suddenly the subscriber needs to know when it wants to become eligible for garbage collection, which can often end up with extra knowledge propagating all round the system, and suddenly you've lost half the benefit of automatic garbage collection. – Mithridate

Agreed, unsubscribing handlers do get messy. But, there must be some overhead with "WeakReference" also! The least I can think of is the extra work that GC needs to do to reset the weak reference object to null when the object is removed from memory. – Fiery

so for example, does this mean that when i subscribe to a window's location changed event, I need to use the weak event pattern or the objects in it can't be garbage collected until the window is GC? – Building

@JamesJoshuaStreet: Well, or you need to manually unsubscribe at an appropriate time, yes. – Mithridate

Answer 2

In .NET 4.5, there's improved support for establishing a weak reference to an event.

Instead of

source.Event += OnEvent;

You can use the new WeakEventManager<TEventSource, TEventArgs>:

WeakEventManager<EventSource, EventArgs>.AddHandler(source, "Event", OnEvent);

Read more here.

Hadley

Answer 3

WeakEvent Patterns

Subscribing to events can result in the subscribers being not collected. You'd assume that the object would be collected as you're holding no other reference to it - However the event publisher holds onto the listener object and keeps it in memory (unless it explicitly unsubscribes, in which case you need to know exactly when to unsubscribe). A managed leak.

As a thumb rule, if the event publisher is going to hang around for longer than the listener, you can run into this issue and should check this out.

WeakEvents should help you out here in that the object would be collected if the only active references to it are 'Weak'. You should be concerned with this pattern only if you plan to develop new controls, which usually expose lots of events.

The basic idea is similar to WeakReference w.r.t. garbage collection.

Africander