Blazor
Blazor is exciting because it allows us to build interactive web UIs in C#. In standard ASP.NET MVC and Razor Pages code, we use Razor. Razor uses C# code to embed content into HTML pages, on the server-side, before it is sent to the user. The embedding of content only happens on the server-side. If you want the content to dynamically update when the user interacts with the page, you need JavaScript. Often this means duplicating business logic in both C# and JavaScript.
Blazor improves on this, by allowing us to run C# code while the user interacts with the page. This is either run on WebAssembly in the browser, or on the server where it is communicated by Signal-R. This means that we can write the business logic for our applications in C# and run it both server-side and client-side.
Validation rules are one such example of this. Take for example an email field, where validation may be required to check that the email data has been entered in the correct format. Currently we would have to write this validation in both C# for the server and JavaScript for the client-side. When we update the code, we must remember to do so in both places. By using Blazor, we can write the code once, and use it in both environments.
.Net MAUI and Blazor Desktop
Investigating Blazor is not the only item on our agenda for this Dev Camp. We’re also interested in .Net MAUI as a mobile application framework, and Blazor Desktop as a new pattern for desktop applications. We’ll discuss these in later blog posts.
Meet the team
For this DevCamp, we’ve pulled together experts from across the company. We have:
- Jon Bowen – technical lead of ContrOCC’s Online Financial Assessments website. He’s on the team as a website expert
- William Frankish – a custom software Senior Software Engineer. He’s delivered some of our most public projects, such as QCovid and Active Lives Online. He’s on the team as a website expert
- James Grieg – a custom software Lead Software Engineer. He’s delivered a wide range of projects such as ParkAI, Virtual Assay, and GLOIN. He’s on the team as our desktop application specialist
- Matthew Clarke – technical lead of ContrOCC’s Remote Financial Assessments app. He’s on the team as our mobile app expert
- Tim Palmer – I run the custom software part of the company and lead TAB. These days I have more opinions on code than opportunities to write code. I’m on this project to set the direction and write these blog posts
Day 1
Day 1 of the DevCamp is entitled “Hello World”. Can we build the first page of our project with our new technologies?
Blazor Web
The Blazor Web website was an easy start, using client-side Blazor with WebAssembly. At the end of the day, we had our home page. We’ve used our UI component set based on the Lightning Design System to get OCC’s quality look and feel.
We’re hosting this website on Azure, along with our SQL Server database. We’ve also added an ASP.NET Web API, which will allow different parts of the system to fetch and update the data.
The application we’re building is an Order Processing System (OPS). More information on that in a later blog.
.Net MAUI
Progress with .Net MAUI was not as smooth. We had expected MAUI to be released in November, but that was pushed back to April 2022, so we are working with the preview version (31st Jan 2022). It is immediately obvious why the release was pushed back – we’re finding many bugs and are unable to use the templates.
Despite this, we’ve successfully made a new Shell App for our application, which can be seen below running as a Universal Windows Platform app.
Blazor Desktop
Blazor Desktop involves embedding a Blazor website inside a desktop application. Our original plan was to create a MAUI WPF application. However, this is not yet available on preview. Instead, we have fallen back to our old favourite – WinForms.
We were able to successfully create a home page on Blazor within WinForms. However, we have a new question to investigate: “Does Blazor Desktop prefer a server-side Blazor approach, rather than a client-side approach, and will that stop us from sharing code?”.
End of day 1
Day 1 ended positively for Blazor, but on a disappointing note for .NET MAUI as more problems arose.
Day 2
The plan for Day 2 is to build the create/edit and the view screens and connect them to the database. Blazor Desktop is on pause today, and will resume tomorrow. We will be looking at .Net MAUI, and going into more details about the software we are building this week.
.Net MAUI
One of our goals for this Dev Camp is to assess .Net MAUI, which allows an app to be built once, but run on multiple platforms (iOS, Android, macOS, Windows). This is exciting, because we are frequently trying to create the biggest impact possible for clients, but within their budgets. Often when building apps, it is necessary to target both Android and iOS, but creating two different apps is expensive. Being able to write a single app that can be deployed in both Android and iOS will save a lot of time.
This is not new. We’ve worked with both Flutter and Xamarin. Forms (XF) to build apps we can deploy in Android and iOS. The advantage of XF is that we can use (and reuse) C# code. MAUI represents the next generation of XF and would be the natural upgrade path for our existing products.
In this Dev Camp, we want to find out whether MAUI has improved on their existing offering, and whether we want to upgrade our existing XF apps to MAUI.
What we are building – Order Processing System (OPS)
During Dev Camp it is important to pick a toy project which will allow us to fully test the potential of the technology, but not one that is so complicated it would take longer than a week to build. In terms of picking a task, we looked for inspiration in-house and decided to focus on our proprietary tool for tracking orders. This system allows project managers to create orders, update existing orders, and search the list of orders.
The existing OPS is good, but we want to demonstrate how the latest technologies can improve it.
- Blazor, we hope to improve website performance, while also improving the maintainability of the code
- MAUI, we want to demonstrate how to build a mobile app that shares much of the same infrastructure as the website
- Blazor Desktop, we want to demonstrate how easily we can make a desktop client by reusing the web code
OCC UX Design Studio
Before the Dev Camp, we asked our UX design studio to provide some design work. They are experts at designing systems that not only meet user requirements but also provide an enjoyable user experience.
The purpose of Dev Camp is to test the technology, so aesthetics are not the highest priority. However, these designs give us something to aim for, and it will be interesting to see how close we can get to reproducing these designs in only a week.
Blazor
As expected, it was not too difficult to build the screens in Blazor. There are many similarities with existing ASP.NET MVC development. Admittedly some further styling is required (as shown in the screenshots below) but given the fact that we are working with a new technology, we were pleased with our progress.
Now we are using Blazor to solve a real problem, we are starting to get a better feel for the technology. This is the purpose of the Dev Camp.
Our feedback after testing the functionality of adding validation using attributes in Blazor was positive. These attributes allow us to easily apply the validation rules to fields. This isn’t new, and has been available in ASP.NET MVC. However, Blazor enables these validation rules to be used in both the server-side and client-side code. Previously we would have had to write a JavaScript version as well.
An area we explored which was new to us was how to debug Blazor. What would normally be a single MVC project would constitute 2 projects in Blazor, Blazor.Client and Blazor.Server. You might reasonably expect to need to debug the client project to debug code within the client pages, but we learned that to debug Blazor, you need to run the debugger on the server project instead.
MAUI
Work on the mobile app development has not been as smooth. We can see clearly that it is built on Xamarin, because all the old Xamarin methods are there, but marked as obsolete. The new MAUI versions of these methods have many outstanding bugs waiting to be fixed.
For example, we added a list view component and bound it to our source, but it didn’t render our data. We soon discovered that this is because the list does not trigger a page refresh. We could fix it by adding a data binding to a label, which would trigger a page refresh, but such workarounds are awkward. Instead, we ended up building our own grid control.
It was discovered that our app does not render correctly in Android, hence why we are unable to include a nice screenshot today.
initially going into this Dev Camp we knew that MAUI wasn’t ready for production, because the release was pushed back to April when .Net 6 launched in November. We thought it was still worth trying, but we hadn’t expected it to be this incomplete. We have decided to limit our investigation of MAUI, so we do not spend too much time on broken functionality. There are a few features that we are planning to test, but we do not expect to build a complete product.
To wrap up
The day concluded with an interesting discussion. Blazor allows data to be cached in Web Assembly much more easily than was previously the case in JavaScript. This means we can support offline working, but does it also provide benefits for online users? Users may have a slow or unreliable connection. Yet perhaps there are also performance benefits to be realised. Come back tomorrow to find out more.