Maui Archives - XABLU

5 things for .NET MAUI devs to look forward to in 2022

Sebastián Pérez — Tue, 28 Dec 2021 16:21:49 +0000

The year 2021 has brought us a lot of news related to .NET 6. However, we are going to highlight some milestones that must be taken into account for next year:

1. .NET MAUI release: This year we had a working preview of .NET MAUI and a lot of announcements. However, we will have the release of this long-awaited framework for mobile cross-platform development by the middle of next year. If you can’t wait, stay tuned because a release candidate will be out very soon

2. Visual Studio 2022 for Mac: This tool, which was once known as Xamarin Studio, is used by developers who use MacOS environments. For this version 2022 a new version was created using native components to achieve an improvement in performance. The bad news are that we don’t have currently a stable version, but we will soon in 2022. If you want to try, you can find a preview version that can be downloaded here.

3. C#11: Although there is no official announcement of what will come in the next version of this programming language, some issues have already appeared in the Github repository that give us some clues. For example, the keyword field and list patterns, features that were left out of version 10. When ? Probably at .NET 7 release.

4. Microsoft Build 2022: Starting in Q2 2022 we will find Microsoft’s most important developer-oriented event: Microsoft Build. This event, that used to be face-to-face, adopted full-remote in recent years due to the pandemic and although there is no official announcement of the event, we can imagine that it will continue in the same way. In this event the releases roadmap is usually announced for the rest of the year, will it be the chance to see the stable version of .NET MAUI?

5. .NET 7 release: Although .NET 6 is a long support version, the roadmap for this technology tells us that in 2022 we will have version 7 available. This version will be very important for the integration of .NET MAUI, since it will be the first version that supports it from the beginning. When ? November 2022, and as expected a new edition of the .NET Conf will accompany this release.

What are you looking forward the most? I definitely vote .NET MAUI release !

On behalf of the Xablu team, we wish you a great 2022!

The post 5 things for .NET MAUI devs to look forward to in 2022 appeared first on XABLU.

.NET Conf 2021: Updates in .NET MAUI

Sebastián Pérez — Wed, 24 Nov 2021 13:13:08 +0000

In the previous post I shared the videos that I recommend to see of the conference, however we didn’t see anything on .NET MAUI. Why? First because I was planning to do it in this post, but mainly because we are still in a preliminary version of this new .NET component and there weren’t many announcements.

To start, if it is your first approach to .NET MAUI I recommend you to read this post and watch this video of the conference:

A very interesting functionality that was presented is to use the controls already known in Xamarin Forms but a drawn version instead of its native version:

Blazor + MAUI: We can write web applications with Blazor in the same way as we did before but adding the chance of deploy them also on mobile devices:

Finally I here you have some updates related to one of the most used libraries which was created and maintained by the community: (Former Xamarin Community Toolkit) .NET Maui Community Toolkit

Although there were no big announcements, this point helps us to catch up and be ready for when the stable version comes out next year. Stay connected !

The post .NET Conf 2021: Updates in .NET MAUI appeared first on XABLU.

.NET Conf 2021 is coming

Sebastián Pérez — Tue, 09 Nov 2021 16:58:32 +0000

As every year there will be a new edition of the most important .NET conference in the world: .NET Conf. This year will feature two tasty ingredients: the release of .NET 6 and … my first participation in the event

The conference will be held from November 9th to 11th and will focus mainly on what is new that introduces .NET 6. Also, it will introduce Visual Studio 2022 that has been recently released and we can see some news about .NET MAUI (preview 10). If you want to know more about the topics that will be presented I invite you to read these posts:

You can follow all the news of the event in the following link: .NET Conf 2021 (dotnetconf.net)

Finally, I invite you to be part of my presentation on “Creating NFT with .NET” next Thursday 11th at 6 am (PT) / 10 am (ARG) / 2 pm (NT). See you there !

The post .NET Conf 2021 is coming appeared first on XABLU.

.NET MAUI: Implementing platform behavior

Ruud Kobes — Fri, 17 Sep 2021 15:16:07 +0000

.NET MAUI is right around the corner. Like its predecessor it offers sharing most code while building for multiple platforms. This includes the UI part. Of course there are still elements that require access to the platform, like accessing the camera, or something less common like customizing HttpMessageHandler behavior on iOS.

For common use-cases Xamarin.Essentials was offered to Xamarin Forms users. Now with MAUI this library will be included in your application by default (named MAUI Essentials), making it easy to use SecureStorage or implement permissions on Android and iOS. Additionally there is a MAUI Community Toolkit which, as the name implies, provides free tools: effects, converters, controls and more.

Manual platform implementation

In some apps .NET MAUI with the Essentials pack and the Xamarin Community Toolkit can be sufficient. For most apps though, there is a point where some custom adjustment is necessary. A good example would be control adjustment using Handlers or Effects. We’ll describe Handlers and their value in more detail in a future blogpost.

There are several ways to go about defining platform specific behavior in MAUI. Because of multi-targeting the code will be in the single shared project. With Xamarin Forms this was also possible using the Shared Project architecture, but the recommended and most common approach was using a PCL and implementing platform behavior using dependency injection. Let’s run through some options!

