Forem: Thomas M

Turning .NET MAUI Upgrades into a Repeatable, Low‑Risk Process

Thomas M — Mon, 26 Jan 2026 13:55:17 +0000

Upgrading a .NET MAUI application is rarely hard because of one breaking change.
It’s hard because upgrades sit at the intersection of framework evolution, platform requirements, tooling, and existing architecture — and those things rarely move in sync.

A “simple” MAUI upgrade can involve:

A new .NET SDK
Updated MAUI workloads
Android and iOS minimum version changes
Package deprecations
Build pipeline assumptions that no longer hold
Platform issues that only appear once the app actually launches

Most teams know this — yet upgrades are still handled as ad‑hoc tasks, driven by release pressure or looming support deadlines. That’s usually where things start to go wrong.
I wanted to change that.

Instead of treating MAUI upgrades as a one‑off activity, I treated them as a design problem — and the result was a reusable upgrade prompt whose job is to enforce good engineering behaviour by default.

This post explains why that prompt exists, how it’s structured, and why the prompt itself is the real product.

⭐ The Prompt Is the Solution

This approach isn’t about AI magically upgrading your app for you.
The prompt is the star of the show.

🧠 It encodes experience
🛑 It enforces discipline
🧭 It removes ambiguity
📋 It turns upgrades into a guided, auditable workflow

Without a strong prompt, assistants tend to optimise for “making things compile”.

With a strong prompt, they optimise for doing the upgrade properly.
The assistant becomes an execution partner — but the prompt defines the rules of engagement.

🚨 What the Prompt Is Designed to Prevent

The prompt exists because the same failure patterns show up again and again in MAUI upgrades:

❌ Accidentally upgrading to preview or RC SDKs
❌ Architecture drift during “harmless” refactors
❌ Dependency churn justified as “best practice”
❌ Full solution builds run blindly and repeatedly
❌ Android or iOS issues discovered at the very end
❌ CI pipelines failing after the upgrade is merged

These aren’t edge cases — they’re the default outcome of unstructured upgrades.

Every section of the prompt exists to counter one of these failure modes.

🧩 A Practical MAUI Upgrade Prompt Pattern

Below is a practical example of the upgrade prompt pattern I use.
It focuses on structure, sequencing, and guardrails — the things that actually make upgrades predictable and repeatable — rather than on any single application or codebase.

💡 Think of this as a blueprint, not a script.

The value is in how the pieces fit together.

// MAUI Upgrade Prompt Pattern
// Purpose: enforce a structured, low-risk MAUI upgrade process

You are an experienced .NET MAUI engineer performing a framework upgrade.

Target the latest fully released, stable MAUI version unless otherwise specified.
Do NOT use preview, RC, or beta SDKs, workloads, or NuGet packages.

Primary objectives:
- Maintain application stability throughout the upgrade
- Preserve architectural intent and existing design decisions
- Minimise unnecessary or speculative changes
- Ensure Android and iOS builds succeed and launch

Architectural constraints:
- Preserve existing navigation patterns
- Maintain strict MVVM boundaries
- Keep views lightweight and UI-focused
- Avoid conditional compilation in shared source code
- Place platform-specific code behind proper abstractions

Before making any changes:
- Inventory current MAUI and .NET versions
- List all projects and target frameworks (TFMs)
- Identify key packages and build tooling
- Review CI/CD pipelines for SDK or MAUI assumptions
- Confirm required SDKs and workloads are installed

Upgrade workflow:
1. Plan the upgrade and document required changes
2. Update project files and target frameworks
3. Align dependencies using stable releases only
4. Address breaking changes deliberately and incrementally
5. Build and test incrementally, avoiding unnecessary rebuilds
6. Validate Android and iOS builds and app launch
7. Review and justify any optional or non-essential changes

Operational rules:
- Warn before running long or expensive build commands
- Pause after each major step for review or confirmation
- Produce a final summary of changes, outcomes, and risks

Definition of done:
- Solution builds successfully
- Android app launches successfully
- iOS app launches successfully
- Architectural intent remains intact

This prompt is intentionally opinionated — because upgrades are not the place for ambiguity.

🧠 Why Each Section Exists

🎯 1. Role and Quality Bar

The prompt starts by defining how the assistant must behave.

✅ Stability‑first mindset
✅ No experimentation during upgrades
✅ Engineering judgement over novelty

Without this, tools tend to suggest newer APIs, introduce architectural changes “for improvement”, or optimise for cleverness rather than safety.
Upgrades demand restraint — the prompt enforces it.

🏗️ 2. Architectural Guardrails

Upgrades are where architecture erodes quietly.
The prompt explicitly protects against that:

No surprise navigation changes
No UI logic leakage
No platform hacks in shared code

The result is that the application still feels like the same system after the upgrade — just on a newer framework.

⏱️ 3. Build‑Time Awareness

MAUI builds are expensive, slow, and easy to overuse.
The prompt treats build time as a cost to manage, not an afterthought:

⚠️ Warn before long builds
⚡ Prefer incremental validation
🧹 Avoid unnecessary cleans

This keeps humans in control and prevents blind iteration.

🗺️ 4. Context Before Action

Most upgrade pain comes from missing context.
The prompt forces an inventory before touching code:

Framework versions
Project structure
Dependencies
CI/CD assumptions

Nothing changes until the landscape is understood.
This alone eliminates a huge class of late‑stage surprises.

