.NET MAUI

.NET MAUI iOS Bug – Release Mode Bindings Not Working

by

Software bugs can sometimes manifest in specific environments or platforms, leading to unexpected behavior. In this blog post, we will discuss a bug in .NET MAUI specifically affecting iOS platforms. The bug causes bindings between Views and ViewModels to fail in Release mode, resulting in empty Views without the expected data. We’ll explore the symptoms of this bug and present a workaround that involves utilizing the XamlCompilation attribute with the Skip option.

Symptoms

The bug we are addressing affects the binding functionality in .NET MAUI apps running on iOS platforms in Release mode. When encountering this issue, Views fail to bind with their associated ViewModels, resulting in empty Views that appear as if no BindingContext is present.

What is XamlCompilation?

XamlCompilation is an attribute provided by Xamarin.Forms that allows developers to specify how XAML files should be compiled. It offers three options: None, XamlC, and Skip.

  • None: The default option. XAML files are not compiled individually and are interpreted at runtime.
  • XamlC: XAML files are compiled ahead-of-time into IL code, improving performance by eliminating the need for runtime interpretation.
  • Skip: XAML files are skipped from the compilation process and are interpreted at runtime, similar to the None option.

Providing workaround

To mitigate this bug, we can utilize the XamlCompilation attribute with the Skip option on the affected Views. This attribute is used to control the compilation behavior of XAML files in .NET MAUI applications.

Identify the Affected View First, identify the View(s) in your .NET MAUI app that are experiencing the binding issue specifically on iOS platforms in Release mode. Add XamlCompilation Attribute Add the XamlCompilation attribute to the affected View’s code-behind file. Set the attribute value to Skip to instruct the compiler to exclude the associated XAML file from the compilation process.

[XamlCompilation(XamlCompilationOptions.Skip)]
public partial class MyAffectedView : ContentView
{
    // ...
}

Ensure that the affected View is properly updated with the XamlCompilation attribute. Test the application in Release mode on iOS to confirm that the bindings are now functioning as expected and the Views are populated with the appropriate data.

Keep in mind that while this workaround provides a solution for the bug, it’s important to regularly check for updates from the .NET MAUI team, as they may address and fix this issue in future releases. Additionally, test your app thoroughly after applying the workaround to ensure the expected functionality and behavior across different platforms.

This content has 11 months. Some of the information in this post may be out of date or no longer work. Please, read this page keeping its age in your mind.

.NET MAUI: Bug – GestureRecognizers are not working on some views

by

In the world of software development, bugs can occasionally arise, causing unexpected behavior in our applications. In this blog post, we will explore a bug affecting TapGestureRecognizers in .NET MAUI apps, specifically on certain Views like frames. We’ll discuss the symptoms of this bug and provide a practical workaround to ensure that TapGestureRecognizers properly fire events or execute commands.

Symptoms

The bug we are addressing is related to TapGestureRecognizers not functioning as expected on specific Views, such as frames, in .NET MAUI apps. This issue prevents TapGestureRecognizers from triggering events or executing commands, leading to a loss of interactivity for the affected Views.

Workaround

To overcome this bug, we can utilize a simple workaround that involves creating a transparent BoxView on top of the desired interaction area. By setting the InputTransparent property of the BoxView to false, we allow it to capture touch events, effectively acting as an overlay for the affected View. We can then assign the TapGestureRecognizer to the transparent BoxView to regain the desired interactivity.

First, identify the View that is experiencing the issue with TapGestureRecognizers. In this example, let’s assume we have a Frame control that should respond to tap events but is currently affected by the bug. Add a Transparent BoxView Within the same container as the affected View, add a BoxView control. Set its BackgroundColor property to Transparent to ensure it remains invisible to the user. Assign TapGestureRecognizer to the Transparent BoxView Inside the GestureRecognizers collection of the transparent BoxView, assign the TapGestureRecognizer with the desired event handling or command execution logic. You can bind the command property to a command in your view model or handle the event in code-behind. Position the transparent BoxView over the affected View, ensuring that it covers the same area where the TapGestureRecognizer should have been applied. By making the BoxView transparent and setting InputTransparent to false, it allows touch events to pass through, reaching the TapGestureRecognizer.

<BoxView BackgroundColor="Transparent" InputTransparent="False">
    <BoxView.GestureRecognizers>
        <TapGestureRecognizer Command="{Binding YourCommand}" />
    </BoxView.GestureRecognizers>
</BoxView>

Note: It’s important to keep in mind that this workaround is intended as a temporary solution until the bug is officially addressed and fixed by the .NET MAUI team. Stay up to date with the latest releases and bug fixes to ensure that you can eventually transition to the official resolution. Please remember to regularly check the official .NET MAUI documentation, release notes, and bug tracking system for any updates regarding this bug and its resolution.

https://github.com/dotnet/maui/issues/8895#issuecomment-1301620712

This content has 11 months. Some of the information in this post may be out of date or no longer work. Please, read this page keeping its age in your mind.

.NET MAUI: Implementing Light and Dark Modes

by

In modern application development, providing users with the ability to switch between light and dark modes has become an essential feature. This functionality not only enhances user experience but also accommodates personal preferences and improves accessibility. In this blog post, we will explore how to implement light and dark modes in .NET MAUI apps using the UserAppTheme property in the App.xaml.cs file.

