views:

1621

answers:

2

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?

+7  A: 

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.)

Jon Skeet
How exactly does it get messy?
zvolkov
@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.
Jon Skeet
+5  A: 

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.

Gishu