🚦 5. Gated, Sequential Execution

The upgrade is broken into explicit phases, each with pause points.

✅ Failures are isolated
✅ Reviews are meaningful
✅ Rollback remains viable

This mirrors how experienced engineers already work — but makes it explicit and repeatable.

📱 6. Platform Validation Is Non‑Optional

The prompt does not consider the upgrade complete unless:

✅ Android builds and launches
✅ iOS builds and launches
“It builds” is not a definition of done.

Mobile apps fail on devices, not in IDEs — and the prompt enforces that reality.

🔍 7. Review of “Optional” Changes

One subtle but powerful rule:

The prompt explicitly asks for a review of changes that might not be required.

Why this matters:

Prevents silent scope creep
Documents trade‑offs
Keeps upgrades honest

This is where discipline usually slips — and where it’s restored.

✅ Why This Works

This approach doesn’t automate expertise — it captures it.
The prompt:

Makes assumptions explicit
Encodes hard‑won experience
Reduces cognitive load
Scales across teams and projects

Most importantly, it turns MAUI upgrades from a stressful event into a repeatable engineering process.

🧠 Final Thoughts

If your MAUI upgrades feel unpredictable, the problem usually isn’t the framework.
It’s the lack of structure.
A well‑designed prompt won’t remove the need for engineers —
but it will ensure their experience shows up every single time.
And once you’ve used this approach for upgrades, you’ll start seeing other places where a good prompt can act as guardrails — migrations, refactors, and CI/CD changes included.

Exploring Azure ADO MCP Server: A Smart Assistant for Smarter Development

Thomas M — Wed, 14 Jan 2026 15:57:48 +0000

Over the past few weeks, I’ve been experimenting with the Azure DevOps MCP (Model Context Protocol) server, and it’s quickly become a valuable part of my development workflow. I’m always on the lookout for tools that support quality assurance and help reduce scope creep — and MCP is shaping up to be exactly that.

🧠 What Is ADO MCP?

The Azure DevOps MCP server acts as an intelligent agent inside Azure DevOps, analysing code changes in the context of user stories, acceptance criteria, and broader project objectives. Instead of simply reviewing what was changed, it helps evaluate why those changes were made and whether they fully address the requirements.
You can learn more about the Azure DevOps MCP Server setup via:

🔍 Use Case: Validating Scope Against Acceptance Criteria

A recent example involved a task to add a new field to a user interface. Straightforward enough — but the related requirements also involved updating the underlying data records, a detail that’s easy to miss.
Using MCP in agent mode, I asked it to compare my branch with the main branch and evaluate the changes against the story description and acceptance criteria. MCP correctly flagged that while the UI updates were complete, the associated data updates were missing.
In this case, the omission was intentional — a small experiment to see how well MCP could detect the gap. It did exactly that.
Even better, because I was using agent mode, MCP didn’t stop at identifying the issue. It proposed the necessary data updates, applied them, and confirmed that the acceptance criteria were now fully met.

✅ Why This Matters

This kind of contextual, requirement‑aware validation can significantly improve development workflows by offering:

Fewer missed requirements
Faster feedback loops
Higher confidence that work items are complete and aligned with their acceptance criteria

As long as user stories are written with clear descriptions and robust acceptance criteria, MCP provides an additional layer of assurance that’s both practical and powerful.

💡 Final Thoughts

Tools like the MCP aren’t here to replace developers — they’re here to enhance the way we work. By introducing context‑aware reasoning into our development processes, we can deliver with greater confidence and catch issues that might otherwise slip through. I’ll definitely be keeping MCP in my toolkit going forward.

Migrating to MAUI 10: What Architects Need to Know

Thomas M — Wed, 14 Jan 2026 15:45:31 +0000

If you’ve been working with .NET MAUI—or planning a migration from Xamarin—MAUI 10 is a release you shouldn’t ignore. This isn’t just a routine update; it delivers meaningful improvements in performance, developer experience, and architectural clarity. Here’s what’s new, what’s changed, and how to plan your migration with confidence.

🔥 Why Upgrade to MAUI 10?

MAUI 10 introduces enhancements that matter for both developers and architects:

Performance Improvements
- Faster startup, reduced memory usage, and improved Hot Reload make the development loop smoother and the end experience snappier.
Modern Development Patterns
- Async‑first APIs, simplified layouts, and clearer architectural boundaries reduce complexity and technical debt.
Enterprise‑Ready Capabilities
- Built‑in telemetry hooks, better observability, and improved control over embedded web content.

🧱 Key Architectural Changes

Migrating isn’t just updating your NuGet packages — it’s understanding the underlying shifts.

⚡ Async‑First Animation APIs

Legacy animation methods like FadeTo and RotateTo now have async equivalents (FadeToAsync, RotateToAsync). These follow modern async patterns and help you:

sequence animations naturally
support cancellation
avoid UI thread blocking

✔️ Cleaner MAUI 10 Example

private async Task AnimateBox(CancellationToken cancellationToken)
{
    await Task.WhenAll(
        AnimatedBox.FadeToAsync(0.0, 250),
        AnimatedBox.RotateToAsync(90, 250)
    );

    cancellationToken.ThrowIfCancellationRequested();

    await AnimatedBox.FadeToAsync(1.0, 200);
}

Why: Predictable sequencing, easier chaining, better responsiveness.

🧹 Removal of Legacy Components

