DEV Community: Sr. Kuantico

Publish-Subscribe Pattern in .NET MAUI

Sr. Kuantico — Sun, 13 Jul 2025 21:53:47 +0000

Why This Pattern?

Publish–Subscribe (Pub/Sub) is like the PA system for your app: one bit of code (the publisher) shouts, “Hey, something just happened!” and anyone who cares (subscribers) quietly tunes in. Nobody swaps phone numbers, so publishers stay blissfully ignorant of who’s listening, and subscribers don’t sweat who triggered the event. That double-blind decoupling is catnip for event-driven or distributed setups.

In a statically-typed world like C#, Pub/Sub is perfect when you need to fire off work without tripping over other patterns—or the UI thread. Strong typing keeps your contracts clear, while async subscribers do their thing off to the side so the main flow stays snappy.

Think real-world stuff: an IoT sensor pings your app, a background job waits for a status flip before nudging the UI, or your backend shoots a push notification. For all those “react-as-soon-as-this-happens” moments, Pub/Sub is the buddy you’ll call first.

Recommended Libraries

Pub/Sub choices in .NET MAUI aren’t exactly scarce, but two names pop up in just about every repo and blog post you’ll stumble across.

CommunityToolkit.Mvvm WeakReferenceMessenger – bundled with the official MAUI Community Toolkit, it keeps event contracts strongly-typed while holding references loosely so your pages don’t stick around in memory after you navigate away. Fire-and-forget, minimal ceremony, shipped by the same folks who maintain the toolkit you’re already using for MVVM goodness. Ref: WeakMessaging

Plugin.Maui.MessagingCenter – a lightweight, MAUI-friendly wrapper around the classic Xamarin .Forms MessagingCenter. Same dead-simple .Send() / .Subscribe() API you might already know, refreshed for the multi-target MAUI world with no extra dependencies. Ref: MessagingCenter By Gerald

Both libraries let your pages, view-models, and services gossip without swapping phone numbers: publishers broadcast, subscribers listen, and nobody keeps a hard reference to anyone else. They’re thread-safe, play nicely with async/await, and live entirely in-process—no broker, queues, or JSON schemas required. Pick the Toolkit if you want strong typing and built-in leak protection, or stick with MessagingCenter if you favor the ultra-simple “string topic + payload” vibe. Either way, you get that double-blind decoupling MAUI apps crave.

Good Practices

There are 3 things that you can do to improve your Pub/Sub pattern. Again this practices are based on my dev experience, they can be better or other ref options, my intention in share my knowledge instead override others. Keep that in mind.

Usage on Handlers or Platform Specific
Usage for Core Layer or ViewModels
Example of messaging payload

Now let's code a little bit...

Usage on Handlers or Platform Specific

What you can do

When I’m wiring up custom handlers, Pub / Sub is my grab-and-go trick. Think of an Android barcode-scanner handler shouting “QR decoded!” while the shared view happily renders the result—no ugly #if ANDROID needed. Over on iOS, a Core Bluetooth handler yells “BLE connected,” Windows fires “pen pressure,” and the same shared code just listens. I can bolt on native NFC taps or game-controller events without splashing platform glue across my neutral layer.

That recipe’s worked for me—your mileage may vary. I’m not laying down gospel here, just sharing what’s saved me headaches. With Pub/Sub all I track is a topic name. Swap out an Android Binding Library tweak for an iOS Binding Library shim, add a fresh Windows/MacOS target, and the rest of the app doesn’t flinch. Tests spoof messages, new platforms add their own handler publishers, and my shared codebase keeps its zen-garden cleanliness.

What you should avoid

Stuff I dodge when wiring handlers to the bus: never blast messages every frame from a gyro stream—debounce or you’ll tank battery and FPS. Unhook in DisconnectHandler/Dispose/OnNavigatedFrom; leaked subscriptions survive orientation changes and eat RAM. Keep payloads skinny—pass a file path, not the 4 MB photo bytes. Don’t bury runtime-permission prompts inside callbacks; raise an event and let a page decide or task completions will vanish on suspend/resume. And always program for the void—if a device lacks haptics, your “vibrate” message may meet exactly zero listeners.

Usage for Core Layer or ViewModels

What you can do

In my .NET MAUI apps, wiring Pub/Sub between services and ViewModels (when necessary) keeps things nice and loose: the page fires an event, any background service handles it on its own thread, and the UI never hangs. That decoupling lets me push silent refreshes, live notifications, or analytics pings without sprinkling callbacks all over the codebase—smooth user flow, fewer spaghetti dependencies.