Using #if

To add a few lines of platform-specific code to an otherwise shared class we can use compiler directives like #if __IOS__. This is a quick and easy solution and keeps the related code close together, in the same file. For smaller handler mappings this could be a nice and easy to manage approach. It could also make Effects easier, because we don’t need the routed effects and DI registration of every platform implementation. With larger sections of platform-specific code this can get messy and harder to read though.

				
					//SecureSettingsProvider.cs

namespace MyApp.Settings;

public class SecureSettingsProvider
{
    public string GetSecureSetting(string context, string key)
    {
        return GetLocalSetting($"{context}-{key}");
    }

    private string GetLocalSetting(string contextSpecificKey)
    {
        #if __IOS__
        // retrieve value from secure storage / keychain
        #elif __ANDROID__
        // do the same for android
        #endif
    }
}

Using platform folders

MAUI projects using the single project structure will provide platform folders out-of-the-box. They will be compiled conditionally by default, e.g. the Android folder will only be included when building for Android. Within this option there are still 2 distinctive approaches:

Dependency injection using interfaces

Like the old-school Xamarin Forms pattern, using an interface in the cross-platform code, and explicit implementations in each platform folder. Any logic that could be shared will have to be copied between the implementations, although to make it slightly more complex, one could also define a cross-platform base class.

Partial classes

Partial classes are not a new concept in C#. Check the docs if you want to read more about them. We can define one cross-plaform partial class and another partial class with the same name and namespace in each platform folder. This is a pretty clean alternative to using #if directives when working with larger classes/code sections. A potential disadvantage of this approach is that both partial classes live quite far-away from each other, which could hinder discoverability and increase cognitive load, if there is a lot of shared code. If the partial class has little shared code, the experience is a lot like using interfaces.

				
					//SecureSettingsProvider.cs in shared code

namespace MyApp.Settings;
public partial class SecureSettingsProvider.cs
{
    public string GetSecureSetting(string context, string key)
    {
        var settingValue = GetLocalSetting($"{context}-{key}");

        // do some work that's shared between implementations
        if(String.IsNullOrEmtpy(something))
          return "nothing";
        else
          return settingValue;
    }
}

				
					//SecureSettingsProvider.cs in Android platform folder

namespace MyApp.Settings;
public partial class SecureSettingsProvider.cs
{
    private string GetLocalSetting(string contextSpecificKey)
    {
        // retrieve secure setting value for Android
    }
}

Using filename based conditional compiling

This pattern is used in the MAUI github repository itself. Concretely this again means using partial classes, but this time the platform specific implementation is defined in the same folder in a separate file. For example for our SecureSettingsProvider, we would have a partial class in SecureSettingsProvider.cs and another one in SecureSettingsProvider.Android.cs, SecureSettingsProvider.iOS.cs , etc.
A potential advantage of this is that platform implementations are directly next to the shared part, which improves discoverability and can reduce cognitive load.

This approach is not supported out of the box though. The compiler needs to be informed which files to include or more accurately, which NOT to include, so we need to add this information to our project file. For an example of how this could look, see the first +-30 lines in MultiTargeting.targets file in the MAUI repository. The following sample is taken from line 2-7 there and slightly adjusted:

				
					<ItemGroup Condition="$(TargetFramework.StartsWith('Xamarin.iOS')) != true AND $(TargetFramework.StartsWith('net6.0-ios')) != true AND $(TargetFramework.StartsWith('net6.0-maccatalyst')) != true ">
  <Compile Remove="**\**\*.iOS.cs" />
  <None Include="**\**\*.iOS.cs" Exclude="$(DefaultItemExcludes);$(DefaultExcludesInProjectFolder)" />
</ItemGroup>

This ItemGroup definition informs the compiler to ignore all *.iOS.cs files in the project unless the current build target is Xamarin.iOS, net6.0-ios or .net6.0-maccatalyst. Similar project configuration can also be used to allow for custom platform folders thoughout the code:

				
					  <Compile Remove="**\iOS\**\*.cs" />
  <None Include="**\iOS\**\*.cs" Exclude="$(DefaultItemExcludes);$(DefaultExcludesInProjectFolder)" />

Which option is best?

As always in software development, the answer here is “it depends”. For multitargeting libraries, like MAUI itself, it is likely a good option to look at the the filename or nested folder approach we discussed. With a little project setup this allows you to group code by functionality, keeping related code close together.

For apps, it depends on how much platform-specific code really needs to be written. For some apps only a few adjustments may be needed using Effects, Behaviors and handler mappings. It is very possible for these to be only a few lines which allows for keeping everying in one file using #if directives. If these grow it is convenient to use the existing platform folders. In both these alternatives you can forego the need to use interfaces and register the platform services for dependency injection which can be convenient.

Please note that we’ve been looking at these patterns fairly strictly from MAUI perspective. Of course it is possible that you prefer to use interfaces to making testing and mocking easier. In that case you will be setting up the DI container anyway. It may still be easier to register one implementation and use above options, instead of registering every platform service separately, but keep in mind your overall architecture before choosing any of these patterns.