Some legacy Xamarin‑compatibility APIs are now deprecated or removed. Here are the notable ones:

👆 Gesture Recognisers.

ClickGestureRecognizer (from the old compatibility stack) has been removed.

Use TapGestureRecognizer instead:

<Image Source="logo.png">
    <Image.GestureRecognizers>
        <TapGestureRecognizer 
            NumberOfTapsRequired="2"
            Tapped="OnTapGestureRecognizerTapped" />
    </Image.GestureRecognizers>
</Image>

📐 Layout Changes

Compatibility layouts (e.g., older Forms-based ones) are deprecated and being phased out. Modern layouts offer:

better performance
deterministic layout behaviour
cleaner XAML

Recommended layouts:
Grid, StackLayout, FlexLayout, and VerticalStackLayout.

<Grid Padding="16"
      RowDefinitions="Auto,*"
      ColumnDefinitions="Auto,*">

    <Image Grid.Row="0" Grid.Column="0" 
           Source="avatar.png" 
           WidthRequest="40" HeightRequest="40"/>

    <Label Grid.Row="0" Grid.Column="1" 
           Text="Welcome" FontAttributes="Bold"/>

    <CollectionView Grid.Row="1" 
                    Grid.ColumnSpan="2"
                    ItemsSource="{Binding Items}" />
</Grid>

Why: Cleaner architecture with no legacy compatibility layers.

🌐 HybridWebView & WebView Interception Enhancements

If your app embeds web content, MAUI 10 introduces meaningful improvements. You can now intercept and handle web requests through WebView handler APIs and—where supported—through HybridWebView or BlazorWebView integrations.
Typical use cases:

Injecting enterprise security headers
Capturing and redirecting requests
Overriding responses
Handling secure API calls in hybrid apps

Note: Interception availability varies slightly by platform; always test behaviour on Android, iOS, and Windows.

Example: Intercepting Requests

private void InitializeWebView()
{
    DemoWebView.WebResourceRequested += OnWebViewWebResourceRequested;
    DemoWebView.RawMessageReceived += OnWebViewRawMessageReceived;
}

private void OnWebViewWebResourceRequested(object? sender, WebViewWebResourceRequestedEventArgs e)
{
    if (e.Uri.ToString().Contains("api/secure"))
    {
        e.Handled = true;
        e.SetResponse(
            statusCode: 200,
            statusMessage: "OK",
            contentType: "application/json",
            content: GetCustomStream()
        );
    }
}

private Stream GetCustomStream()
{
    var json = "{\"status\":\"success\",\"message\":\"Everything is fine!\",\"timestamp\":\""
        + DateTime.Now.ToString("o") + "\"}";
    return new MemoryStream(System.Text.Encoding.UTF8.GetBytes(json));
}

private void OnWebViewRawMessageReceived(object? sender, HybridWebViewRawMessageReceivedEventArgs e)
{
    MainThread.BeginInvokeOnMainThread(() =>
    {
        WebStatusLabel.Text = $"Message from JS: {e.Message}";
    });
}

Why: Better control, improved security, and richer hybrid scenarios.

🧭 Migration Strategy for Architects

Here’s the calm, structured approach to avoid surprises:

🔍 1. Audit Your Codebase

Identify deprecated gesture recognizers
Flag legacy layout usage
Check animation logic for sync‑based APIs

⚠️ 2. Prepare for Breaking Changes

Update animation code paths
Replace obsolete compatibility components
Test WebView‑based features across target platforms

🚀 3. Modernise During Migration

Don’t just port — upgrade.

Adopt async‑first UI flows
Move to modern layouts
Leverage WebView interception for enterprise scenarios
Integrate richer telemetry hooks (MAUI + App Insights)

❗ Common Pitfalls

Treating the migration as a simple “lift and shift”
Ignoring deprecated layout or gesture APIs
Not testing hybrid features across all platforms
Overlooking the opportunity to simplify UI architecture

🎯 Final Thoughts

Upgrading to MAUI 10 isn’t just about staying current — it’s an opportunity to modernise your architecture, remove legacy baggage, and deliver faster, more maintainable apps.
By embracing modern APIs, cleaning up deprecated components, and adopting updated design patterns, your migration becomes an investment in long‑term productivity and performance.

Exploring the Potential of Copilot Agents for Large-Scale Application Migrations

Thomas M — Thu, 15 May 2025 13:21:44 +0000

As a developer, migrating a large-scale web application can be a daunting task. The complexity and scale of such projects often require innovative solutions to streamline the process and ensure success. Recently, I embarked on this journey, aiming to harness the power of AI to facilitate the migration. My initial approach involved using Copilot Chat, a tool I frequently relied on for various tasks. However, I soon realised that while Copilot Chat was helpful, it struggled to fully comprehend the intricacies of my large application.

This led me to explore other options, and that's when I discovered Copilot Agents. Unlike Copilot Chat, Copilot Agents seemed capable of understanding and processing larger applications, which was a promising development. The responsiveness of Copilot Agents to my prompts was particularly noteworthy. It felt like I was venturing into the realm of prompt engineering, where the agent could be guided more effectively based on the prompts I provided.

One of the most intriguing aspects of using Copilot Agents was its ability to process my requests and respond with questions that built further actions. This dynamic interaction was almost like having a virtual pair programming session with myself. The agent's capacity to comprehend my needs and provide actionable insights made the migration process more manageable and less overwhelming.

