Blazor & Xamarin: Code Sharing For Everyone!

If you have been waiting and watching the Blazor news for the last year like I have, we can both do a little ‘happy dance’ now that it is soon coming out of preview! My hope is that Blazor represents a way to build web applications (sans JavaScript) that cashes-in on some of the growing pains Microsoft-Stack developers have been enduring with the .Net Framework –> .Net Core & .Net Standard transition.

In a nutshell, Blazor is:

• Blazor is C# for the web client, replacing the cringe of JavaScript
• Captures some of the component-ized spirit of React – they call the components ‘Razor Components’
• Doesn’t try to reinvent HTML/CSS (hip hip hooray!)
• Server-side Blazor works with Signal R
• Client-Side Blazor works with Web Assembly
• Any .Net Standard 2.0. Library can be used by a Blazor project – allowing one to leverage all of the existing .Net libraries
• And yes, you can share .Net Standard 2.0 libraries between your Blazor and your Xamarin.Forms apps!

Server-side Blazor will be shipped with .Net Core 3.0 in September 2019.

• Blazor Roadmap
• April 2019 – Official Preview Announcement

So, I thought I would build a simple example app to see what happens when the ‘rubber meets the road’. I set out to build a Xamarin.Forms Shell app that shares models and business rules with a Blazor app. It was important to me to make sure I used HTTPClient because that is a library that has represented a recurring nightmare for the simplest of projects, in a number of different settings over the past 4 years. I wasn’t looking to make something really beautiful. I just wanted to see how many problems I would run into ACTUALLY sharing code between Blazor and Xamarin.

So, what did you build?

Both apps simply pull the top 50 cities from the AccuWeather API and display them in a list. If you click on one of the cities, it will call another AccuWeatherAPI and report the current weather conditions. I used VS 2019 Preview.

Here is the Blazor website:

Here is the Xamarin.Forms Mobile App (Screen Caps from Android):

What’s the Solution Structure?

The Config files, Business Logic, Business Logic Tests and the Models (DTOs) are all in their own .Net Standard 2.0 projects. The Config, BizLogic and Models projects are referenced by the Blazor and Xamarin.Forms projects (Just the core XF project, not the platform specific projects).

The Blazor app is a .NetCore 3.0 app.

The projects inside the solution end up looking something like this. Notice that if you can successfully isolate the business logic in it’s own library and write tests around it, you are potentially saving a ton of development and QA time. Sharing the Model/DTO layer also saves a ton of headaches with syncing.

Where’s the Source Code?

Check out the GitHub Repo

To run it, you will need an API key from AccuWeather. Put your key in the Config project, in Config.cs.

Where were the Pain Points?

Well, I am more than a little afraid to write this, but this ‘just worked’. NO weird HTTPClient assembly redirect problems. I didn’t have any problems with dependencies. I expected to have a harder time picking up Blazor, but it JUST MAKES SENSE. Everything built and ran just fine on the Xamarin iOS and Android side. Visual Studio 2019 preview didn’t give me any weirdness. Granted, I built something super-simple.

I used the shell template for the Xamarin.Forms project, so I didn’t have a UWP project. There really isn’t any reason that a UWP project couldn’t be added, or created independently. Likewise, you could easily share code in this way with an UNO Platform project or a non-Xamarin.Forms UWP project.

I am super-hopeful that in the next few years, after we successfully deliver a cool Blazor app that is C# front and back, and the client says, “This is really great, now can we do something similar in a mobile app?”. I can say “Heck, yeah!” and smile to myself because now I can happily and confidently reuse a whole bunch of code.