backgroundTop
backgroundTop
Front Page
GreenBackgroundTop

Prism Eventing

Eventing in Prism - Loosely Coupled Talking

Prism allows us to have modular and loosely coupled applications, but how do these loosely coupled pieces communicate? That's where Eventing and the EventAggregator come in: they provide communication channels. A way that the separate pieces of the application can safely talk back and forth. Eventing also has extra goodies (thread preference, weak references) that are built on the lessons learned from past technologies (like CAB). All around, it's a great helper for any Silverlight/Prism (or WPF) application.

erikmork

2k Votes

GreenBackgroundBottom
 

Important Code

Mark as Inappropriate Content

This video is licensed under a Creative Commons License.

Creative Commons License Download the Video

Information From the Video

GreenBackgroundTop

Zombie Application

This is an example Silverlight Prism application. It has a bunch of dots representing people who can turn into Zombies, and it has their backing ViewModels. The "Zombies" button is in a separate Region, and is a loosely coupled piece. The idea is that this button will broadcast an event that will trigger the immediate conversion of all non-zombies into zombies.
GreenBackgroundBottom
 
GreenBackgroundTop

Adding the Event Class

Eventing in Prism requires a class that inherits from CompositePresentationEvent<T>. This class is used as a marker. That is, instead of using magic strings to tie publishers and subscribers together, types are used. This means that we get some compile-time verification of events. Interestingly, the classes that we add for events typically don't have implementations. They're simply used as tokens to indicate a kind of event.
GreenBackgroundBottom
    public class TurnIntoZombieEvent : CompositePresentationEvent<bool>
    {

    }
 
GreenBackgroundTop

Publishing an Event with the IEventAggregator

The IEventAggregator is passed into our constructor by Prism. This interface allows us to reach out and access events of interest. In this example, we signal our interest in the TurnIntoZombieEvent. Of course, the aggregator can manage multiple events and even multiple kinds of events (it could, theoretically, handle TurnIntoHumanEvents as well). After we get the event, we're free to either publish or subscribe. In this example, we publish (fire) whenever the button is clicked. This example uses a code-behind file. This is for demonstration purposes. In a shipping application we'd of course use a ViewModel.
GreenBackgroundBottom
        public ZombieButton(IEventAggregator aggregator)
        {
            _aggregator = aggregator;
            InitializeComponent();

            var zombieEvent = _aggregator.GetEvent<TurnIntoZombieEvent>();

            Zombie_Button.Click += (s, e) =>
                {
                    zombieEvent.Publish(true);
                };
        }
 
GreenBackgroundTop

Subscribing to an Event

Subscribing to an event starts out similarly to publishing an event. The first step is to ask the aggregator to give us our zombie event. We do that by passing the TurnIntoZombieEvent class as a token. Once we have the event, we subscribe to it; That is we specify our method that will be called whenever the event is fired. In this case, we're calling a turnIntoZombie method that we'll define in just a moment.
GreenBackgroundBottom
        public PersonVM(IBlankSurface surface, IEventAggregator aggregator)
        {
            _surface = surface;
            IsZombie = false;

            var zombieEvent = aggregator.GetEvent<TurnIntoZombieEvent>();
            zombieEvent.Subscribe(turnIntoZombie);

        }
 
GreenBackgroundTop

Event Callback

In the "Subscribe" call on the event, we specify which method will be called when the event fires. We can take that opportunity to specify that Prism shouldn't use Weak References to track the callbacks. Normally, Prism does use Weak References, and this helps to prevent a very common memory leak (when programmers forget to unwire events). In addition, the Subscribe statement can be used to specify whether the callback should be on the GUI or worker thread. By default, the callback is on the GUI thread. In this example, a "turnIntoZombie" is called which in turn forwards the call to an overload which does the work of changing the Human into a Zombie state.
GreenBackgroundBottom
 //...
//  This method is subscribed by the earlier call:
//zombieEvent.Subscribe(turnIntoZombie);
//...



        public void turnIntoZombie(bool zombify)
        {
            if (zombify == true)
            {
                turnIntoZombie();
            }
        }
 
 
GreenBackgroundTop

References

Silverlight Prism

Video on how to get an application started in Prism. It provides an overview of Modules, Services and Regions.

Modularity in Prism

This video shows how Prism and Unity interact to provide capablities for Dependency Injection and Service Location. It also shows how to use the ModuleCatalog.

Prism Regions

Regions are kind of like Master Pages in Silverlight. This video walks you through how to use Regions to break your application's UI up into usable pieces.

Prism Commanding

How to fire events directly from XAML into the ViewModel. Current thinking holds that this is the best approach for managing complexity and unit testing in an application.

MVVM in Silverlight

This video describes the concept of a ViewModel, and it does it outside of Prism. If you're interested in MVVM, this is the video that shows you how to do it.

GreenBackgroundBottom
backgroundBottom
backgroundBottom