At this stage, I am still in the early phases of my migration journey. However, the potential of Copilot Agents as a tool for large-scale web application migration is evident. I am keen to see how this tool will continue to support my efforts and streamline the process. As I progress, I plan to share more insights and updates through additional blog posts, documenting my experiences and the effectiveness of Copilot Agents in this venture.

Stay tuned for more updates as I navigate this exciting journey of leveraging AI for web application migration!

References

[1] Set up GitHub Copilot in VS Code - Visual Studio Code

[2] Use agent mode in VS Code - Visual Studio Code

Exploring the new HybridWebView for MAUI 9

Thomas M — Thu, 05 Dec 2024 11:38:39 +0000

In this blog post, I want to share my experience using the new HybridWebView for MAUI 9. The process was surprisingly easy to add a React web app into my MAUI app, and I would definitely use it again in the future.

Introduction

The HybridWebView in MAUI 9 offers a new way to integrate web content into your mobile applications. Unlike the traditional WebView hybrid approach, which requires the web app to be hosted somewhere else and running, the HybridWebView allows you to embed your web app directly into your MAUI app. This eliminates the need for separate hosting and the associated costs.

Benefits of HybridWebView

Using the HybridWebView has several advantages over the standard WebView approach:

No Separate Hosting Required: With HybridWebView, you don't need to spin up your web app separately or make it publicly available before integrating it into your MAUI app.
Stable Versioning: You can ensure that the version of your web app embedded in your mobile app is stable and consistent.
Cost Savings: By not requiring a separate hosting environment, you can save on hosting costs.

Potential Drawbacks

While the HybridWebView approach has many benefits, there are some potential drawbacks to consider:

Divergence Between Web and Mobile Apps: If you can automatically push updates to your web app but have to wait for reviews in the app stores before pushing updates to your mobile app, there may be some divergence between the two versions.
Review Delays: Updates to your mobile app will still need to go through the app store review process, which can introduce delays.

How-To Guide

The following how to will go through some of the steps I took to create a simple MAUI 9 app with a react web application

Step 1: Set up your react web application

For this step I used web storm to create a simple vite + react web application which looked like this:

At this point I have made no changes to the sample app. To generate the files you need, the sample app is enough as it generates the package.json file with the commands you need.

Step 2: Generate your web files

Once you have your react app created, you can run

npm build

This will generate your files in the dist directory.

These are the files that your MAUI application will need to run your web app from the HybridWebiew.

Step 3: Set Up Your MAUI Project

At this point you should now have your web application, and the built files in the dist folder. The next step is to create your MAUI 9 app using your preferred choice of approach. For me, I use Jetbrains Rider to create my MAUI applications and this is the basic configuration

Once you have created your app, you should now have the basic “hello world app”.

Step 4: Add in your web app files

Before we can slot in the HyrbidWebView XAML element, it needs to have the supporting web app files. These files should be stored in the ‘Resources/Raw’ directory, and you can create a folder in here with any name. My example I am using is “reactApp” and once you have added in your files you should have something similar to this

So at this point we now have our web application files added into our new MAUI 9 app and we are ready to configure our HybridWebView.

Step 5: Add the HybridWebView

For me at this stage, I just wanted to use an existing file so that the HybridWebView was the first thing that users seen when they open the app. To do this I updated the MainPage.xaml to remove the existing elements and slot in my HybridWebView element

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="MauiApp2.MainPage">

    <HybridWebView 
        VerticalOptions="FillAndExpand"
        HorizontalOptions="FillAndExpand"
        HybridRoot="reactApp" DefaultFile="index.html" />
</ContentPage>

Doing this will cause some build issues so remember to go in and remove/comment out the counter from the basic app to stop build errors

namespace MauiApp2;

public partial class MainPage : ContentPage
{
    int count = 0;

    public MainPage()
    {
        InitializeComponent();
    }
}

Step 6: Test Your Application

Once you have made all these changes you should now be in a position to test your new MAUI 9 app with your react web application. The app ran on an iOS simulator should look something like the below screenshot

This is your react application built and running successfully hosted in your MAUI 9 application!

Conclusion

Overall, I really like the HybridWebView approach for integrating web content into your MAUI apps. The ease of integration, cost savings, and stable versioning make it a compelling choice. While there are some potential drawbacks, such as divergence between web and mobile app versions, the benefits far outweigh these concerns. I would definitely consider this approach for future projects.

Exploring the Exciting Updates in .NET MAUI 9

Thomas M — Wed, 20 Nov 2024 08:45:12 +0000

I’m thrilled to share my enthusiasm for the newly released .NET MAUI version 9! As a developer who’s always eager to dive into the latest tools and technologies, I can’t wait to get hands-on with the updates and see how they can enhance my applications.

One of the features I’m particularly excited about is the new HybridWebView element. This powerful addition will allow me to embed and host my existing JavaScript web app directly within my MAUI app. The potential here is immense, especially for larger projects where the ability to lift and shift a JavaScript web app into a MAUI app could save a significant amount of time during a migration to Blazor.

I’ve been experimenting with hosting a Blazor app inside my MAUI app, and while that’s been an interesting journey, the HybridWebView offers a different approach. It could simplify communication between a web app and a native app when they’re hosted and bundled together in the MAUI app, which is something I’m very interested in exploring further.