These thoughts come straight from projects I’ve wrestled with; you might find slicker tricks or stronger refs elsewhere, and that’s cool. What Pub/Sub still buys me is painless testing (just inject a mock bus), cheap feature adds (new view just subscribes), and safer refactors because publishers never care who’s on the other end.

What you should avoid

Things I try hard avoid: don’t blast huge payloads through the bus—pass IDs and pull details locally or you’ll choke memory. Resist treating Pub/Sub as a magic DI container: if a consumer is required, wire it directly so failures surface fast. Keep the messenger wrapped in a thin service so tests stay clean, and always unsubscribe; orphan handlers pin pages in memory and wreck perf on Android back-stacks. Skip heavy business logic in the callback—hand it off to a service or background task—and never assume UI-thread context; hop back to MainThread or enjoy random crashes.

Example of messaging payload

If you are looking some Pub/Sub implementation code in .NET MAUI, this is your section. Now there is two libraries mention in this post, so I will created code for both of them. Are you ready?

Plugin.Maui.MessagingCenter

Let's create the Subscribe and Unsubscribe functions in the class that you will Subscribe/Register the payload.

    /// <summary>
    /// Subscribes to MessagingCenter messages carrying a MessagingResponse payload.
    /// </summary>
    public void Subscribe()
    {
        MessagingCenter.Subscribe<object, MessagingResponse>(
            this,
            nameof(MessagingResponse),
            DoWhenMessageReceived);
    }

    /// <summary>
    /// Unsubscribes from MessagingCenter messages.
    /// </summary>
    public void Unsubscribe()
    {
        MessagingCenter.Unsubscribe<object, MessagingResponse>(
            this,
            nameof(MessagingResponse));
    }

Now, add the next model to your project or Entity layer. This will gives to every Pub/Sub hop a single, consistent envelope: Result carries data, MessageType hints at shape, and built-in error/exception flags travel with it, so subscribers can act or bail fast. One strongly-typed wrapper means less casting, safer logging, and cleaner testing across MAUI targets.

If you have a global constant class, add the enum there.

public class MessagingResponse
{
    public enum MessageType
    {
        SingleResponse,
        ComplexResponse
    }

    public object? Result { get; set; }
    public bool HasError { get; set; }
    public bool HasException { get; set; }
    public string? ErrorMessage { get; set; }
    public Exception? Exception { get; set; }
    public MessageType MessageType { get; set; }
}

The next thing to do is define what you need when the Subscription get hits. I did a sample function for you:

/// <summary>
/// Handles incoming MessagingResponse messages.
/// </summary>
/// <param name="sender">The publisher sending the message.</param>
/// <param name="message">The message payload.</param>
private async void DoWhenMessageReceived(object sender, MessagingResponse message)
{
    if (message.HasException || message.HasError)
    {
        Console.WriteLine($"Do Something when error or exception: {message.Exception?.Message} {message.ErrorMessage}");
        return;
    }

    switch (message.MessageType)
    {
        case MessageType.SingleResponse:
            // Example: message.Result = https://www.google.com to Ping Google in the background
            try
            {
                if(message.Result == null)
                  return;

                using var client = new HttpClient();
                var response = await client.GetAsync((string)message.Result));
                Console.WriteLine($"Website ping status: {response.StatusCode}");
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Ping failed: {ex.Message}");
            }
            break;
        case MessageType.ComplexResponse:
            // Handle complex objects here. Ex: Iterate a list, call a services, or another kind of sync/async activity.
            break;
    }
}

Finally, do not forget to call using Plugin.Maui.MessagingCenter; in your class or implement your publishHelper or service to the send the messages from your most convenient case:

   public void Subscribe() =>
        MessagingCenter.Subscribe<object, MessagingResponse>(
            this,
            nameof(MessagingResponse),
            DoWhenMessageReceived);

    public void Unsubscribe() =>
        MessagingCenter.Unsubscribe<object, MessagingResponse>(
            this,
            nameof(MessagingResponse));

CommunityToolkit.Mvvm WeakReferenceMessenger

Let's reuse the previous example, first add the library to and nuget package for using CommunityToolkit.Mvvm.Messaging; to Send a message:

