Hands-on MAUI

MAUI isn’t out yet – thus don’t cite any of this in the future. However, with Preview 9 some groundbreaking, innovative, industry-changing features came to life: Borders, Shadows, and Corners. </sarcasm> But let’s be real, I just want to take a look at the current development state and the new Windows App SDK. Sooooooooo

20 Nobody Cares Memes For When You Want To Be Snarky - Ultima Status
Lemme eval MAUI!

Architecture

What stands out, in particular, are two things about the architectural diagram (See Fig. 1). Win32 and WinUI 3. Win32, somewhat released with Windows 95 (correct me if I am wrong), is an API and a runtime environment for Windows desktop applications. WinUI 3 is a UX Framework to get access to the latest UI controls, patterns, and styles. But why is this important? I am glad you asked.

With Windows 8 the Win32 “successor” WinRT emerged – more like an addon instead of a replacement. 3 years later, Windows 10 introduced the UWP, an extension to WinRT, to add support to various devices, such as Hololens, Xbox, Windows Phone (RIP), and much more. In regards to the UX Framework, UWP app development leverages WinUI 2.

You the point Memes
Get to the point bro

UWP won’t receive an update to WinUI 3. Hence, modern UWP applications are stuck in the past and require manual migration (not all features are currently available. See Fig. 2). But even worse, WinUI 3 builds on top of Win32 only, ditching 6 years of progress; including multi-device support.

Thus, as MAUI uses WinUI 3, it automatically minimizes potential target platforms – duh. The UWP may start to cease with WinUI 2, considering everything moving to NET5/6. In other words, MAUI incorporates a new and simultaneously ancient technology, posing serious questions and acquisitions. My favorites:

  • “Go from Win32 => Windows 8, Windows Phone Runtime => UWP => Win32. Great job MS, you make us waste our time.” -WesleyKhoiVo
  • “What are you guys even doing? Why are you not improving UWP instead of constantly creating new frameworks? Now we are back to WinForm/WPF and Win32 with fancy incompleted WinUI3? Don’t you think it’s embarrassing that a massive platform like Windows has 0 competent app development platform for years, almost a decade? Windows is one of the olders platforms … Meanwhile you keep running around in circles … truly no words for this.” -Qws
  • “I simply don’t understand how you can tell us “if you’re happy with your current functionality in UWP” — we’re pretty much 8 years behind any decent advance there has been made.” -jtorjo
Fig. 2.: Not (yet) supported features in WinUI 3

Project templates

There are two project templates to choose from (See Fig. 3): MAUI and MAUI Blazor. We only inspect the MAUI template, as the Blazor version is more or less the same, simply hosted in a webview.

Fig. 3.: Project templates

MAUI

With a default project deployment to an Android Simulator not working (Error CS0103 The name ‘InitializeComponent’ does not exist in the current context MAUI (net6.0-ios), MAUI (net6.0-maccatalyst), MAUI (net6.0-windows10.0.19041) – lel mac, wat?) we will stick to Windows Machine deployment tests only.

Application Patterns

MAUI supports four different software design patterns: MVU (Model-View-Update), MVVM (Model-View-ViewModel), Blazor, and MVP (Model-View-Presenter). This caught me off-guard, how amazing is that. Hence, one may choose to implement a button press in various ways (See List. 3, 4, 5, 6, 7):

[Body]
Button CreateBody() => new Button().ClickGesture((click) => Debugger.Break());
<Button Command="{Binding ClickCommand}" />
...
public ICommand ClickCommand { get; set; } = new Command(() => Debugger.Break());
@using System.Diagnostics

<button onclick="@(() => Debugger.Break())"></button>
<button onclick="ButtonPress"></button> <!-- works as well -->

@code {
    private void ButtonPress() => Debugger.Break();
}
Button button = new Button();
button.Clicked += (a, b) => Debugger.Break(); 
button.ClickGesture((click) => Debugger.Break()); // works as well
<Button Clicked="OnClick" />
...
void OnClick(object sender, EventArgs e) => Debugger.Break();