Another aspect that caught my attention is the compiled bindings approach in MAUI 9. It looks a lot more flexible and promises to streamline data binding in a way that’s both efficient and easy to manage. This is a welcome improvement, as one of the challenges I faced with MAUI 8 was the cleanup and control over bindings. The new changes in MAUI 9 for handler disconnection will be incredibly helpful in giving me more control and visibility over my disposals, ensuring a cleaner and more maintainable codebase.

For those who are as excited as I am about these updates, I encourage you to check out the official documentation to find out more: What’s New in .NET MAUI 9. I’m looking forward to playing around with all the new features and hope to post more blogs on what I discover. Stay tuned for more insights and happy coding!

Adding Platform-Specific Code to a .NET MAUI Project

Thomas M — Wed, 30 Oct 2024 08:10:56 +0000

.NET Multi-platform App UI (MAUI) is a powerful framework for building cross-platform applications with a single codebase. However, there are times when you need to write platform-specific code to leverage native APIs or functionalities. In this blog post, we’ll explore how to add platform-specific code to a .NET MAUI project, with examples on how to register and use this code on both Android and iOS platforms. We’ll also discuss a caveat regarding the difficulty of testing platform-specific code compared to cross-platform code.

Why Use Platform-Specific Code?

While .NET MAUI provides a unified API for most functionalities, certain features or optimizations might only be available on specific platforms. For instance, you might want to access a native API that isn’t exposed through MAUI, or you might need to implement platform-specific optimizations for performance reasons.

Adding Platform-Specific Code

To add platform-specific code in a .NET MAUI project, you can use partial classes, conditional compilation, or dependency injection. Let’s dive into each method with examples.

1. Partial Classes

Partial classes allow you to split the implementation of a class across multiple files. This is useful for separating platform-specific code.

Example:

Create a partial class in the shared project:

// Shared project
public partial class PlatformService
{
    public void ShowPlatformMessage();
}

Implement the platform-specific code in the platform projects:

// Android project
public partial class PlatformService
{
    public void ShowPlatformMessage()
    {
        Android.Widget.Toast.MakeText(
        Android.App.Application.Context, 
        "Hello from Android!", 
        Android.Widget.ToastLength.Short).Show();
    }
}

// iOS project
public partial class PlatformService
{
    public void ShowPlatformMessage()
    {
        var alert = new UIKit.UIAlertView(
        "Hello from iOS!", "", null, "OK", null);
        alert.Show();
    }
}

2. Conditional Compilation

Conditional compilation allows you to include or exclude code based on the target platform. However, in my experience, using conditional compilation can make the code harder to read, especially in larger classes.

Example:

public void ShowPlatformMessage()
{
#if ANDROID
    Android.Widget.Toast.MakeText(Android.App.Application.Context, "Hello from Android!", Android.Widget.ToastLength.Short).Show();
#elif IOS
    var alert = new UIKit.UIAlertView("Hello from iOS!", "", null, "OK", null);
    alert.Show();
#endif
}

3. Dependency Injection

Dependency injection is a design pattern that allows you to inject dependencies into a class, making it easier to manage platform-specific implementations. I often found myself using a mixture of the separate file and dependency injection approaches.

Example:

Define an interface in the shared project:

// Shared project
public interface IPlatformService
{
    void ShowPlatformMessage();
}

Implement the interface in the platform projects:

// Android project
public class AndroidPlatformService : IPlatformService
{
    public void ShowPlatformMessage()
    {
        Android.Widget.Toast.MakeText(Android.App.Application.Context, "Hello from Android!", Android.Widget.ToastLength.Short).Show();
    }
}

// iOS project
public class iOSPlatformService : IPlatformService
{
    public void ShowPlatformMessage()
    {
        var alert = new UIKit.UIAlertView("Hello from iOS!", "", null, "OK", null);
        alert.Show();
    }
}

// MauiProgram.cs
public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()
            .ConfigureServices(services =>
            {
#if ANDROID
                services.AddSingleton<IPlatformService, AndroidPlatformService>();
#elif IOS
                services.AddSingleton<IPlatformService, iOSPlatformService>();
#endif
            });

        return builder.Build();
    }
}

Use the platform-specific service in your shared code:

// Shared project
public class MainPageViewModel
{
    private readonly IPlatformService _platformService;

    public MainPageViewModel(IPlatformService platformService)
    {
        _platformService = platformService;
    }

    public void ShowMessage()
    {
        _platformService.ShowPlatformMessage();
    }
}

Caveat: Testing Platform-Specific Code

One important caveat to keep in mind is that platform-specific code can be more challenging to test compared to cross-platform code. This is because platform-specific code often relies on native APIs and behaviours that are not easily replicated in a test environment. To mitigate this, you can:

Use dependency injection to abstract platform-specific code, making it easier to mock and test.
Write unit tests for the shared logic and use integration tests for platform-specific code.
Utilise platform-specific testing tools and frameworks to test native functionalities.

Upcoming Changes in .NET MAUI 9

In .NET MAUI 9, Microsoft is reintroducing a separate project approach for platform-specific code, which feels more like the Xamarin way. This change will likely alter how you interact with your platform-specific code, making it more organised and potentially easier to manage. This approach can help in keeping platform-specific code isolated, improving readability and maintainability.

Conclusion