/// <summary>
/// Publishes this <see cref="MessagingResponse"/> instance through the toolkit messenger.
/// </summary>
public void Send() => WeakReferenceMessenger.Default.Send(this);

/// <summary>
/// Static helper to publish any <see cref="MessagingResponse"/> payload.
/// </summary>
public static void Send(MessagingResponse payload) => WeakReferenceMessenger.Default.Send(payload);

It's more or less the same than previous to Subscribed and unsubscribe:

    public void Subscribe() =>
        WeakReferenceMessenger.Default.Register<MessagingResponse>(
            this,
            (recipient, message) => _ = HandleMessageAsync(message));

    public void Unsubscribe() =>
        WeakReferenceMessenger.Default.Unregister<MessagingResponse>(this);

Finally, your to-do function:

private static async Task HandleMessageAsync(MessagingResponse message)
{
    if (message.HasException || message.HasError)
    {
        Console.WriteLine($"Error or exception: {message.Exception?.Message ?? message.ErrorMessage}");
        return;
    }

    switch (message.MessageType)
    {
        case MessageType.SingleResponse:
            if (message.Result is string url)
            {
                try
                {
                    using var client = new HttpClient();
                    var response = await client.GetAsync(url);
                    Console.WriteLine($"Website ping status: {response.StatusCode}");
                }
                catch (Exception ex)
                {
                    Console.WriteLine($"Ping failed: {ex.Message}");
                }
            }
            break;
        case MessageType.ComplexResponse:
            Console.WriteLine("Complex response processing...");
            break;
    }
}

I hope this could help you. Enjoy the coding!...

Credits To:

Many thanks to these cracks...

Ref: Gerald Versluis
Ref: CommunityToolkit.Mvvm Contributors

Microsoft Teams Video Calls to .NET MAUI: A Seamless Integration Guide for iOS

Sr. Kuantico — Sun, 22 Jun 2025 16:39:51 +0000

And now let's continue with the other part of the implementation. If you missed the first one, go to this post where I explained how to do it for Android platform.

Now, it's to start with the steps. Enjoy the code!...

Configuration

You will required a Mac for this. Sorry for that, but we will need to run some files via CocoaPods + Xcode too.

First at all, download the repo from here: http://bit.ly/4dROPnr
In your CMD or Terminal go to: [repo]/ProxyLibs/CommunicationUI-Proxy/CommunicationUI-Proxy.xcworkspace folder.

Make sure to have homebrew, Ruby & Cocoapods installed

//Run this in your terminal, consider use *sudo* for permissions. After all these commands pay attention to the console due probably will required extra libraries to install.

brew install ruby
export PATH="/opt/homebrew/opt/ruby/bin:$PATH"
source ~/.zshrc
gem install cocoapods

//This next command will help us to install part of the necessary resource for Proxy xcworkspace.
pod install

Jump back, in your terminal, to: [repo]/ProxyLibs/CommunicationUI-Proxy and run

//This will create the xcode project framework

./iOSFramework.sh

5.In my case, I didn't have to, but if after these steps your Proxy dir doesn't look like the image below; You will need to execute the Sharpie commands for this project. However, AFTER SHARPIE make sure your dir looks like this:

6.Let's jump to our project in VSCode where we will add the necessary project reference, and your solution explorer should looks like this:

<ItemGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'">
    <ProjectReference Include="../iOS.CallingUI.Binding/iOS.CallingUI.Binding.csproj" />
  </ItemGroup>

7.Do not forget to create your Composite class in iOS and extended it from IComposite interface created in the Android post.

8.Clean and Build, always make sure whatever you are adding AT LEAST compile.

9.Considered to add in your Azure Portal the necessary resources to make this work. For this one we will need an Azure Communication Service. First create the resource and finally, generate the token.

10.Finally, the place to put your token and meeting info, you will find it on MainPage.xaml.cs:

callComposite.joinCall("[Your Name]",
            "[Your Azure Communication Services Token]",
            "[Teams Link]",
            CallType.TeamsCall, _localization, _dataModelInjection, _orientationProps, _callControlProps);

NOTES TO CONSIDER

1.I left an alert setup, because this get crash if you try to join into a meeting from a simulator:

if (DeviceInfo.Platform == DevicePlatform.iOS && DeviceInfo.DeviceType == DeviceType.Virtual)
            {
                DisplayAlert("Error", "Joining calls is not supported on iOS Simulators.", "OK");
                return;
            }