Thus, we can choose between Comet, XAML, Blazor, and Code-behind when it comes to UI building. A bit over the top, but I will take it. As comet typing is new within the .NET world, you might want to check out the following sources.

MAUI Controls

Following controls are available via Intellisense: WebView, View, VerticalStackLayout, TimePicker, TemplateView, TableView, Switch, SwipeView, SwipeItemView, StructuredItemsView, Stepper, StackLayout, Slider, SelectableItemsView, SearchBar, Scrollview, RoundRectangle, RefreshView, Rectangle, RadioButton, ProgressBar, Polyline, Polygon, Picker, Path, OpenGLView, ListView, Line, Label, InputView, IndicatorView, ImageButton, Button, HorizontalStackLayout, GroupableItemsView, GridLayout, Grid, GraphicsView, Frame, FlexLayout, Elypse, DatePicker, ContentView, CheckBox, CollectionView, Button, BoxView, Border, ActivityIndicator, AbsoluteLayout. However, not all of them render when starting the windows simulator. Either some controls are platform-specific (but don’t throw an exception when the current platform doesn’t support the control) or it’s simply not implemented yet.

What we know for sure, these controls are truly platform-independent and arrive with three different designs: Cupertino (iOS), Material (Android), and Fluent (Windows); all supporting light- and dark-mode out of the box. Various controls offer convenient addons – a requirement for multi-platform development IMHO – such as platform-specific parameterization (See List. 8). For even more flexibility, OnPlatform and OnIdom (See List. 9) offer to exclusively serve layout sections to specific platform- or device types.

<Grid Padding="{OnPlatform iOS='30,60,30,30', Default='30'}" />
<OnPlatform>
    <On Platform="Android" />
</OnPlatform>

<OnIdiom Default="" Desktop="" Phone="" Tablet="" TV="" Watch="" />

The Grid control received lifetime saving properties (See List. 10), similar to other frameworks (e.g. Avalonia). For accessibility, the SemanticProperties allow attaching descriptive information (See List. 10), also similar to other frameworks. It seems like the StackLayout replaces the well-known StackPanel, but offers, similar to the Grid, a spacing property.

<Grid RowSpacing="25" RowDefinitions="Auto,Auto,Auto,Auto,*"
    SemanticProperties.Description="Sup" SemanticProperties.HeadingLevel="1"
    SemanticProperties.Hint="Bro"

<StackLayout Spacing="50" />

MAUI Hybrid

Quite confusing – due to the Blazor template – one may add Blazor bindings alongside XAML code. Although technically correct, adding XAML code to Blazor components (See List. 11). Ladies and gentlemen, this is MAUI hybrid – as far as I understood. In conclusion, you may create your app with:

  • MAUI Native
  • MAUI Blazor, effectively MAUI Native with a webview
  • MAUI Native with Blazor components
  • MAUI Blazor with Blazor bindings
Delonge GIFs | Tenor
Fig. WTF.: Me after reading that
<StackLayout>
    <Label FontSize="30">You pressed @count times </Label>
    <Button Text="+1" OnClick="@HandleClick" />
</StackLayout>

@code {
    int count;

    void HandleClick() => count++;
}

Conclusion

MAUI wants to be everything. A semi-replacement for the UWP, native-mobile cross-platforming, web application capable, and even both in combination. It facilitates Comet, XAML, Code-behind, and Blazor to define user interfaces. What is your favorite application pattern? Just in case, here are MOST OF THEM. Currently, we deal with a non-feature complete WinUI 3, an old Win32 application runtime, and a mixture of cross- and non-cross platforming user-interface controls. It feels like Blazor components in an MAUI native application may serve as a universal custom-renderer, closing gaps between different platforms. On the other hand, Xamarin’s custom renderers will still be a thing upon release (See Fig. WTF)

0 0 votes
Article Rating
Subscribe
Notify of
0 Comments
Inline Feedbacks
View all comments