Adding platform-specific code to a .NET MAUI project allows you to leverage the full power of native APIs and functionalities. By using partial classes, conditional compilation, and dependency injection, you can effectively manage platform-specific implementations. However, be aware of the challenges in testing platform-specific code and plan your testing strategy accordingly. With the upcoming changes in .NET MAUI 9, the process of handling platform-specific code will evolve, offering a more structured approach.

Happy coding! 🚀

Why having a page factory is a good idea

Thomas M — Wed, 30 Oct 2024 08:05:43 +0000

Enhancing Testability in MAUI Applications with a View Factory

In the world of software development, ensuring that our code is testable is paramount to maintaining high-quality standards. When working with .NET MAUI (Multi-platform App UI) applications, I encountered a significant challenge: making our view-models more testable. The solution I found was implementing a view factory, a technique often considered an anti-pattern but proved to be a vital piece in our development puzzle.

The Challenge: Testability in MVVM

In a typical MVVM (Model-View-ViewModel) architecture, view-models are responsible for handling the logic and data-binding for views. However, injecting views directly into view-models can make unit testing cumbersome and less effective. This is because the tight coupling between views and view-models introduces dependencies that are hard to mock or isolate during testing.

The Solution: Implementing a View Factory

To address this, I implemented a view factory in our MAUI application. While view factories are often seen as an anti-pattern due to their potential to obscure dependencies and making code harder to understand, in our case, it was a game-changer. Here’s why:

Decoupling Views and View-Models: By using a view factory, I could obtain pages through the service provider rather than injecting them directly into the view-models. This decoupling allowed us to isolate view-models from their views, making them easier to unit test.
Leveraging the Service Provider: MAUI’s built-in dependency injection system enabled us to use the service provider to create instances of our views. This approach ensured that our view-models remained agnostic of the specific views they were associated with, further enhancing testability.
Improved Unit Testing: With the view factory in place, I could mock the service provider and the views it created. This allowed us to write comprehensive unit tests for our view-models without worrying about the complexities of the UI layer. As a result, I could focus on testing the business logic and data-binding aspects of our view-models, leading to higher quality assurance.

How this looks in code

Creating the View Factory

The first thing we need to do is to create a View Factory and interface it like in the examples below:

namespace MyApp.Views;

public class ViewFactory : IViewFactory
{
    private readonly IServiceProvider _serviceProvider;

    public ViewFactory(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    TView IViewFactory.CreateView<TView>() where TView : default => _serviceProvider.GetRequiredService<TView>();
}

namespace MyApp.Views;

public interface IViewFactory
{
    TView CreateView<TView>();
}

The above code injects the IServiceProvider into the factory, and accepts a generic view type that the service provider will use to create the view

Plumbing this into the App

Once we have created the ViewFactory class and interface we will then want to register it as a service in our Maui Program file like in the example below

// Reference any supporting imports

namespace MyApp;

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()
            // any other supporting added services
            .RegisterServices();

        return builder.Build();
    }

    public static MauiAppBuilder RegisterServices(this MauiAppBuilder mauiAppBuilder)
    {
        mauiAppBuilder.Services.AddSingleton<IViewFactory, ViewFactory>();

        return mauiAppBuilder;
    }
}

Using the factory in a view-model

Once the service is registered you can now use it in your view-models to get pages without injecting the view directly.


using MyApp.Views;

namespace MyApp.ViewModels;

public partial class PageViewModel : ViewModelBase
{
    private readonly IViewFactory _viewFactory;
    private readonly IAppNavigationService _appNavigationService;

    public PageViewModel(
        IViewFactory viewFactory,
        IAppNavigationService appNavigationService)
    {
        _viewFactory = viewFactory;
        _appNavigationService = appNavigationService;
    }

    [RelayCommand]
    private async Task LoadNextPage()
    {
        await _appNavigationService.PushNewPage(_viewFactory.CreateView<SecondPage>()).PreserveThreadContext();
    }

}

In the above example you can see we are injecting our IViewFactory into the view model and we are using it to create a view for our second page and pushing that to our navigation service instead of injecting the Second page into the view-model. This IViewFactory as it is injectable becomes mockable in a unit testing scenario.

Why I Recommend This Approach

For anyone developing an MVVM-based MAUI application, I highly recommend considering the implementation of a view factory. Despite its reputation as an anti-pattern, in the context of MAUI, it can be a powerful tool to enhance the testability of your view-models. By decoupling views from view-models and leveraging the service provider, you can achieve a more modular and testable codebase.

In conclusion, while the view factory might not be the go-to solution for every scenario, it proved to be invaluable in our MAUI application. It allowed us to write better unit tests, improve our code quality, and ultimately deliver a more robust application. If you’re facing similar challenges in your MAUI projects, give the view factory a try – it might just be the solution you need.

Streamlining MVVM in .NET MAUI with Relay Commands

Thomas M — Fri, 11 Oct 2024 08:18:59 +0000

Understanding Relay Commands in .NET MAUI

.NET MAUI simplifies the development of cross-platform apps with a modern, consistent API. One of the features that enhances the Model-View-ViewModel (MVVM) pattern in .NET MAUI is the use of relay commands. These commands help to bind user actions on the view to methods defined in the ViewModel.

What are Relay Commands?

Relay commands are a type of ICommand implementation that allows you to bind the UI events to commands in your ViewModel, eliminating the need for event handlers and making your code cleaner and more maintainable. They are particularly useful in MVVM applications where you want to keep a strict separation of concerns between the view and the ViewModel.

How Relay Commands Work