2.Point #5 of this post is very important. When you finish to download the framework files, they gets located in a different folder path than the image. I have to move them manually to make it work. This is because when you compile the project the binding will try to reach this files ON THIS path instead on the other installed by default. Don't forget it!

3.If My repo on github give you errors when compile, if because you need to follow to steps to decompress the missing files and libraries. Good luck!

CREDITS

I want to say thanks to the .NET MAUI and Microsoft team whose collaborate to give us the base code for this. They did the major part and deserve my gratitude.

Collaborators

Enjoy the coding!

Microsoft Teams Video Calls to .NET MAUI: A Seamless Integration Guide for Android

Sr. Kuantico — Sat, 24 May 2025 04:20:12 +0000

Ever wished you could blend .NET MAUI with the collaboration magic of Microsoft Teams? With .NET MAUI, building native apps for multiple platforms is easier than ever — and now, you can take it a step further by integrating a new Azure UI Library that get you directly with Teams video calls! making your apps more collaborative and accessible with the power of Azure + Teams. 🚀

Not too many .NET MAUI Frameworks for video calls

One noticeable gap in .NET MAUI right now is the lack of built-in support for implementing video calls. While MAUI excels at creating cross-platform applications with a single codebase, developers looking to integrate real-time video communication need to rely on third-party SDKs or platform-specific implementations. Unlike some frameworks that offer native modules for video conferencing, .NET MAUI doesn't currently provide an out-of-the-box solution, which can add complexity when targeting multiple platforms like Android, iOS, Windows, and macOS. This means handling platform-specific quirks and ensuring smooth video performance across devices, often leading to additional development overhead.

Azure Communication Service UI Library for Mobile

Even with the market being blooding by the lack of options The Azure team has designed this new library as a solution. This required a platform-specific implementation, but today we will just focus on Android.

The Azure Communication UI Mobile Library gives you plug-and-play UI components for building B2C and B2B calling experiences fast—no need to start from scratch. Now let's start the coding...

Prerequisites

Based on Contributors Documentation take this requirements as must:

Create an Azure account and make a subscription active:
Don't forget to Download Android Studio and run a test project.
Create and add the Azure Communication Resource into your previous Azure account created.
Don't forget to get your service Token for authentication.
Remember having setup your Visual Studio Or Visual Code.
Download GitBash at your end or have installed anything that could run .sh files.
And finally, download this repo at your end.

After having done all preparation points, let's start with the implementation.

Getting Start

1- Open the repo downloaded call: CommunicationCallingSampleMauiApp with your file explorer/finder.

2- Now, create your own .NET MAUI project. In my case, I created one based on .NET 9 just for Android.

3- From the repo project downloaded, find this folder AndroidMauiBindings and copy the files from the image into your solution folder:

4- Run the script file with your Gitbash (Windows) console or your preference editor, like this:

///First command
chmod +x downloadJarScript.sh
///Second command
./downloadJarScript.sh

5- Import the android bindings previously copied under your solution:

This binding are very important and their Jars libreries too. If you can get it correctly from the repo, try it from the original source.

6- After that, add the resources folder require for bindings to get the necessary assets to drawing the Video Call UI:

7- Now go to your Android Manifest file and make sure it looks like this:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools">
  <application
    android:allowBackup="true"
    tools:replace="android:label"
    android:icon="@mipmap/appicon"
    android:roundIcon="@mipmap/appicon_round"
    android:supportsRtl="true"
    android:enableOnBackInvokedCallback="true"/>
  <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.INTERNET" />
</manifest>

8- Now is time to compile your project and everything should be good.

9- I submitted a repo with this working, and you can find the missed pieces in there.

10- Considered to add in your Azure Portal the necessary resources to make this work. For this one we will need an Azure Communication Service. First create the resource and finally, generate the token.

11- Finally, the place to put your token and meeting info, you will find it on MainPage.xaml.cs:

private void OnCounterClicked(object sender, EventArgs e)
        {
             callComposite.joinCall("[Your Name]", "[Place your token in here]", "[Place your Teams link meeting in here]", CallType.TeamsCall, _localization, _dataModelInjection, _orientationProps, _callControlProps);
        }

NOTES TO CONSIDERE

NOTE #1: There is a reported about this kind of implementation saved on a very long file path. Consider to save this in a shorter place, As: C:/src/[MyProject]. Issue Link.

NOTE #2: Make sure to setup the project file as was recommended other wise, you could get this type of Issue.