Playing local audio files with .NET MAUI

Previously I wrote about playing audio with .NET MAUI on Android, iOS, Mac Catalyst, and Windows. The main problem with my implementation was that the FilePicker for picking local audio files only worked on Windows. On iOS/Android it let you browse the device, and displayed audio files, but it didn’t let you select an audio file. On Mac Catalyst it did nothing at all. I was convinced these were MAUI bugs. Turns out I was completely wrong!

The problem was this block of code:

var pickedAudio = await FilePicker.Default.PickAsync(new PickOptions
{
	PickerTitle = "Select audio file",
	FileTypes = new FilePickerFileType(
		new Dictionary<DevicePlatform, IEnumerable<string>>
		{
			{ DevicePlatform.WinUI, new [] { "*.mp3", "*.m4a" } },
			{ DevicePlatform.Android, new [] { "*.mp3", ".3gp", ".mp4", ".m4a", ".aac", ".ts", ".amr", ".flac", ".mid", ".xmf", ".mxmf", ".rtttl", ".rtx", ".ota", ".imy", ".mkv", ".ogg", ".wav" } },
			{ DevicePlatform.iOS, new[] { "*.mp3", "*.aac", "*.aifc", "*.au", "*.aiff", "*.mp2", "*.3gp", "*.ac3" } }
		})
});

The problem was ultimately caused by the order in which I wrote and tested the code on each platform. I did Windows first, followed by Android and iOS. Also, note the lack of an entry for Mac Catalyst.

So, I started off by adding code for Windows and specified *.mp3 and *.m4a as the file extensions to display in the FilePicker. This was purely because I couldn’t find any docs on which audio file formats are supported in WinUI 3. I got the MauiAudioPlayer working on Windows using these file extensions and moved onto Android.

I assumed that I could just use the same file extensions on Android and iOS. I managed to find docs from Google and Apple that mentioned the audio file formats they supported, and what their file extensions are, hence the more extensive entries for each platform. The issue was that I didn’t know that file picking on Android and iOS, using FilePicker and FilePickerFileType, doesn’t require an array of file extensions.

It was Gerald who alerted me to this, by pointing to the Xamarin.Essentials PickOptions.FileTypes API docs. Sure, it’s for Xamarin.Essentials rather than .NET MAUI but the same content applies. Specifically:

