Messaging Between ViewModels

When view models need to talk

CoinJar now has several screens (from Navigation Between Views): an “add expense” form, the expense list and a summary. When the user saves a new expense on the form, the list should show it and the summary should update its total.

The obvious fix is to give AddExpenseViewModel a reference to the other two and call them:

// Works, but every view model now knows about every other one
_list.Expenses.Add(expense);
_summary.Refresh();

That creates a tangle. Add a fourth screen that cares about new expenses, and you have to edit the form’s view model again. Tests get harder too, because you cannot create one view model without all the others.

A messenger solves this. Think of it as a noticeboard in an office. Anyone can pin a note (“a new expense was added”), and anyone who is interested reads it. The person who pins the note does not need to know who will read it. In programming this is called the publish and subscribe pattern.

CommunityToolkit.Mvvm, which you installed in MVVM with CommunityToolkit.Mvvm, includes a ready made messenger.

Step 1: define a message

A message is just a small class that carries data. A record is perfect, because messages should not change after they are sent:

namespace CoinJar.Messages;

public sealed record ExpenseAddedMessage(Expense Expense);

The toolkit also has a helper base class for “here is a new value” messages, if you prefer:

using CommunityToolkit.Mvvm.Messaging.Messages;

public sealed class ExpenseAddedMessage(Expense value) : ValueChangedMessage<Expense>(value);
// Receivers read message.Value

Either style is fine. This lesson uses the record.

Step 2: send it

Sending is one line. WeakReferenceMessenger.Default is a shared messenger for the whole app:

using CommunityToolkit.Mvvm.Messaging;

[RelayCommand]
private void Save()
{
    var expense = new Expense { Title = Title, Amount = Amount, Category = Category };
    _store.Add(expense);

    WeakReferenceMessenger.Default.Send(new ExpenseAddedMessage(expense));
}

The sender does not know or care who is listening. If nobody is, the message simply goes nowhere.

Step 3: receive it

A view model that wants the message registers for it. The handler gets two arguments: the recipient (the object that registered) and the message.

public ExpenseListViewModel(IMessenger messenger)
{
    messenger.Register<ExpenseListViewModel, ExpenseAddedMessage>(this,
        static (recipient, message) => recipient.Expenses.Add(message.Expense));
}

Why the odd (recipient, message) shape, and why static? The handler uses the recipient argument instead of this. Marking the lambda static makes the compiler stop you from capturing this by accident. That matters because of how the messenger stores recipients, explained next.

Weak references: why “WeakReference” messenger?

Normally, if object A holds a reference to object B, B cannot be cleaned up by the garbage collector while A is alive (see memory management and garbage collection). With a messenger that lives forever, that would mean every registered view model also lives forever. That is a memory leak: memory that is never given back.

WeakReferenceMessenger holds recipients through weak references. A weak reference lets the messenger find the object while it is alive, but does not keep it alive. When nothing else uses a view model, it can be collected, and the messenger forgets it automatically.

The toolkit also has StrongReferenceMessenger. It is a bit faster, but you must unregister every recipient yourself, or it leaks. Start with the weak one.

To stop listening:

messenger.Unregister<ExpenseAddedMessage>(this); // one message type
messenger.UnregisterAll(this);                   // everything for this recipient

IRecipient and ObservableRecipient

If a view model handles several messages, registering lambdas one by one gets noisy. Instead, implement IRecipient<TMessage> for each message type and inherit from ObservableRecipient:

public partial class SummaryViewModel : ObservableRecipient, IRecipient<ExpenseAddedMessage>
{
    public SummaryViewModel(IMessenger messenger) : base(messenger)
    {
        IsActive = true; // registers every IRecipient<T> this class implements
    }

    [ObservableProperty]
    public partial decimal Total { get; set; }

    public void Receive(ExpenseAddedMessage message)
    {
        Total += message.Expense.Amount;
    }
}

ObservableRecipient is an ObservableObject with messenger support built in:

• It has a Messenger property (the one you pass to the constructor, or WeakReferenceMessenger.Default if you pass none).
• Setting IsActive = true calls OnActivated, which by default registers all your IRecipient<T> interfaces.
• Setting IsActive = false calls OnDeactivated, which unregisters everything.

That makes it easy to listen only while a screen is visible: activate it when you navigate to it and deactivate it when you leave.

Asking a question: request messages

Sometimes you want an answer back, not just to announce something. A request message carries a reply. Inherit from RequestMessage<T>, where T is the type of the answer:

public sealed class CurrentTotalRequestMessage : RequestMessage<decimal>;

The view model that knows the answer replies:

messenger.Register<ExpenseListViewModel, CurrentTotalRequestMessage>(this,
    static (recipient, message) => message.Reply(recipient.Total));

Any other view model can now ask:

decimal total = messenger.Send<CurrentTotalRequestMessage>();

The Send call returns the message, and a request message converts to its answer automatically. If nobody replied, reading the answer throws an InvalidOperationException. Check HasReceivedResponse on the message first if a reply is not guaranteed.

Broadcasting property changes

ObservableRecipient has one more trick. Add [NotifyPropertyChangedRecipients] to a property and every change is sent as a PropertyChangedMessage<T>:

public partial class SettingsViewModel(IMessenger messenger) : ObservableRecipient(messenger)
{
    [ObservableProperty]
    [NotifyPropertyChangedRecipients]
    public partial string CurrencyCode { get; set; } = "GBP";
}

Other view models register for PropertyChangedMessage<string> and check message.PropertyName == "CurrencyCode". This is handy for app wide settings.

Using the messenger with DI

WeakReferenceMessenger.Default works anywhere, but a hidden global is hard to replace in tests. Register the messenger in the container from Dependency Injection with the Generic Host and ask for IMessenger in constructors:

builder.Services.AddSingleton<IMessenger>(WeakReferenceMessenger.Default);

In a test you can pass new WeakReferenceMessenger() instead, so each test gets its own clean noticeboard.

Tips and common mistakes

• Use messages for “something happened” between screens. For a parent talking to its own child view model, a normal method call or property is simpler. Do not turn every call into a message.
• Make one message type per event. ExpenseAddedMessage, ExpenseDeletedMessage. A generic “SomethingChanged” message with a string inside quickly becomes confusing.
• Handlers run right away, on the sender’s thread. Send calls every handler before it returns. If you send from a background thread, the handlers also run there, and updating UI bound collections from there fails. See The Dispatcher and Threading.
• Capturing this in the handler. Use the recipient argument and a static lambda, as shown above.
• Forgetting IsActive = true. An ObservableRecipient does not receive anything until it is active.
• Registering twice. Registering the same recipient for the same message type twice throws an exception. Register in the constructor (or OnActivated), not every time a screen is shown.
• Channels. If two separate parts of the app send the same message type, you can pass a token to Register and Send so each part only hears its own messages.

Quick recap

• A messenger lets view models talk without references to each other: senders Send a message, recipients Register for it.
• Messages are small classes, often records. ValueChangedMessage<T> and RequestMessage<T> are ready made bases.
• WeakReferenceMessenger does not keep recipients alive, so forgotten registrations do not leak memory.
• ObservableRecipient plus IRecipient<T> registers handlers automatically when IsActive is true.
• Request messages return an answer with Reply, and [NotifyPropertyChangedRecipients] broadcasts property changes.
• Register IMessenger in DI so tests can use their own messenger.