COMMUNICATION

- communicate with modules and still maintain loose coupling

APPROACHES TO COMMUNICATE BETWEEN MODULES

- Commanding with the support of delegate commands and composite
commands
- Event Aggregation
- Shared Services
- provide information with the Region Context

COMMANDING
- the most common method of communicating in a Prism application
COMMAND
- a command binds a UI gesture, such as a button click, to an
action that needs to be performed
- has an execute method which is called when the command is
invoked
- has a CanExecute method which determines whether or not the
command can be executed
*the element that is bound to the command will be either
enabled or disabled based on the result of the CanExecute method
COMMON WAYS IN CREATING COMMANDS
- RoutedCommand
- deliver command messages through UI elements in
the visual tree (any element outside of the tree will not receive these messages)
- require to create handlers in the code behind
*which is where we don't want to place our
logic
- Custom Command
- involves creating a custom class that derives
from ICommand and implements the ICommand interface
2 CLASSES THAT MAKES COMMANDING EASIER
- Delegate Command
*allows you to call a
delegate method when the command is executed
- Composite Command
*allows you to combine
multiple commands

2 CLASSES TO MAKE COMMANDING EASIER AND PROVIDES MORE FUNCTIONALITY

\

+ DELEGATE COMMAND
- a command that allows you to supply methods as delegates
that will be invoked when the command is invoked
- command that allows you to call a delegate method when the
command is executed
*event handler is not required in the code behind
- normally locally scoped,meaning they're created within a
ViewModel
- concerns of the delegate methods are within the context of
that ViewModel
2 DELEGATE COMMANDS
1. DelegateCommand
- Execute and CanExecute delegate
methods will not accept a parameter
2. DelegateCommand<T>
- allows you to specify a type of
parameter that the execute and CanExecute methods parameters will be.
 + COMPOSITE COMMANDS
- are usually globally scoped commands that exist in the
infrastructure class that contain multiple child commands
- each view would have the local commands that are defined in
the ViewModel register with the SaveAll CompositeCommand
*when SaveAll command is invoked, all registered child
commands will also be invoked
- it supports enablement by listening to the
CanExecuteChanged event of each registered child command
*if any call to the CanExecute returns false in a child
command, the CompositeCommand will also return false, thus disabling all the
invokers
- allows you to combine multiple commands

+ EVENT AGGREGATION
- loosely coupled event based communication mechanism
- made up of publishers and subscribers
publisher - executes an event
subscribers - listen for the event
- memory leaks are reduced
*because subscribers don't need a strong reference to the
publishers
*not worry about manually unsubscribing to subscribers

INTERFACE
IEventAggregator - interface which is a prism built in
support for event aggregation by providing core service
- responsible for locating
and building events
- keeping a collection of
events in the system
* both publishers and subscribers will
need an instance of the EventAggregator *
* to get the instance, just request it
from the container

- provides multicast Pub/Sub functionality

*there can be multiple publishers that raise the same event
*and there could be multiple subscribers listening to that
same event

*Events created with the Prism library are typed events *

*can take advantage of the compile type checking to check for errors
before running the application
*The only class that Prism provides for creating events is the
CompositePresentation<T>

CompositePresentation<T>
- maintains the list of subscribers and hndles event
dispatching to the subscribers
- this class is a generic that requires a payload type <T> is
the required payload
*the payload being what you would want to send to the
subscriber when the event is published
SERVICES OF THE EVENTAGGREGATOR
- publish events
*Publishers raise an event by retrieveing the
event from the EventAggregator and then calling the Publlish method
- subscribe to events
 *using one of the subscribe method overloads
available on the CompositePresentationEventClass
WAYS TO SUBSCRIBE TO AN EVENT
- If UI elements need to be
updated when an event is received, subscribe to the event on the UI thread
- Subscribe using a strong
reference.
*use the
keepSubscriberReferenceAlive parameter on the Subscribe method.
*by using this method, you
would manually need to unsubscribe from the event when disposing the subscriber
- Event filtering
*Subscribers may not need to
handle every instance of a published event
*In this case, you can
provide a filtered delegate when subscribing
- Manually unsubscribe from
events
*Subscriber no longer wants
to receive the event
*Can be done using your
subscriber's handler or by using a subscription token

+ SHARED SERVICES
- custom class that provides functionality to other modules in a
loosely coupled way
- normally done through an interface and is often a singleton
- these services normally exist in a separate module
*and when these modules load, the service can be registered with
the Service Locator
- when registering a service, you will register them with a common
interface
*allows other modules to use your service without requiring a
static reference to the service module
* side effect of using a common interface is that your concrete
implementations don't have to be shared
* common interface can exist in your Infrastructure class
* concrete implementation will exist in a service module
- registering a service as a shared service is as easy as
specifying a ContainerControlledLifetimeManager

+ REGION CONTEXT
- share an object between the region host and views inside the
region
- expose the object either in xaml or through code
*currently, prism only supports consuming the region context from
a view inside a region only of that view is a dependency object
*if view is not a dependency object, for example,using of data
templates, you may need to create a custom region behavior to forward to the region
context in order to view your objects
*don't use data context because data context is commonly used to
bind ViewModel to a view.
*So this means that your DataContext is now storing the
view's entire ViewModel, so unlesss you have very simple views, using DataContext
as a communication mechanism between loosely coupled views is not recommended