On Android and iOS the files not matching this list is only displayed
grayed out. When the array is null or empty, all file types can be
selected while picking. The contents of this array is platform
specific; every platform has its own way to specify the file types. On
Android you can specify one or more MIME types, e.g. “image/png”; also
wild card characters can be used, e.g. “image/*”. On iOS you can
specify UTType constants, e.g. UTType.Image. On UWP, specify a list of
extensions, like this: “.jpg”, “.png”.

So there’s the answer: on Android you specify the file types as MIME types, and wild cards can be used. On iOS you specify UTType constants, and on Windows you use file extensions.

I looked at common MIME types and discovered that for audio the MIME types are entries like audio/aac, audio/mpeg etc. When combined with wildcards it meant that the MIME type for all audio files supported by a platform is audio/*. So this became the string entry in the FilePickerFileType dictionary for Android.

iOS was a thornier problem. UTType constants are the recommended approach and are documented here. The problem I have with this approach is it requires iOS14+. I wanted my code to work with all versions of iOS that MAUI supports (which the docs says is iOS10+). On a random StackOverflow post I read that you could use system-defined uniform type identifiers to specify which files can be selected, which lead me to Apple’s System-declared Uniform Type Identifiers doc. A quick search of the doc revealed that the correct constant for audio files is public.audio. So this became the string entry in the FilePickerFileType dictionary for iOS, that I also duplicated for Mac Catalyst.

This lead to the following code:

var pickedAudio = await FilePicker.Default.PickAsync(new PickOptions
{
	PickerTitle = "Select audio file",
	FileTypes = new FilePickerFileType(
		new Dictionary<DevicePlatform, IEnumerable<string>>
		{
			{ DevicePlatform.WinUI, new [] { "*.mp3", "*.m4a" } },
			{ DevicePlatform.Android, new [] { "audio/*" } },
			{ DevicePlatform.iOS, new[] { "public.audio" } },
			{ DevicePlatform.MacCatalyst, new[] { "public.audio" } }
		})
});

When combined with a couple of small updates to MauiAudioPlayer on iOS/Android/Mac Catalyst, to correctly load the selected file, all platforms gained the ability to play locally stored audio files. The PR of changes to enable this can be found here.

So there we have - a .NET MAUI audio player for iOS, Android, Mac Catalyst, and Windows, that plays audio from URLs, audio embedded in your app package, and local audio files on your device that can be chosen by the user. You can find the code here.

Playing audio with .NET MAUI

Many apps, whether mobile or desktop, require the ability to play audio. That audio may be remote, stored in the app bundle, or be chosen from the user’s device. However, .NET MAUI currently doesn’t have a cross-platform control capable of playing audio. However, all of the underlying platforms that .NET MAUI supports have native controls for playing audio. Android has MediaPlayer, iOS/Mac Catalyst has AVPlayer, and WinUI has MediaPlayerElement (only available in WinAppSDK 1.2-preview).

I’ve used these native types to create a cross-platform Audio control. It’s based on the Video control I created a month or two ago (see Playing video with .NET MAUI and Playing video with .NET MAUI on Windows). It plays audio from URLs, from audio embedded in your app package (and hence embedded in your single project), and files chosen by the user on your device. As well as using the in-built transport controls to control audio playback, you can provide your own transport controls.

Are there code sharing opportunities between my Audio and Video controls? Yes. The code to play audio on iOS/Mac/Windows is 99% identical to the code to play video on iOS/Mac/Windows. Similarly, the cross-platform Audio control is a renamed version of the cross-platform Video control. The big difference is audio and video playback on Android. The Video control uses an Android VideoView, combined with a MediaController, while the Audio control uses an Android MediaPlayer, combined with a MediaController. It’ll be possible to merge the two controls into a single Media cross-platform control, capable of playing video and audio. Will I be doing this? Maybe at some point. Just not now.

You can download the control from its GitHub repo.

An alternative approach to playing audio in a .NET MAUI app is to use Plugin.Maui.Audio, created by Gerald Versluis and Shaun Lawrence. Are there any code similarities between Plugin.Maui.Audio and what I’ve done? Not really. Plugin.Maui.Audio uses different types to play audio on iOS/Mac/Windows than I’ve used, requires you to provide your own transport controls, and doesn’t use handlers.

Handler architecture

.NET MAUI has an extension mechanism, known as handlers, that you can use to customise existing .NET MAUI controls, and write your own cross-platform views (controls) whose implementations are provided by native views (controls).

Each .NET MAUI cross-platform control is known as a virtual view. Handlers map these virtual views to native views on each platform, and are responsible for creating the underlying native view, and mapping their API to the cross-platform control. Each handler typically provides a property mapper, and potentially a command mapper, that maps the cross-platform view API to the native view API.

The following diagram shows the handler architecture for the Audio view:

The Audio type represents the cross-platform control. On iOS/Mac Catalyst the AudioHandler maps the Audio view to an iOS/Mac Catalyst AVPlayer. On Android, the Audio view is mapped to a MediaPlayer, and on WinUI the Audio view is mapped to a MediaPlayerElement.

The PropertyMapper in the AudioHandler class maps the cross-platform view properties to native view APIs via mapper methods. Each platform then provides implementations of the mapper methods, which manipulate the native view API as appropriate. The overall effect is that when a property is set on the cross-platform view, the underlying native view is updated as required.

The CommandMapper in the AudioHandler class maps cross-platform view commands to native view APIs via mapper methods. Command mappers provide a way for cross-platform controls to send commands to native views on each platform. They’re similar to property mappers, but allow for additional data to be passed. Note that commands, in this context, doesn’t mean ICommand implementations. In this context, a command is just a way of invoking some functionality on a native control. For example, the ScrollView in .NET MAUI uses a command mapper so that the ScrollView asks its handler to instruct the native views to scroll to a specific location, passing along the scroll arguments (such as the position or element it wants to scroll to). The ScrollView handler on each platform unpacks the scroll arguments and invokes native view functionality to perform the desired scroll. This was analogous in Xamarin.Forms to having an event on the cross-platform view, with the renderer subscribing to the event. The advantage of the command mapper approach is that it decouples the native view from the cross-platform view, and avoids the need to unsubscribe from events. It also allows for easy customisation - the command mapper can be modified by consumers without subclassing.

Handler implementations on each platform must override the CreatePlatformView method, and optionally the ConnectHandler and DisconnectHandler methods. The CreatePlatformView method should return the native view that implements the cross-platform view. The ConnectHandler method should perform any required native view setup, and the DisconnectHandler method should perform any required native view cleanup. Note that the DisconnectHandler override is intentionally not invoked by .NET MAUI - you have to invoke it yourself from a suitable place in your app’s lifecycle.

Code

I’m not going to provide a walkthrough of the code. But you can download it, and step through it yourself, by cloning the repo. However, I’ll give you some pointers to working through the code.

The solution is structured as follows:

The important folders in the solution are:

• Controls - the cross-platform view implementation.

  

  The Audio class derives from .NET MAUI’s View class, provides the cross-platform implementation, and is a collection of BindableProperty objects and public methods.

• Handlers - the handler implementation.

  

  The AudioHandler class is a partial class, whose platform-specific implementations are in the AudioHandler.Android.cs, AudioHandler.MaciOS.cs and AudioHandler.Windows.cs files. The AudioHandler class exposes a VirtualView property that can be used to access the cross-platform view from the handler/native view layer. It also exposes a PlatformView property that can be used to access the native view that implements the Audio view.

• Platforms - the native view implementations.

  

  Rather than implement the native views directly in the handler, I’ve split them out into native view implementations named MauiAudioPlayer. On Android, MauiAudioPlayer derives from CoordinatorLayout and uses a MediaPlayer (along with a MediaController). On Android there’s also an AudioProvider class, which is a content provider that retrieves the embedded audio files from the assets folder of its bundle. On iOS/Mac Catalyst, MauiAudioPlayer derives from UIView and uses an AVPlayer (along with an AVPlayerViewController for the transport controls). On Windows, MauiAudioPlayer derives from Grid and uses a MediaPlayerElement.

• Resources/Raw - three embedded audio files.

  

  The audio files have a build action of MauiAsset.

• Views - pages that exercise the Audio view. An event handler for the Unloaded event on each page invokes the DisconnectHandler override on AudioHandler.

A handler must be registered against its cross-platform view, and this takes place in MauiProgram.cs with the ConfigureMauiHandler/AddHandler methods.

On iOS, I modified the ContentOverlayView of the AVPlayerViewController object to display an image (the idea being you could display something that represents the audio being played - any UIView-derived object):

UIImageView imageView = new UIImageView();
imageView.Image = UIImage.FromBundle("dotnet_bot.png");
imageView.ContentMode = UIViewContentMode.ScaleAspectFit;
_playerViewController.ContentOverlayView.AddSubview(imageView);

imageView.TranslatesAutoresizingMaskIntoConstraints = false;
imageView.BottomAnchor.ConstraintEqualTo(_playerViewController.ContentOverlayView.BottomAnchor).Active = true;
imageView.TopAnchor.ConstraintEqualTo(_playerViewController.ContentOverlayView.TopAnchor).Active = true;
imageView.LeadingAnchor.ConstraintEqualTo(_playerViewController.ContentOverlayView.LeadingAnchor).Active = true;
imageView.TrailingAnchor.ConstraintEqualTo(_playerViewController.ContentOverlayView.TrailingAnchor).Active = true;

This code retrieves the dotnet_bot image that’s stored in the Resources\Raw folder of the project, from the app bundle (where it’s copied to at build time), and centers it in the ContentOverLay view of the AVPlayerViewController object using constraints. This makes the audio player look less plain:

Next steps

There are a couple of issues I’m aware of in the implementation. Firstly, the FilePicker, for selecting an audio file from the device, only works on Windows. On iOS/Android it lets you browse the device, but won’t let you select a file. On Mac Catalyst, it does nothing. At the moment I’ve yet to investigate whether these are MAUI bugs, or whether I’m doing something wrong/lacking a piece of config. Secondly, I’ve encountered a random crash on Android - I’m still trying to produce a firm repro case for it.

In addition, on Windows, the MediaPlayerElement seems to be reserving rendering space for a non-existent video. I need to look into whether there’s something I can do about that, or whether it’s due to MediaPlayerElement still being in preview.

Playing video with .NET MAUI on Windows

Previously I wrote about playing video with .NET MAUI on Android, iOS, and Mac Catalyst. The problem platform was Windows because WinUI 3 lacked any media playback controls. This has been rectified with the preview release of the WinAppSDK v1.2, which contains the MediaPlayerElement and MediaTransportControls types. If you want to know how to use these types, see Media players.

I’ve updated my VideoPlayer code with Windows support, so it’s now a truly cross-platform Video control. This includes the ability to play remote videos, videos embedded in the app, and video's from the file system. As with the other platforms, the MauiVideoPlayer class provides video playback capabilities on Windows. This class derives from Microsoft.UI.Xaml.Controls.Grid and adds a MediaPlayerElement to it (all WinUI controls must be in a layout, and so this mechanism ensures this will always be the case).

I also updated the code to remove the IVideo and IVideoHandler interfaces. After chatting to Shane I realised the interfaces weren’t necessary and weren’t adding anything. While .NET MAUI decouples its handlers from its cross-platform controls via interfaces, this is to enable experimental frameworks such as Comet and Fabulous to provide their own cross-platform controls, that implement the interfaces, while still using .NET MAUI’s handlers. Therefore, creating an interface for your cross-platform control is only necessary if you need to decouple your handler from its cross-platform control for a similar purpose, or for testing purposes.

My understanding is that v1.2 of the WinAppSDK will move out of preview by the end of the year, so there may be issues with MediaPlayerElement until then.

Behaviors library for .NET MAUI

Many years ago I wrote a behaviours library for Xamarin.Forms. The conventional view was that behaviours extend the functionality of controls, with typical examples validating user text input. Inspired by the then Blend SDK, my thought was that behaviors can be split into two concepts. Behaviours are attached to a control and listen for something to happen. When the something happens, it triggers one or more actions in response. So actions are invoked by behaviours and executed on a specified control. Typical behaviors are listening for an event firing, or data changing. Typical actions are invoking a command, invoking a method, setting a property etc.

I ended up producing a behaviours library for Xamarin.Forms, based on the Blend SDK, that I shipped on NuGet and for a while it was moderately successful. I updated it from time to time, but eventually forgot all about it.

I’ve now resurrected it for .NET MAUI. But I’m not going to ship it as a NuGet. Doing so for the previous version caused me lots of work that I’d like to avoid now.

What is it?

Behaviours for .NET MAUI is a class library I’ve created that can be consumed by .NET MAUI apps. It supports the following scenarios:

• Invoking commands from XAML when an event fires or when data changes.
• Invoking methods from XAML (in the view or view model) when an event fires or when data changes.
• Setting properties from XAML (in the view or view model) when an event fires or when data changes.
• Invoke animations from XAML, including compound animations, when an event fires or when data changes.
• Triggering a specified VisualState on a VisualElement from XAML, when an event fires or when data changes.

The result of using the library is that you can eliminate lots of boiler plate C# code, instead moving it to XAML.

Behaviours

The library contains the following behaviours:

• EventHandlerBehavior - listens for a specific event to occur, and executes one or more actions in response.
• DataChangedBehavior - listens for the bound data to meet a specified condition, and executes one or more actions in response.

Actions

The library contains the following actions:

• InvokeCommandAction - executes a specified ICommand when invoked.
• InvokeMethodAction - executes a method on a specified object when invoked.
• SetPropertyAction - changes a specified property to a specified value.
• FadeAction - performs a fade animation when invoked,
• RotateAction - performs a rotate animation when invoked.
• ScaleAction - performs a scale animation when invoked.
• TranslateAction - performs a translate animation when invoked.
• GoToStateAction - invokes visual state changes.

Where is it?

You can download the library and a sample that demos it from its repo.

How do I use it?

Using the library is a three step process:

1. Clone the library from its repo and add the BehaviorsLibrary class library project to your .NET MAUI solution.
2. Add a reference to the BehaviorsLibrary project to your app project.
3. Add an xmlns to the library to your XAML file, and then consume the required behaviors/actions from XAML.

The following code example shows an example of using the EventHandlerBehavior to invoke two commands:

<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:behaviors="clr-namespace:Behaviors;assembly=Behaviors"
             ...>

    <ContentPage.Resources>
        <converters:SelectedItemEventArgsToSelectedItemConverter x:Key="SelectedItemConverter" />
    </ContentPage.Resources>
	...
    <ListView x:Name="listView"
                 ItemsSource="{Binding People}">
        <ListView.Behaviors>
            <behaviors:EventHandlerBehavior EventName="ItemSelected">
                <behaviors:InvokeCommandAction Command="{Binding ItemSelectedCommand}"
                                               Converter="{StaticResource SelectedItemConverter}" />
                <behaviors:InvokeCommandAction Command="{Binding OutputAgeCommand}"
                                               Converter="{StaticResource SelectedItemConverter}"
                                               ConverterParameter="35" />
            </behaviors:EventHandlerBehavior>
        </ListView.Behaviors>
    </ListView>
</ContentPage>

In this example, when the ListView.ItemSelected event is raised, the ItemSelectedCommand and OutputAgeCommand are sequentially executed on the bound view model (the InvokeCommandAction class expects to find the Command objects on the BindingContext of the attached object). The advantage of this approach is that it enables commands to be associated with controls that weren’t designed to interact with commands, thereby removing boiler-plate event handling code from code-behind files.

In the coming weeks I’ll explore all the functionality the library offers in more detail.

Display a map with .NET MAUI

Many apps, whether mobile or desktop, require the ability to show a map. However, .NET MAUI doesn’t currently have a view (control) capable of displaying a map. That’s frustrating because the underlying platforms that .NET MAUI supports all largely have native map views. Android has the MapView. iOS/MacCatalyst has MKMapView. WinUI has…nothing.

So, most of the platforms .NET MAUI runs on can display a map, but .NET MAUI itself lacks a cross-platform view to display a map. Therefore I’ve created a very simple cross-platform Map view. It was written primarily for me to understand how to write handlers, rather than being a fully featured control. It displays a map, lets you scroll it, zoom it, show your location, show traffic data, and change the map imagery (street/satellite/hybrid). There’s plenty it doesn’t do - no initialising the map to a specific location, no map pins, no routes, no drawing on the map surface etc. A fully featured Map view is beyond the scope of what I was attempting to do, and besides, there will be one appearing in .NET MAUI in the not too distant future.

As it’s a simpler example than the Video view I published yesterday, I thought I’d share it.

Handler architecture

.NET MAUI has an extension mechanism, known as handlers, that you can use to customise existing .NET MAUI controls, and write your own cross-platform views whose implementations are provided by native views.

Each .NET MAUI view has an interface representation, that abstracts a cross-platform view. Cross-platform views that implement these interfaces are known as virtual views. Handlers map these virtual views to native views on each platform, and are responsible for creating the underlying native view, and mapping their API to the cross-platform control.

Handlers are accessed through their view-specific interface. This avoids the cross-platform view having to reference its handler, and the handler having to reference the cross-platform view. Each handler typically provides a property mapper, and sometimes a command mapper, that maps the cross-platform view API to the native view API.

The following diagram shows the handler architecture for the Map view:

The Map view implements the IMap interface. On iOS/MacCatalyst, the MapHandler class maps the cross-platform Map view to an iOS/MacCatalyst MKMapView. On Android, the Map view is mapped to a MapView that's provided by the Xamarin.GooglePlayServices.Maps NuGet package. There’s no Windows implementation, due to the lack of a map control on WinUI.

The PropertyMapper in the MapHandler class maps the cross-platform view properties to native view APIs via mapper methods. Each platform then provides implementations of the mapper methods, which manipulate the native view API as appropriate. The overall effect is that when a property is set on the cross-platform view, the underlying native view is updated as required.

Handler implementations on each platform must override the CreatePlatformView method, and optionally the ConnectHandler and DisconnectHandler methods. The CreatePlatformView method should return the native view that implements the cross-platform view. The ConnectHandler method should perform any required native view setup, and the DisconnectHandler method should perform any required native view cleanup. Note that the DisconnectHandler override is intentionally not invoked by .NET MAUI - you have to invoke it yourself from a suitable place in your app’s lifecycle.

Code

I’m not going to provide a walkthrough of the code. But you can download it, and step through it yourself, by cloning the repo. However, I will give you some pointers to working through the code.

The important files in the solution are highlighted below:

• Controls - the cross-platform view implementation. IMap abstracts the Map view and exposes members that the handler needs to be able to access, and derives from .NET MAUI’s View. The Map class, which derives from .NET MAUI’s View class, provides the cross-platform implementation, and is simply a collection of BindableProperty objects.
• Handlers - The IMapHandler interface, which derives from .NET MAUI’s IViewHandler, specifies VirtualView and PlatformView properties. The VirtualViewproperty is used to access the cross-platform view from the handler, and the PlatformView property is used to access the native view that implements the Map view. The MapHandler class is a partial class, whose platform-specific implementations are in the MapHandler.Android.cs, MapHandler.iOS.cs and MapHandler.Windows.cs files.

A handler must be registered against its cross-platform view, and this takes place in MauiProgram.cs with the ConfigureMauiHandler/AddHandler methods.

On Android you’ll need to insert your Google Map API key into the Android Manifest for the map to appear.

I hope this ends up being useful to folks on their journey to understand how to write custom controls backed by .NET MAUI handlers.

Playing video with .NET MAUI

Many apps, whether mobile or desktop, require the ability to play video. That video may be remote, stored in the app bundle, or be chosen from the user’s device. However, .NET MAUI currently doesn’t have a view (control) capable of playing video. That’s frustrating because the underlying platforms that .NET MAUI supports all largely have native views for playing video. Android has the VideoView. iOS/MacCatalyst has AVPlayer. WinUI has…nothing yet, but I understand it’s coming soon.

So, most of the platforms .NET MAUI runs on can play video, but .NET MAUI itself lacks a cross-platform view to play video. Therefore I’ve created a cross-platform Video view. It changed name as I iterated over it. It started out as VideoPlayer, changed to VideoView, then I settled on Video, purely because .NET MAUI’s image view is called Image. Obviously the Video view plays video. Specifically, it plays video from URLs, from videos embedded in your app package (and hence embedded in your single project), and files chosen by the user on your device. As well as using the in-built transport controls to control video playback, you can provide your own transport controls. Does it play audio? Potentially but I’ve not tried it. It will most likely require some work to turn it into a Media view.

Handler architecture

.NET MAUI has an extension mechanism, known as handlers, that you can use to customise existing .NET MAUI controls, and write your own cross-platform views whose implementations are provided by native views.

Each .NET MAUI view has an interface representation, that abstracts a cross-platform view. Cross-platform views that implement these interfaces are known as virtual views. Handlers map these virtual views to native views on each platform, and are responsible for creating the underlying native view, and mapping their API to the cross-platform control.

Handlers are accessed through their view-specific interface. This avoids the cross-platform view having to reference its handler, and the handler having to reference the cross-platform view. Each handler typically provides a property mapper, and potentially a command mapper, that maps the cross-platform view API to the native view API.

The following diagram shows the handler architecture for the Video view:

The Video view implements the IVideo interface. On iOS/MacCatalyst, the VideoHandler class maps the cross-platform Video view to an iOS/MacCatalyst AVPlayer. On Android, the Video view is mapped to a VideoView. There’s currently no WinUI implementation (due to the lack of a MediaElement control on WinUI) but I’ll add one once WinUI supports playing video.

The PropertyMapper in the VideoHandler class maps the cross-platform view properties to native view APIs via mapper methods. Each platform then provides implementations of the mapper methods, which manipulate the native view API as appropriate. The overall effect is that when a property is set on the cross-platform view, the underlying native view is updated as required.

The CommandMapper in the VideoHandler class maps cross-platform view commands to native view APIs via mapper methods. Command mappers provide a way for cross-platform controls to send commands to native views on each platform. They’re similar to property mappers, but allow for additional data to be passed. Note that commands, in this context, doesn’t mean ICommand implementations. In this context, a command is just a way of invoking some functionality on a native control. For example, the ScrollView in .NET MAUI uses a command mapper so that the ScrollView asks its handler to instruct the native views to scroll to a specific location, passing along the scroll arguments (such as the position or element it wants to scroll to). The ScrollView handler on each platform unpacks the scroll arguments and invokes native view functionality to perform the desired scroll. This was analogous in Xamarin.Forms to having an event on the cross-platform view, with the renderer subscribing to the event. The advantage of the command mapper approach is that it decouples the native view from the cross-platform view, and avoids the need to unsubscribe from events. It also allows for easy customisation - the command mapper can be modified by consumers without subclassing.

Handler implementations on each platform must override the CreatePlatformView method, and optionally the ConnectHandler and DisconnectHandler methods. The CreatePlatformView method should return the native view that implements the cross-platform view. The ConnectHandler method should perform any required native view setup, and the DisconnectHandler method should perform any required native view cleanup. Note that the DisconnectHandler override is intentionally not invoked by .NET MAUI - you have to invoke it yourself from a suitable place in your app's lifecycle.

Code

I’m not going to provide a walkthrough of the code. But you can download it, and step through it yourself, by cloning the repo. However, I will give you some pointers to working through the code.

The solution is structured as follows:

The important folders in the solution are:

• Controls - the cross-platform view implementation.

  

  IVideo abstracts the Video view and exposes members that the handler needs to be able to access, and derives from .NET MAUI’s IView. The Video class, which derives from .NET MAUI’s View class, provides the cross-platform implementation, and is a collection of BindableProperty objects, events, and public methods.

• Handlers - the handler implementation.

  

  The IVideoHandler interface, which derives from .NET MAUI’s IViewHandler, specifies VirtualView and PlatformView properties. The VirtualView property is used to access the cross-platform view from the handler/native view layer, and the PlatformView property is used to access the native view that implements the Video view. The VideoHandler class is a partial class, whose platform-specific implementations are in the VideoHandler.Android.cs, VideoHandler.iOS.cs and VideoHandler.Windows.cs files.

• Platforms - the native view implementations.

  

  Rather than implement the native views directly in the handler, I’ve split them out into native view implementations called MauiVideoPlayer. On Android, MauiVideoPlayer derives from RelativeLayout (for positioning the video on the page) and uses a VideoView to play videos (along with a MediaController for the transport controls). On Android there’s also a VideoProvider class, which is a content provider that retrieves the embedded video files from the assets folder of its bundle. On iOS/MacCatalyst, MauiVideoPlayer derives from UIView and uses an AVPlayer to play videos (along with an AVPlayerViewController for the transport controls).

• Resources/Raw - three embedded video files.

  

  The video files have a build action of MauiAsset.

• Views - pages that exercise the Video view. An event handler for the Unloaded event on each page invokes the DisconnectHandler override of the VideoHandler.

A handler must be registered against its cross-platform view, and this takes place in MauiProgram.cs with the ConfigureMauiHandler/AddHandler methods.

Next steps

There are currently two bugs I’m aware of in the implementation. Firstly, on Android the video is meant to be centred on the page, but it insists on aligning itself to the top of the page. I have suspicions for why this is happening. Secondly, on iOS, when using a Slider as a custom positioning bar, the scale of the Slider isn’t updated at runtime when setting its Maximum property. This makes it impossible right now to use a Slider to control the video’s position. I’ve pin pointed this to a bug in .NET MAUI on iOS, and logged it.

I’m planning on turning this into an official sample during August, and writing official docs on how to create custom controls using .NET MAUI handlers.

Implicit usings in .NET MAUI

.NET MAUI Preview 11 now uses implicit usings to reduce the number of using statements you need to specify at the top of each file. For more information about implicit usings, see this blog post.

Specifically, from Preview 11 onwards you don’t need to add using statements for the following namespaces, which are all now available implicitly in .NET MAUI projects:

• Microsoft.Extensions.DependencyInjection
• Microsoft.Maui
• Microsoft.Maui.Controls
• Microsoft.Maui.Controls.Hosting
• Microsoft.Maui.Controls.Xaml
• Microsoft.Maui.Graphics
• Microsoft.Maui.Essentials
• Microsoft.Maui.Hosting

If you’re new to .NET MAUI, implicit usings really make life easier as you don’t have to hunt around to find out which namespaces specific types are in. However, note that there are sometimes types you’ll need to use that do reside in other namespaces for which you’ll have to add using statements (e.g. the types in Microsoft.Maui.Layouts).

The project templates also now use file-scoped namespaces. All I’ll say is it’s a syntax I’m still getting used to.

.NET Android

.NET Android projects now include the following implicit usings:

• Android.App
• Android.Widget
• Android.OS.Bundle

Therefore, it’s not necessary to add using statements for the above namespaces.

.NET iOS

.NET iOS projects (and MacCatalyst, and tvOS) now include the following implicit usings:

• CoreGraphics
• Foundation
• UIKit

Therefore, it’s not necessary to add using statements for the above namespaces.

.NET macOS

.NET macOS projects now include the following implicit usings:

• AppKit
• CoreGraphics
• Foundation

Therefore, it’s not necessary to add using statements for the above namespaces.