Apprentice Dev Blog: Week 6 - Markup & New Ways To Design UIs

The cover image for this post is by Hal Gatewood

This blog post was written by Alex. Alex is our apprentice for 2022, and will be providing frequent developer logs.

Jamie here - to jump directly to Alex’s log for this week, click here

Today marks the completion of Alex’s sixth week with us, meaning that they are coming toward the end of their apprenticeship.

remember that Alex is NOT their real name

Alex is studying a Digital T-Level course and has joined us for their mandatory eight weeks in industry.

We are incredibly proud to be helping with Alex’s technical education. And as a reminder, I was assigned to be their PM on the project that they are working on and someone to reach out to for help in completing it. The Digital T-Level course that Alex has taken is very comprehensive and covers a number of different development technologies, but there are certain gaps in their knowledge. This is not meant as a negative point towards either the course designers or those who are delivering it, there is simply not enough time to teach all of the things required of a developer in just two short years.

in fact, development is one of the career choices which require a person to be constantly learning new things

This week sees us starting work on the .NET Maui portion of this project. There are a few reasons for waiting until now:

• it gives the .NET Maui content creators a chance to content in line with the v1 release of .NET Maui
• it gives us a chance to make sure that Alex’s project is shored up with enough tests
• it gives Alex experience at taking an already working project and upgrading parts of it
• Alex has built this project with SOLID principles in mind, so they should be able to just swap the UI with very few issues

I’m still very aware that with .NET Maui being so new the documentation and content around it could be incorrect, as was pointed out by our friend Scott Harden:

.NET Maui really is at the bleeding edge, and there isn’t that much documentation out there - and what there is is partially incorrect because it’s so new. My recommendation would be to go WPF first, then .NET Maui.

But I feel that there is enough content out there for Alex to get started on their journey of learning .NET Maui; and there will be a lot to learn - with MVVM, XAML, and a different paradigm for building and releasing. As a reminder, my goal for this project has never been for Alex to complete it; I would much rather that they were able to use this project as a way to plug any gaps in their knowledge around how we actually do things in industry.

they’ll also get a great app code base to work with once they have completed their apprenticeship

Anyway, you didn’t come here to read what I have to say. So here is a development log which represents Alex’s sixth week, in their own words:

one note, I’ve edited for presentation not content

Alex’s Devlog

Hi, I’m Alex and am currently studying a Digital T-Level course, am taking my industry experience with RJJ Software, and these are some of the things that I learned this week.

This week, I spent a lot of time learning about the different layouts in .NET Maui. Both XAML and .NET Maui are brand new to me, so it’s been slow working. One of the best ways to learn something new is to use it in a project, so what I’ve been doing is attempting to rebuild the current UI (built using WinForms) in .NET Maui. This has presented a lot of new challenges for me. First of which is actually designing the UI.

First, The Current

With WinForms, you have a visual designer. You can drag and drop controls onto a form, and very quickly build up something which matches your envisioned design:

With WinForms, the actual code which drives the creation of the UI is stored in an auto-generated file. This helps to abstract away the busy-work of creating new instances of the toolbox controls, setting all of their properties, and layering them.

Jamie here: WinForms is a 20+ year old technology, but I genuinely believe that they got the functionality of form builder perfect

Here you can see the visual designer. You drag controls from the toolbox (on the left) onto the form (in the centre) and set it’s properties in the Properties pane (lower right).

And Now The New

There is a visual designer for XAML built into Visual Studio, but it isn’t as intuitive as the WinForms builder. Very little of the code to generate a XAML-based UI is auto generated

Jamie here: there’s some autogenerated code, but it’s mostly wiring things up for you and convention based stuff

and it’s all XAML based. Here’s an example:

<?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="MyMauiApp.MainPage">
    <Grid>
      <Grid.RowDefinitions>
        <RowDefinition Height="*" />
        <RowDefinition Height="*" />
      </Grid.RowDefinitions>
      <Grid.ColumnDefinitions>
        <ColumnDefinition Width="*" />
        <ColumnDefinition Width="*" />
      </Grid.ColumnDefinitions>
      <StackLayout Grid.Row="0" Grid.Column="0">
        <Label Text="Hello, XAML!"
               VerticalOptions="Center"
               HorizontalTextAlignment="Center"
               FontSize="18"
               FontAttributes="Bold"
               TextColor="Blue" />
        <Entry Placeholder="I'm ready for some text" />
        <Button Text="I'm a button, but I don't do anything" />
      </StackLayout>
      <StackLayout Grid.Row="0" Grid.Column="1" BackgroundColor="#ffd320">
        <Label Text="Top-right!"
               VerticalOptions="Center"
               HorizontalTextAlignment="Center"
               FontSize="18"
               FontAttributes="Bold"
               TextColor="Blue" />
      </StackLayout>
      <StackLayout Grid.Row="1" Grid.Column="0" BackgroundColor="#00ffff">
        <Label Text="Bottom-left!"
               VerticalOptions="Center"
               HorizontalTextAlignment="Center"
               FontSize="18"
               FontAttributes="Bold"
               TextColor="Blue" />
      </StackLayout>
      <StackLayout Grid.Row="1" Grid.Column="1" BackgroundColor="#008000">
        <Label Text="Bottom-right!"
               VerticalOptions="Center"
               HorizontalTextAlignment="Center"
               FontSize="18"
               FontAttributes="Bold"
               TextColor="white" />
      </StackLayout>
    </Grid>
