Prism Event Aggregator Subscription Blues

After too many hours of debugging and hair-pulling, I finally figured out why my Prism EventAggregator (EA) subscriptions were not working in an important case. The reason made perfect sense ... once understood.

Here is the setup.

• I have a CustomerOrders module to manage viewing and editing of one Customer and its Orders.
• I have another module, CustomerSearch, in which the user searches for Customers.
• The two modules are de-coupled.
• The CustomerOrders module learns about which Customer to show when CustomerSearch publishes the SelectedCustomerEvent.
• The CustomerOrders module will not display itself until it hears the first SelectedCustomerEvent.

This is a canonical example of cross-module Eventing, perfect for Prism's EventAggregator.

Here is the subscription in the CustomerOrders module:

  _eventAggregator.GetEvent<CustomerSelectedEvent>()
     .Subscribe(NotifyView);

But the subscription is never raised and NotifyView is never called! The CustomerOrders module is instantiated alright but it never shows a Customer.

Maybe I didn't publish correctly. So I try subscribing inside some other class that I'm sure is in-use ... such as a class in CustomerSearch itself.

  _eventAggregator.GetEvent<CustomerSelectedEvent>()
    .Subscribe(HeardIt);


  ...
  public void HeardIt(object dummy) { 
    var sink = "I heard you";
  }

Put a breakpoint on HeardIt; works like a charm.

I break at the point where I'm adding subscriptions to CustomerSelectedEvent; they are all there! I can see both subscriptions in the CustomerSelectedEvent's list of subscriptions.

After a few frustrating hours, I happen to look at _eventAggregator subscriptions when HeardIt is called. Now there is only one, the one for HeardIt. The CustomerOrders subscription is gone!

Then I remember, EventAggregator holds weak references to subscriptions by default ... so the subscriber doesn't have to unsubscribe when it is disposed or garbage collected (GC'd). This is a very cool feature. Sadly, I immediately suspect that this is the source of my problem. To test that thesis, I force the subscription to use strong references.

  const bool keepAlive = true;
  _eventAggregator.GetEvent<CustomerSelectedEvent>()
    .Subscribe(NotifyView, ThreadOption.UIThread, keepAlive);

It works!

Of course now the instance in which I make this subscription will hang around for the life of the application (the life of the EA to be precise). This is a potential memory leak. If I'm going to make and forget a lot of these instances, I better remember to unsubscribe, perhaps via IDisposable. That doesn't seem like fun.

Why did the subscriber disappear ... taking its subscription with it?

Prism decoupling was just doing its job. Most Prism modules that you will ever create actually disappear rather quickly.

You can verify that thesis. Drop the following in your module class (the inheritor of IModule) and set a breakpoint:

  // Destructor to demo when GC'd
  ~MyModule() {
    System.Console.WriteLine("Goodbye, MyModule");
  }

If your module class is very simple as it should be ... perhaps some type registrations before dropping a view into a region ... you'll see that destructor called in no time; happens almost immediately for me because I'm running in a VM where the garbage collector is very busy.

So my subscription disappeared because I subscribed within a class that itself disappears ... really quickly.

In my example, I was unable to find or construct an instance of a class that outlived the module.

I could have put it inside the View (the ViewModel to be precise); once the View was injected into the visual tree, it would outlive the module because the visual tree would keep it alive. That is why the subscription to "HeardIt" worked in the CustomerSearch module . I  had subscribed inside a ViewModel after it's companion View had been presented. It didn't matter that the CustomerSearch module class instance, which had created that ViewModel, had long since been GC'd.

Unfortunately, I can't follow that example in the CustomerOrders module. Can you see why?

Remember I said at the beginning that the CustomerOrders module waits for the first publication of CustomerSelectedEvent before it shows itself. If I don't show anything, everything I create in that module evaporates (get's GC'd) before the first publication of CustomerSelectedEvent!

I have to do something to keep the module around until it can do its work. I'm sure you can think of plenty of ways; I did. They're mostly ugly. I decided that I should put my solution near the cause of the problem ... and so I ensure that at least one subscription has "keepAlive = true".

I won't worry about the potential memory leak from hanging on to the module class; I don't expect to have more than one instance of this module in the lifetime of this application. I'll just document the issue and move on.

Hope this helps you!

p.s.: No ... I did not actually put this logic in the module class. Module classes are supposed to be bare bones. I put it in a Coordinator class, an instance of which is resolved by the CustomerOrders module. The problem is the same. The coordinator is referenced only by the module so it evaporates when the module does. I thought this detail would only interfere with exposition were it introduced earlier.