The RelayCommand attribute can be used to annotate methods in a partial class, which will automatically generate the necessary command properties. For example:

[RelayCommand]
private void GreetUser()
{
    Console.WriteLine("Hello!");
}

This will generate a command property in your ViewModel that you can bind to from your view.

Command Parameters and Asynchronous Commands

Relay commands can also work with parameters and asynchronous methods. When a method has a parameter, the generated command will be of type IRelayCommand<T>, where T is the type of the parameter1. For asynchronous methods, the command will implement IAsyncRelayCommand or IAsyncRelayCommand<T> if it has a parameter.

The Prism Approach

Prism is a well-known framework for building loosely coupled, maintainable, and testable applications in WPF, Xamarin Forms, and now in .NET MAUI. It provides developers with a robust set of tools to implement the MVVM pattern, including DelegateCommand and CompositeCommand for handling commands within the ViewModel. However, this approach often requires a considerable amount of boilerplate code, which can be cumbersome and increase the complexity of the application.

How .NET MAUI’s MVVM Toolkit Reduces Code

The .NET MAUI MVVM approach, powered by the Microsoft MVVM Toolkit, simplifies command implementation through the use of relay commands. This reduces the need for the verbose code that is typically associated with the Prism approach. Here’s how:

Less Boilerplate: Relay commands require less boilerplate code than Prism’s DelegateCommand, as they don’t need explicit implementation of CanExecute and Execute methods.
No Event Handlers: Relay commands eliminate the need for event handlers in the code-behind, which are often required in Prism to invoke commands.
Simplified Command Execution: The execution of commands is more straightforward with relay commands, as they allow direct method calls within the ViewModel.

Example: Simplified Command Implementation

Here’s a side-by-side comparison of a command implementation using Prism and .NET MAUI’s relay commands:

// Prism approach
public class MyViewModel : BindableBase
{
    private DelegateCommand _myCommand;
    public DelegateCommand MyCommand =>
        _myCommand ?? (_myCommand = new DelegateCommand(ExecuteCommand, CanExecuteCommand));

    private void ExecuteCommand() { /* Command logic */ }
    private bool CanExecuteCommand() { /* CanExecute logic */ }
}

// .NET MAUI's relay command approach
public partial class MyViewModel
{
    [RelayCommand]
    private void MyCommand()
    {
        // Command logic here
    }
}

As demonstrated, the .NET MAUI approach results in a more concise and readable ViewModel.

The Microsoft MVVM Toolkit Framework

The Microsoft MVVM Toolkit framework is a set of tools that simplifies the implementation of the MVVM pattern in .NET applications. It provides developers with a robust foundation for building responsive, maintainable, and testable applications. The toolkit includes features like ObservableObject, RelayCommand, and AsyncRelayCommand, which are essential for creating a clean and efficient ViewModel.

How .NET MAUI Adopts the MVVM Toolkit

.NET MAUI’s MVVM approach is heavily influenced by the Microsoft MVVM Toolkit framework. It leverages the toolkit’s features to streamline the development process and reduce the boilerplate code typically associated with MVVM applications. This allows developers to focus more on the business logic rather than the intricacies of the MVVM implementation.

For example, the RelayCommand attribute in .NET MAUI is a direct adoption from the MVVM Toolkit. It automatically generates command properties, thus removing the need for manual implementation of ICommand properties and the associated CanExecute and Execute methods.

Benefits of Using the MVVM Toolkit in .NET MAUI

By incorporating the Microsoft MVVM Toolkit framework, .NET MAUI offers several advantages:

Simplified ViewModel: The use of source generators and attributes provided by the MVVM Toolkit reduces the complexity of the ViewModel.
Enhanced Maintainability: With less code to manage, the ViewModel becomes easier to maintain and evolve over time.
Improved Testability: The separation of concerns is more pronounced, making it easier to write unit tests for the ViewModel and Model.
Streamlined Development: Developers can quickly scaffold new features without worrying about the underlying command infrastructure.

Conclusion

The adoption of the Microsoft MVVM Toolkit’s relay commands in .NET MAUI has taken the complexity out of the MVVM pattern. By reducing the amount of code required for command implementation, developers can enjoy a more streamlined development experience, allowing them to focus on creating feature-rich and responsive applications.

Embracing the Blazor Hybrid Approach in .NET MAUI

Thomas M — Fri, 11 Oct 2024 08:01:30 +0000

.NET MAUI has introduced a game-changing approach to cross-platform development with its Blazor Hybrid model. This innovative framework combines the best of both worlds: the rich ecosystem of .NET with the flexibility and familiarity of web technologies. Let’s dive into the benefits of this approach and how it can streamline your development process.

Leveraging npm Packages for Style Consistency

One of the standout features of the Blazor Hybrid approach is the ability to incorporate npm packages into your project. This is particularly beneficial when you want to maintain style consistency across different platforms. For instance, if you have a front-end library used in your web app, you can easily share the same styles in your MAUI app, ensuring a uniform look and feel.

Integrating npm into Your MAUI Project

To add npm into your MAUI project, you’ll need to follow these steps:

Initialize npm in your project directory:

npm init -y

This command creates a package.json file in your project.
Install your desired front-end library:

npm install your-library-name

Replace your-library-name with the actual library you wish to use.
Build your JavaScript library:

npm run build

This command compiles your JavaScript and CSS assets, based on the scripts defined in your package.json.
Include the compiled library in your index.html file:HTML