</ContentView>

The above code creates the following view:

XAML is declarative form of XML, which makes it similar to HTML

Jamie here: similar to but not the same as

And by this, I mean that you declare what you want, where you want it, and add properties to it. For instance:

<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="MyMauiApp.MainPage">
</ContentPage>

Tells .NET Maui’s rendering engine that you are declaring a ContentPage, and that you will use a .NET class found at MyMauiApp.MainPage as the Model. .NET Maui (and Xamarin before it) uses an MVVM approach, and as such the rendering engine needs to know where you find any of the Class properties that you might want to bind against in your view.

The following code sets up a Grid with Rows and Columns which will grow and shrink to fill the screen evenly:

<Grid>
  <Grid.RowDefinitions>
    <RowDefinition Height="*" />
    <RowDefinition Height="*" />
  </Grid.RowDefinitions>
  <Grid.ColumnDefinitions>
    <ColumnDefinition Width="*" />
    <ColumnDefinition Width="*" />
  </Grid.ColumnDefinitions>
</Grid>

And the following code creates a StackLayout in the first row and first column (i.e. top-left) with a Label, text input, and button. The label, text input, and button are stacked within the StackedLayout. Items are added to the bottom of the stack in this example.

<StackLayout Grid.Row="0" Grid.Column="0">
  <Label Text="Hello, XAML!"
        VerticalOptions="Center"
        HorizontalTextAlignment="Center"
        FontSize="18"
        FontAttributes="Bold"
        TextColor="Blue" />
  <Entry Placeholder="I'm ready for some text" />
  <Button Text="I'm a button, but I don't do anything" />
</StackLayout>

Learning how to recreate my previously created UI in XAML has taken some time, and I’ve had to go back to the drawing board a number of times. This is largely because when using the WinForms designer, I haven’t had to think too much about the order of the controls being added to the UI, but when it comes to XAML the ordering is almost always important. I’m sure that experienced XAML developers are much faster than I am, but it seems like the WinForms UI builder is a little more intuitive.

A Quick Note About The WinForms Designer

Jamie here.

The WinForms Designer is wonderful for RAD-style development of a UI, but it can become very unwieldy, very quickly. As I pointed out in a Stack Overflow question back in 2012, this can happen very quickly if you’re not keeping a close enough eye on what’s happening. Combine that with the fact that the majority of the code for the UI is in the control of the code generator (i.e. magic), and you have a recipe for disaster.

Whilst I’ve been working mostly on server-side code for around 12 years, I can appreciate why HTML and HTML-like languages have become the UI languages of choice: they are declarative (i.e. “give me a div here, and a paragraph there”), and since HTML5 everything is now semantic (i.e. we now have more specialised elements for article, aside, video, etc.)

In Closing

Alex again.

The majority of this week has been spent slowly re-implementing my WinForms UIs with XAML; I’ve also been spending time learning the ideas behind Response web design. This is because .NET Maui is a multi-platform UI paradigm, so it has to scale from mobile phones up to 4 and 8k PC screens, and everything in between. This has meant that I’ve had to work on designing a UI which fits the constraints of a mobile phone first, then expand the UI design to potentially allow more controls (or more space between them) on a bigger screen.

Jamie again.

Another week of setting Alex some pretty complicated tasks, and another week of watching them fly through those tasks with ease. Next week, we’ll start to take the screens that they are building and add our services back in via dependency injection.

I’m genuinely excited to see what Alex can make in the final few weeks of their time with us. It feels like all of the lessons that I’ve been teaching them are coming together and will make it relatively trivial (especially compared to how non-trivial XAML seems to be for beginners) to wire all of the services back up. I suspect that once the UI is written, we should be able to have everything working again in a matter of hours.

Which is what SOLID, Domain-Driven Design, and all of the modern development paradigms are all about.