Welcome to day 3 of our OCC 2022 Dev Camp blog, to find out more about the camp click here. Today’s post will be looking at our testing of Blazor Desktop.
Blazor Desktop
Blazor Desktop is a new Blazor version of the hybrid client app approach. It enables you to create a desktop application using the standard frameworks (WinForms or WPF), and then add a browser control to host a website within your desktop application. With Blazor Desktop, Microsoft has introduced the new BlazorWebView component for WinForms. Using this control, we can host Blazor pages locally within our app.
The advantage of the Blazor Desktop approach is that you can use the latest web technologies to build an attractive, engaging application within older desktop frameworks which are less flexible. The key disadvantages are performance and memory consumption; hybrid apps like this can easily use an additional 250MB memory, since they are hosting a web browser. You may see this on your own computer with apps like Slack and Discord, which have a much larger memory footprint than would otherwise be required for a chat app.
Another argument put forward in favour of adopting this approach is the potential for decreased development costs. If you need to build both a website version and a desktop version of the same application, you can reuse much of the code. We are testing this theory in our Dev Camp and want to find out how true this is.
Day 3
Blazor Desktop
It might not seem like we’re doing much with Blazor Desktop in Dev Camp, but that is exactly the point. Today, we copied the code from the Blazor Web application, and within a couple of hours we had a functioning desktop client.
Website caching
As well as building the desktop client, we added caching to both the desktop and web versions. We’re now able to add entities while offline, and then upload them to the server when online again.
We discussed as the group the benefits of caching data as standard practice for all websites, whether we’re expecting offline use or not. The conclusion was that the additional burden of writing synchronisation code is too great, unless there is a specific need to work offline. This is because the cache adds an additional layer between the page and the data, replacing our otherwise beautiful Entity Framework Core repository implementation.
Searching within our list
Today we implemented our search box. There are 2 strategies with search, depending how much data you have. You can either download the data and search for it within the client, or you can send a request to the server to return only the rows you need. Given that server-side search is already principally C# driven, we opted for client-side searching which is ideal for small datasets. We enjoyed implementing our client-side search algorithm within Blazor using C#. Being able to use the domain entities and LINQ made implementing search a doddle.
End of day 3
To conclude the day, we imported the latest version of the web project into Blazor Desktop. We now have both a web and Windows client that has our search implementation.