<link rel="stylesheet" href="path/to/your-library.css"> <script src="path/to/your-library.js"></script>

By following these steps, you can seamlessly integrate front-end libraries into your MAUI app, enhancing style consistency and reducing development time.

Accessibility Considerations

Accessibility is a crucial aspect of application development. The Blazor Hybrid approach in MAUI allows developers to leverage web standards for accessibility, such as ARIA (Accessible Rich Internet Applications) attributes, ensuring that the app is usable by people with various disabilities.

HTML vs. XAML: Catering to Front-End Developers

A significant advantage of the Blazor Hybrid model is that it caters to developers who are more comfortable with HTML and CSS than XAML. This familiarity allows front-end developers to jump into MAUI development with minimal learning curve, utilizing their existing skills to create rich user interfaces.

Integrating BlazorWebView in XAML

When working with the Blazor Hybrid approach in .NET MAUI, you can integrate your Blazor components directly into your XAML files using the BlazorWebView component. This allows you to leverage the full power of Blazor within your MAUI app.

Here’s an example of how to add a BlazorWebView to your XAML:

XAML

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:local="clr-namespace:YourAppNamespace"
             xmlns:blazor="clr-namespace:Microsoft.AspNetCore.Components.WebView.Maui;assembly=Microsoft.AspNetCore.Components.WebView.Maui"
             x:Class="YourAppNamespace.MainPage">

    <blazor:BlazorWebView HostPage="wwwroot/index.html">
        <blazor:BlazorWebView.RootComponents>
            <blazor:RootComponent Selector="#app" ComponentType="{x:Type local:Main}" />
        </blazor:BlazorWebView.RootComponents>
    </blazor:BlazorWebView>

</ContentPage>

In this snippet:

The xmlns:blazor namespace is declared to reference the Blazor components.
The BlazorWebView tag specifies the host page that will be displayed within the MAUI app.
The RootComponent tag within BlazorWebView.RootComponents defines the Blazor component to be used, which is referenced by its selector (in this case, #app).

To then register the use of this package you should ensure to add it into your Maui program file

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()

        builder.Services.AddMauiBlazorWebView();

        return builder.Build();
    }

By adding this code to your MAUI app, you can seamlessly integrate Blazor components, enabling you to use standard web technologies like HTML and CSS for your UI.

Navigating the Drawbacks

While the Blazor Hybrid approach offers numerous benefits, it’s not without its drawbacks. Navigation can become more complex, especially when dealing with navigation inside a Blazor WebView and between navigation pages within the app. Developers need to carefully manage routing to ensure a smooth user experience.

Conclusion

The Blazor Hybrid approach in .NET MAUI presents a compelling option for developers looking to create cross-platform applications with shared styles and reduced development time. By embracing web technologies, developers can build accessible, consistent, and visually appealing apps while leveraging their existing front-end expertise. Despite some challenges with navigation, the benefits of this approach make it a worthy consideration for your next project.

Migrating from Xamarin to .NET MAUI: A Journey to Modernization

Thomas M — Fri, 11 Oct 2024 07:59:33 +0000

As the Xamarin framework approached its end of life in May 2024, the need to migrate applications to a more current and supported framework became a pressing concern for developers seeking continued security updates and access to new features. This blog post outlines my journey of migrating an application from Xamarin to .NET MAUI, the challenges faced, and the strategic decisions that led to a successful transition.

The Impetus for Migration

The announcement of Xamarin’s end of life set the stage for a necessary migration. The primary goal was to ensure that the application remained within a supported ecosystem, benefiting from security updates and the rich new features that come with active development.

Evaluating Migration Approaches

Initially, I explored several migration strategies, including the use of automated migration tools. However, these tools often resulted in a multitude of errors and a fragmented codebase that was difficult to manage. The scattered approach left much to be desired, prompting a reevaluation of the strategy.

Embracing a Full Rewrite in .NET MAUI

After careful consideration, I decided to undertake a full rewrite of the application code into the .NET MAUI framework. This approach allowed for a clearer migration path, enabling me to move the application in sections and conduct incremental testing. It also provided an opportunity to address and fix many of the issues that were problematic in Xamarin, resulting in a more robust and reliable application.

The Shift to Blazor Hybrid and MVVM

The migration journey was also an opportune time to modernize the application’s architecture. I chose to adopt the Blazor Hybrid approach, which allowed for the use of HTML and CSS—technologies that are widely familiar to many developers, more so than XAML. This shift not only enhanced the developer experience but also improved the application’s maintainability and scalability.

Furthermore, the transition to .NET MAUI was complemented by a move from the MVP (Model-View-Presenter) pattern to an MVVM (Model-View-ViewModel) architecture using the MVVM Toolkit. This change facilitated a cleaner separation of concerns, improved testability, and allowed for more intuitive data binding and UI updates.

The Outcome and Future Insights

The decision to rewrite the application and embrace a Blazor Hybrid model with MVVM was not without its challenges and required a significant investment of time. However, the outcome has been overwhelmingly positive. The application now stands on a modern, scalable, and flexible foundation, ready to evolve with the ever-changing landscape of technology.

I am very pleased with the results of this migration and look forward to sharing more insights in future blog posts. I’ll delve into the benefits and any obstacles encountered during this transition, providing a comprehensive look at the migration process for those considering a similar path.

Stay tuned for more updates on this journey of application transformation.