The post .NET MAUI: Implementing platform behavior appeared first on XABLU.

Microsoft Build 2020 – What Day 1 Brought Us

XABLU HQ — Wed, 20 May 2020 14:06:15 +0000

In light of the current COVID-19 pandemic, Microsoft has transformed this year’s Build conference into a 48-hour online event, accessible to everyone! Within this blogpost, we will look back at the first day of Microsoft Build 2020 and get you up to date with the most important announcements. Already know what happened on the first day, but curious what they announced the second day? Read everything about day 2 here!

Besides hosting this event online, the current pandemic also has an effect on the actual content presented during the conference, as much emphasis was also put on enabling the developers to be more collaborative and productive while working from home through advances in tools. Also, a large focus was put on integrating more AI.

MAUI

We already knew that .NET 5 is going to be released later this year, but Microsoft surprised us yesterday with the announcement of .NET 6, which is planned for November 2021. Even though that date is still far from today, we know that it will there are big plans for Xamarin: both Xamarin.Forms and Xamarin will finally become first-class citizens in the .NET world, under the acronym MAUI, which stands for .NET Multi- platform App UI.

MAUI will introduce a new approach for developing apps in Visual Studio: by default, there will be a single project that will use multi-targeting to offer 100% customization. It will have support for MVVM, MVU and Blazor! MacOS and WPF will be officially supported (and Linux is also in the roadmap).

But the changes don’t stop there: the Xamarin team is currently considering architectural changes in the Xamarin.Forms framework that will make the codebase simpler and offer better performance. Moreover, Xamarin.Essentials will be part of the .NET APIs.

What will happen then to Xamarin.iOS and Xamarin.Android? Both will be embedded into the .NET APIs as well and they will become .NET for iOS and .NET for Android.

We cannot wait for MAUI to be released as we continue to embrace Xamarin. Want to read more about MAUI? This blogpost from Microsoft will provide you all the ins and outs!

WinUI and Project Reunion

Another great announcement was made regarding UWP and Win32 API’s: Both kind of apps will be reunited under WinUI 3.0 and made available decoupled from the OS through tools like NuGet.

WinUI will have a very positive impact on the Windows Developer experience, which is currently fragmented in different UI frameworks. In Microsoft words, “WinUI will provide a state-of-the-art UX framework for every Windows developer”, meaning developers can build great user experiences that adapt and scale across devices. This can be applied when starting a new project, or when modernising an existing app.

As part of the announcements from yesterday, WinUI3 Preview 1 was made public, containing a lot of improvements and new features. We just need to be aware it is not production ready yet.

Blazor WebAssembly

Blazor WebAssembly was finally released yesterday and it is production ready. This means full-stack web development in .NET is a reality!

Through Blazor WebAssembly, it will be possible to debug front-end and back-end code in the same IDE within Visual Studio, all in C#! Developers will also be able to debug Linux environments from Windows using Visual Studio, all this with the new embedded Linux capabilities from Windows. We believe this will definitely increase efficiency and ease the cross platform support! If you already have a traditional Blazor app, then migrating to WebAssembly is expected to be very easy.

For more information on Blazor WebAssembly, find the official Microsoft blogpost here.

Visual Studio Codespaces and Live Share

Yesterday, Microsoft also paid a lot of attention to remote working environments. First, Visual Studio Codespaces (formerly called Visual Studio Online) is now available: “with a single button, from GitHub, you can experience Visual Studio Code in the browser.” One of the biggest advantages of this is for projects that require complex environments: all settings and configurations, such as environment variables, can be defined in a file and committed to the repository. Furthermore, the developer experience is excellent due to Codespaces being able to pick up your themes, extensions and local configurations. Please be aware that not all workloads are available at this stage (mobile development is not) – but you can certainly debug localhost remotely. Awesome, right?

Yesterday Microsoft also presented new features for Live Share: Developers can now share sessions across Visual Studio Code and Visual Studio and have audio and text chat embedded, so no context switching is necessary anymore. We see tons of possibilities for this feature, not only for collaboration within a project, but also to be used for job interviews, at schools or to onboard new developers to complex codebases. As we value remote work very much, this feature will enable our colleagues to collaborate even more efficiently.

Attending the Remote Event

Like many events, Microsoft had to switch from their usual Seattle gathering to a full-remote event in only a matter of weeks. While this does decrease the network- and community factor the event usually brings, it also makes it more accessible to developers all around the world. There are so many sessions offered, one can sometimes feel lost in the extensiveness of it all. However, with this vast amount of different topics, any developer or designer ranging from student to senior can find something for them.

A lot of sessions were live-streamed or pre-recorded. The live streaming sessions allowed for Q&A sessions where the most liked questions were answered. The broadcast itself worked very well: you could easily pause the broadcast and continue it later without any technical difficulty.

While we think their approach is a great solution for the current situation, we hope in the future we can meet again in person to fully provide the focus and attention these sessions deserve.

The Conference Continues...

The second day of the event included more announcements! Which sessions did you follow? Let us know below in the comments below!

Find another summary of the Microsoft Build conference, day 2, here!

The post Microsoft Build 2020 – What Day 1 Brought Us appeared first on XABLU.