Understanding the App.xaml.cs File

The App.xaml.cs file in a .NET MAUI application is responsible for defining the application’s startup and initialization logic. It acts as the entry point for the application and provides a central location to handle events and configure application-wide settings.

Setting the UserAppTheme Property

To enable light and dark modes in your .NET MAUI app, you need to access the UserAppTheme property available in the Application.Current object. This property allows you to specify the desired theme for your application.

If your application does not allow the users to change the light/dark modes, but you want to force the app to be in a specified state, you can use the App.xaml.cs constructor, and you can set the UserAppTheme property to either AppTheme.Light or AppTheme.Dark, depending on a predefined default.

Here’s an example of how to set the AppTheme to Light mode:

Application.Current.UserAppTheme = AppTheme.Light;

Similarly, you can set the AppTheme to Dark mode:

Application.Current.UserAppTheme = AppTheme.Dark;
This content has 11 months. Some of the information in this post may be out of date or no longer work. Please, read this page keeping its age in your mind.

.NET MAUI: Save any type of object in Preferences

by

.NET MAUI currently have limitations of the supported types in preferences. They can only store simple data types such as strings, integers, and booleans, and do not support more complex data types such as lists or objects. This can make it difficult to store and retrieve more complex data structures.

How to store arrays and lists, or complex classes in Preferences?

The answer is currently to serialize it. Since Preferences is supporting string saving option, you can serialize your arrays and custom classes, and store the string value.

But be aware to store large amounts of data in Preferences as a string. Consider choosing SQLite to store data when there are more than 50-100 items in an array, or your class is more complex than having 25 properties. As Microsoft marks this as a limitation: Performance may be impacted if you store large amounts of text, as the API was designed to store small amounts of text.

But there are cases when it makes sense to store other types

There are cases when it is easier to store a whole complex object on disk than to store all its properties one by one by calling preferences Set. In this case you may find useful the banditoth.MAUI.PreferencesExtension.

Usage

This package is extending the basic functions of the built in MAUI Essentials IPreferences by letting the developers to save any type of object. This is done by using JSON serialization, and saving the raw jsons as strings with the default IPreferences implementation. Since JSON arrays can be serialized back to any collection type, you can use different types when Setting the value and when Getting it back.

There are several ways to access this extension.

Dependency Injection

    private readonly IPreferences preferences;

    public MainPage(IPreferences preferences)
    {
        InitializeComponent();
        this.preferences = preferences;
    }

    private void Foo()
    {
        List<string> taleItems = new List<string>()
        {
            "The quick brown fox",
            "Jumps over the lazy dog"
        };

        preferences.SetObject<List<string>>("Tale", taleItems);

        string[] taleItemsFromPreferences = preferences.GetObject<string[]>("Tale", null);
    }

Access through Preferences

If you are used to access the preferences trough the static class, you can use this tool by accessing the Default property on the Preferences class. You can call the SetObject or GetObject extension method on it.

            // Setting the value
            Preferences.Default.SetObject<IDeviceInfo>("Device_Information", DeviceInfo.Current);
            // Getting the value
            Preferences.Default.GetObject<IDeviceInfo>("Device_Information", null);

Package’s own static reference

You can also access the SetObject or GetObject method on PreferencesExtension static class.

            // Setting the value
            PreferencesExtension.SetObject<DisplayOrientation>("Last_Display_Orientation", orientation);
            // Getting the value
            PreferencesExtension.GetObject<DisplayOrientation>("Last_Display_Orientation", DisplayOrientation.Landscape);
This content has 1 year. Some of the information in this post may be out of date or no longer work. Please, read this page keeping its age in your mind.

Configure CI pipeline with .NET MAUI Release candidate (for NuGets)

by

In order to do automated builds in Azure DevOps with the .NET MAUI Release Candidate release, we need a few extra steps in the pipeline configuration. I used these steps to ensure that the NuGet packages I develop are automatically compiled and uploaded to NuGet.org. In this article I won’t go into detail about how to create a CI pipeline, I just want to show you the difference from a normal CI pipeline. I haven’t tried building and deploying applications in the cloud at the moment, but it can probably be done. Also, I don’t go into how to make the package automatically go to NuGet.org, for that I recommend an earlier article (and also how to create a CI/CD pipeline): https://www.banditoth.net/2021/11/09/azure-devops-setup-private-nuget-feed-with-ci/

Since a final version of .NET MAUI has not been released as of today, in order to build our applications in the cloud, we need to install the MAUI Workload on the Agent.
If we do not do this, we may encounter the following error:

Error NETSDK1147: To build this project, the following workloads must be installed: maui-windows

Adjust your pipeline

In order to install the workload on our build agent, create a new task at the very beginning in the pipeline file, which is executes a command in the command line:

This will result the following task in the yaml file:

- task: CmdLine@2
  inputs:
    script: 'dotnet workload install maui'

The installation of the workload will take about 5 minutes.

From now on, you will be able to use .NET Maui references on the pipelines too. This will let you build your packages in the cloud.
Once MAUI will be officially available, probably you don’t need these steps.

This content has 2 years. Some of the information in this post may be out of date or no longer work. Please, read this page keeping its age in your mind.