The Modern .NET Show
A blurry image of source code, too blurry to read, take the place of the background. Layered over that are the headshot of Matt Goldman and a purple robot holding a microphone; these are on either side of the centre of the image. Above both is the heading 'THE MODERN .NET SHOW' in bold, white text.

S06E01 - Building Cross-Platform Apps with .NET MAUI: A Developer's Dream Come True with Matt Goldman

Embedded Player

S06E01 - Building Cross-Platform Apps with .NET MAUI: A Developer’s Dream Come True with Matt Goldman
The .NET Core Podcast

S06E01 - Building Cross-Platform Apps with .NET MAUI: A Developer's Dream Come True with Matt Goldman

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

The world of app development is constantly evolving, and .NET developers are no exception. This episode features Matt Goldman, a solution architect at SSW, who shares his insights on .NET MAUI, a powerful tool for building mobile and desktop apps.

Goldman has written a book called “.NET MAUI in Action”, which aims to make the journey of learning .NET MAUI easier for .NET developers. The book is designed to have a lower barrier to entry than books on, say Xamarin Forms, which required expertise in Android or iOS. It takes a procedural approach, with readers building an app alongside Goldman. The book covers basic intro apps, including a “hello world” app and an app for sharing location.

According to Goldman, the core components of UI are layout, color, and typography, and a good UI requires a strong layout. XAML is the de facto standard for creating UIs in .NET MAUI, and Goldman likes it because it separates UI into markup and code, which is similar to his experience with Angular.

The book covers all four main platforms of .NET MAUI: Android, iOS, Windows, and macOS, as well as other platforms like Tizen and watchOS. It includes a major project that is enterprise-focused and demonstrates full stack code sharing and design patterns like MVVM. The final chapter of the book covers how to build and deploy apps to the stores using GitHub Actions.

One of the most exciting features of .NET MAUI is Blazor Hybrid says Goldman; this is a tool that allows developers to build an app that can run on multiple platforms, including macOS, Windows, iOS, Android, and watches or TVs. It enables developers to write their UI in Blazor, a web technology, while the rest of the code runs as .NET managed code on the device. This approach provides the benefits of full access to platform APIs, true multithreading, and the ability to share code and UI components between different apps and platforms.

Blazor Hybrid is different from other cross-platform app development technologies, such as Ionic or Cordova, which wrap a web app in an executable that runs a browser without first-party support for platform APIs. React Native, on the other hand, compiles down to native platform code. Blazor Hybrid provides developers with a choice of UI frameworks, including XAML, C#, and Blazor.

Episode Transcription

Welcome to The Modern .NET Show! Formerly known as The .NET Core Podcast, we are the go-to podcast for all .NET developers worldwide and I am your host Jamie “GaProgMan” Taylor.

In this episode, I spoke with Matt Goldman about .NET MAUI and his recently published book “.NET MAUI in Action”. His new book is about .NET MAUI, but also contains some lessons on UI design, such as:

And you can have a really good UI in black and white with one typeface, but all the fancy iconography and color and typography in the world isn’t going to rescue a bad layout.

- Matt Goldman

Matt’s book, as you’ll find out, aims to make the journey of learning .NET MAUI easier for developers.

One of the most exciting features of .NET MAUI is it’s links with Blazor Hybrid, a tool that allows developers to build an app that can run on multiple platforms, including macOS, Windows, iOS, Android, and watches or TVs. We go into this in the episode, but a tl;dr for Blazor Hybrid is that it enables developers to write their UI in Blazor, a web technology, while the rest of the code runs as .NET managed code on the device. This approach provides the benefits of full access to platform APIs, true multithreading, and the ability to share code and UI components between different apps and platforms.

Oh, and make sure you stick around to the end of the episode too, as Matt has a discount code which is good for 35% off the price of his new book.

So let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : You. So thanks for being with us. Matt. I realized that the listeners may not be able to detect it just yet, but we are literally on other sides of the planet, like as far apart as we possibly could be. So that means time zones are a bit wobbly. So thank you for spending part of your evening, my morning, whatever time of the day people are listening that time with us. So I really appreciate get it.

Matt : No worries. Thank you for having me.

Jamie : Hey, no worries at all. No worries at all. So I wondered, would you mind sort of sharing a little bit about yourself? Maybe an elevator pitch for Matt and maybe not the clients he works with, but like the work that he does, that kind of stuff. I’m talking about you as if I’m talking in the third person. I shouldn’t really do that, but anyway, let’s go with it.

Matt : Yeah, sure. Okay. So my name is Matt. I work for a company here in Australia called SSW. We’ve got a few offices here in Australia and as well as in China and now in France. I’m a solution architect. I do a variety of full stack development work for clients and my two areas that I kind of specialize in are mobile and desktop dev. Hence the book, the .NET MAUI stuff. And the other one that I do a bit of is security and authentication.

Jamie : Awesome. Okay. Yeah, I have to admit my experience of .NET stuff on the desktop is WinForms in 2008. And my experience of .NET on the mobile side of it was this time last year I helped an apprentice of mine build an app with very, very early pre release version of .NET MAUI. And we got that out the door. But yeah, I think things have changed. I don’t know.

Matt : Yeah, things have changed a little bit. Not much. If you’ve already done that you’ve probably got a fairly good understanding of how things work. The things that have changed are kind of refinements and quality of life improvements and bug fixes.

Jamie : Oh cool. Okay, well, I mean, I’ll have to go check it out after this, after this recording.

But what’s more important to me is that you get a chance to talk about the book. So you mentioned it in passing. We talked about .NET MAUI, we’ve talked a little bit about desktop and .NET MAUI stuff. So what is the book?

Matt : Yeah, so the book is called “.NET MAUI in Action” and it’s a book that is for .NET developers to learn .NET MAUI. I’ll talk a little bit about kind of why I wrote the book and my approach and that might explain what the book is and who it’s for. A lot of people that work on .NET MAUI and previously on Xamarin forms and Xamarin, that kind of stuff, I find they tend to be experts in Android or iOS or both and then they come to this tool which was previously Xamarin Forms. And now we’ve got a new tool which is .NET MAUI. And they come to this tool and they look at it and think, “this is great. This lets me use my existing skills, my existing expertise in Android or in iOS and lets me use that expertise to build apps in a single code base."

I didn’t come from it from that angle at all. I looked at Xamarin and thought, “wow, this is great. I know how to do .NET and I want to build mobile apps. So now I can use this tool and I don’t have to be an expert in Android or iOS.” That proved to be completely wrong. And I hear a lot that this is a common experience with people that that were interested in Xamarin because they were in the same boat, they were .NET devs, and they heard there was this cool tool that was going to let them build mobile apps. And they thought, “oh great.” And they gave it a try. And the learning curve is very steep and the barrier to entry was very high up until probably version sort of 3.5 of Xamarin Forms if you weren’t already an expert in Android or iOS, you were going to have a very, very hard time. So I guess in my case, I persevered because I was motivated and I really did want to build mobile apps. So I pushed through and I learned and as I progressed as a Xamarin Forms developer, I did learn more about Android and iOS. But it was very much it wasn’t for .NET developers who just wanted to build mobile apps. It was for iOS and Android API experts who were also .NET developers who wanted to use a single code base.

So with .NET MAUI, it’s more than a relaunch of Xamarin Forms. It’s a rebuild from the ground up and it shares a lot of the DNA. So by that we mean the architecture of - I’ll get into this a bit later on, but - the architecture of how it works under the hood is the same, but philosophically, it’s top down. So philosophically, the technology is built for .NET developers. And of course, as you get more sophisticated as a developer in .NET MAUI, and as you learn more about it, and as you become more proficient, you will naturally learn more about the underlying platforms. And knowing more about those underlying platforms is going to help you be a better .NET MAUI developer. But the key difference is you don’t have to already be an expert to come and give it a go and learn it. And the barrier of entry is much lower in that respect.

And I was really on board with that. And that was something that from my own experiences, I was kind of quite passionate about; and that was really the motivating factor and the driving force behind the book. For me, writing the book was I really wanted to make that journey easier for .NET devs. I wanted it to be accessible and I wanted people to be able to come and learn to build these mobile and desktop apps using this technology and using the skills they already have with a lower barrier to entry, and without having to have that expertise in other fields.

So with that in mind, that is really what the whole book is based on. So it’s a book that is for .NET developers that want to learn to build mobile and desktop apps. As you go through the book, you’ll learn a bit about the platforms but you don’t already have to know that. All you have to do is have a basic understanding of .NET. If you’re already a .NET developer, you’re already a .NET MAUI developer. You just have to find your way and that’s what the book is for.

Jamie : Awesome.

As someone who managed to skip over everything after WinForms up to .NET MAUI, I found it rather difficult to get into the entire thing. I was like, “wait, hang on, there’s some underlying stuff that I don’t know here. Putting aside the iOS and Android stuff that is specific to iOS and Android, just like how do I draw a button?”

Matt : Yeah.

Jamie : Like all of that. Like I missed a whole bunch of stuff because I feel like, and this may be specific to me, but because I came from my first couple of dalliances with .NET on the desktop were WinForms and then I dropped off of that and became sort of server side expert. I felt like there was this whole world that moved on without me and I felt like when .NET MAUI first came out I was like, wait, “hang on. There’s this whole world of information I’m supposed to know about."

This isn’t me trying to throw a shade on Microsoft or anyone who wrote the docs, but, like, for people like me who either missed WPF and XAML and all that kind of stuff or people who weren’t developers at that time, it seemed like it was like, “hey, here’s all of this background information we expect you to have to be able to come and do this.”

Matt : Yeah, well, I mean, I don’t think that’s unique to .NET MAUI and I think with the Microsoft docs that’s kind of common for everything. The docs are really there as a reference, they’re not there as a learning resource. Of course, we have got Microsoft Learn now as well. And in fact in Microsoft Learn there is a learning pathway that teaches you .NET MAUI, but it’s not really that hands on. It’s kind of a bit conceptual. Yeah, exactly. That’s where a book like this comes in. All of the information that you need is there in the Microsoft documentation but it’s not going to walk you through it in a procedural manner that’s going to take you from not knowing anything to being able to actually come back and use those docs as a reference in the way that they’re meant to be used.

Jamie : Sure. Okay, so with that in mind then, is it? And I’m asking this, I haven’t read the book yet. I’ve got my copy on order. It will arrive at some point after we’ve recorded this, but before people hear it.

Reading the book. Then I’m presuming that as a reader, I’m going to be building an app alongside you, right?

Matt : Yeah, that’s right. Yeah. So we start off in the first part of the book with a couple of very basic intro apps. Like you’ve got your typical “hello, world,” of course, I called it “aloha, world” because it’s MAUI.

So we introduced some real basics of you mentioned XAML already. XAML, which stands for Extensible Application Markup language, is kind of the de facto standard way of creating UIs in MAUI. Of course, you don’t have to use that, there’s other ways to do it as well. But the book focuses on that because that’s really the main way that people build apps with .NET MAUI. And I think that even if you’re going to go and do something else, you probably should learn that first and have a good understanding of it. And also, to be honest, I like it and a lot of people don’t, and that’s fine, but I like it because I really like the separation of UI into markup and code. I do a bit of Angular as well, so I’m just used to that approach and it’s kind of very similar.

But anyway, yeah, so we start off with a bit of an intro to that and then some intro into how .NET works with the cross platform APIs that are not UI based. So there’s an app that we build in the beginning to share your location, for example. And then we start to get a little bit more advanced with a to do app.

And then we’d start moving on to the main thing of what UI is about, right? Which is layout. So there’s a lot of different ways to do layout, and I make this claim boldly. I’m really not a designer. I’m not a UX or UI designer, and anything where I’m left to design it myself just looks terrible. So I have bought a couple of books from experts on this topic and they kind of say that there’s a lot of different things that make up a UI, but the core components would be layout, color and typography. And you can have a really good UI in black and white with one typeface, but all the fancy iconography and color and typography in the world isn’t going to rescue a bad layout. So I talk a lot about layout and do a couple more sort of basic apps. I get, I guess, some fun apps just to try and teach these concepts.

And about halfway through the book, we move on to the major project, which we then build throughout the rest of the book and that’s more sort of enterprise focus. So it’s an app that’s got a mobile and desktop client that do slightly different - they mostly do the same thing. They do slightly different things towards the end of the book, really just to demonstrate the capability of .NET MAUI to cater to those different platforms. But it’s really focused more on some enterprise development practices. Full stack code sharing, some of the design patterns that you use in .NET MAUI, like MVVM, which you may or may not be familiar with.

You start off really the first third to half of the book with these much smaller, self contained projects, and then the latter half of the book is this big project that you build throughout the rest of the book.

Jamie : Right, I see. So you mentioned both iOS and Android, but is there like a are you targeting a desktop as well or is it just like like, “you can if you want to, but the point of the book is to teach you iOS and Android”?

Matt : Absolutely not at all. No, sorry. I did mention that earlier when we were talking about Xamarin.

So Xamarin was mostly focused on iOS and Android. In fact, the history well, I don’t know how much time we have, and I talk about this in the book a little bit at the beginning and I do love the history of this stuff. But it started off with there’s an open source implementation of .NET called Mono, which I’m sure you know of. In fact it’s now what what powers.net on macOS and Linux. But Mono was developed independently of Microsoft originally, and then the guys that built it eventually created a version called MonoDroid for Android and MonoTouch for iOS, which is basically just the .NET runtime for Android and iOS.

This then evolved into Xamarin - Xamarin.Android and Xamarin.iOS, which was not just the runtime, but actually an abstraction of all those platform APIs. So if you were going to write an iOS app, if you were going to do it in Swift or Objective C, you would obviously have access to a bunch of APIs that the operating system provides, that Apple provides to developers. So Xamarin.iOS was actually an abstraction in .NET of all of those APIs as well. Then they did the same thing for Android, which was Xamarin.Android, and then later on they created a cross platform UI layer called Xamarin Forms. So underneath Xamarin Forms, you had Xamarin.Android and Xamarin.iOS. And then you had Xamarin Forms, which allowed you to not just share your code, sort of your logic, your shared logic, but also your UI across both of those platforms. So later on you were able to run Xamarin on other platforms as well, which would have been Windows Phone and then UWP, which then allowed you to do Windows as well, and eventually macOS.

So with .NET MAUI, it supports four platforms, four main platforms, I guess, out the box. And I say main. When I say “main,” I mean probably the most used. So that would be Android, iOS, Windows, and macOS. It also supports some other platforms as well, like Tizen for TVs, watchOS, GearOs, all the kind of things as well. But the core target platforms, and again, I say “core” in terms of usage, as opposed to what it primarily targets, would be the two main mobile OSes and the two main desktop OSes.

And sorry to get back to your question in the book. The book is absolutely about all of them. So throughout the book, I cover all those platforms. I really do try and focus on .NET MAUI as a shared code base as much as possible. So there is some platform specific code that we go into in the book. But really the main point of the book is to say, “look, here’s an app that you can write that you can run on any one of these things. You just got to choose what build you want to implement."

And then again, with that said, there are parts of the book where I show you how to tailor that experience to specific platforms. Not necessarily specific OSes, but more idioms they’re called. So you can say, “if it’s running on a desktop, behave this way. If you’re running on a mobile, behave this way.”

Jamie : Right, I see. Okay. That’s kind of useful because then I guess I don’t need to have any kind of simulators or emulators installed on my machine to follow along with the book. Right. I can just hit, like, run in whatever IDE I’m using, and it should be able to pick up that, “hey, you’re on macOS. I will load it as if it’s on a macOS computer. Hey, you’re on windows ten. Windows eleven.” I will just show you it using the I guess it’s Win UI. I guess I’m not sure it is Win UI.

Matt : Yeah. And that’s 100% correct. And that’s kind of how it works out the box. Yeah.

Jamie : That’s really cool. Because then I suppose from that point, then you can develop with whatever you have to hand, rather than if you have an Android device, setting it up so you can use that, or if you have an i[OS] device, setting that up, and Xcode and all the other bits and pieces you might need to set up.

Matt : That’s right, yeah. Now, with that said, if you are targeting those platforms, it does help. I mean, look, if you want to target iOS or Android, you’re going to have to at least test it in the simulator. So in iOS, it’s the simulator. In android. It’s the emulator. You have to at least test it in those. I talk about this a little bit in the book as well. If you want to be a cross platform developer, you should have access to all of the platforms that you’re developing for. And it’s kind of like, you know, web design in the early two thousands, you know, when, when you wanted to build a web page or, you know, a web app, you had to have every single browser on every single operating system and test it in each of them. So it’s not quite that bad, but you get the idea.

Jamie : Yeah, okay. I happen to know from my own experience, experience of doing .NET MAUI stuff that there is some CI/CD support for it. Do you talk about that in the book as well? Or is it just like, “hey, I’m going to teach you how to build the app, we’re going to build something together and then if you want to, you can go ahead and learn that outside of the scope of the book”?

Matt : Well, actually the final chapter of the book, there’s a whole chapter on how to build and deploy your apps to the stores using GitHub Actions.

Jamie : Oh, awesome. Okay. So it literally is, “start to finish, let’s get an app on a device.”

Matt : Yeah, that’s right. That’s exactly right.

Not just onto a device, there’s an appendix on setting things up. So for running and testing on your device, you can do that, but literally distributing and publishing to the stores via GitHub actions.

Jamie : Right. That’s really cool. Okay, so it’s quite literally, “I have an idea.” up to, “my mum has downloaded my app from the Public App Store.”

Matt : Exactly. Yeah. In fact, it’s kind of pitched from that exact scenario. So the bigger sort of project app that you build throughout the latter half of the book is pitched in terms of this scenario and it sort of puts you on this enterprise development team and you’re building an app for a client and it absolutely start to finish, from ideation through to deployment to the stores.

Jamie : Cool. All right.

How do I put this? In the project for the book? Are you talking to any public APIs or is it just like, hey, we’ll just do this project and we’ll do this thing. And then if you want to, you can use like HttpClient or GrpcClient to talk to something at a later stage?

Matt : So in the earlier samples there’s a couple where we talk to public APIs; there’s two specifically.

In the major project because it positions you as part of this enterprise development team and because I really want to kind of show the benefit of having .NET MAUI as a UI, which is that it’s part of your full stack .NET solution. So for that major project, it’s an API - so I don’t get you to build the API, I give you the code already. So you download a starter project and that’s got it’s got a full stack solution pretty much ready to go. You just got to plug the UI into it. So you would need to run that locally.

Jamie : Okay, cool. That makes sense. right?

So what you’re saying is there’s going to be hundreds of thousands of people produce .NET MAUI apps that basically look and feel a lot like the one in the .NET MAUI in action book. Probably the same API.

Matt : The are about hundreds of thousands. That’s the dream. Of course.

Jamie : Awesome. Okay, so we’ve talked a little bit about the book, we’ve talked a little bit about the history of MAUI and we’ve talked a little bit about what we can make with it. You said you can make an app for the four main targets - there are other targets as well - but the four main targets are iOS, Android, Windows desktop and macOS desktop. And this is throwing a curveball. I appreciate this one. It’s coming out of nowhere. What about Blazor Hybrid? I’m not asking about whether it’s in the book, but is that a target that you can use with .NET MAUI? I don’t know.

Matt : 100% you can. So there’s two questions there. Well, it’s not in the book and I talk about it a little bit, but I don’t go through demos of that. And I’ll explain why in a minute. But let me explain what Blazor hybrid is.

So with .NET MAUI, earlier on when I talked about the history, right, I said that there’s a kind of really cool diagram that Microsoft have and I’ve kind of got my own version of it in the book. But if you look at it bottom up, you’ve got the operating system, and then you’ve got operating system APIs, and then you’ve got the Runtime, which is various different .NET runtimes depending on which platform you’re on. Then you’ve got the base class library as the next layer up. And then on top of that you’ve got .NET for Android, .NET for iOS, .NET for Windows, .NET for macOS. So these are what have evolved out of that Xamarin.Android [and] Xamarin.iOS But essentially this is the platform’s APIs abstracted into .NET. And on top of that, a layer across that you have .NET MAUI. .NET MAUI provides you things like XAML, right? And lets you do things like the UI.

It also has some shared non UI based stuff like the example I said earlier was location sharing. So if you want to share location, you don’t have to know how to share location in Android or Windows or what have you. You just call the API provided by .NET MAUI and at compile time that gets translated into the appropriate API for that platform. Now, we mentioned, does that make sense?

Jamie : Yeah, sorry.

Matt : It sounded like you had a light bulb moment.

Jamie : Yeah, well, I was sitting there thinking, “I wonder whether it’s translated runtime or compile time, because runtime would be quite slow.”

Matt : Yeah, it’s at compile time.

So the final layer that I mentioned at the absolute top there is the UI. And I mentioned earlier that I talk about XAML in the book because it’s the main way of doing things, but it’s not the only way of doing things. So another way is C#. So you can write your UI in C# out of the box. There are also some really good markup extensions in the Community toolkit - the .NET MAUI Community toolkit that let you write your UI in C# declaratively. So if you’re into declarative UI, if you’ve come from other - I don’t want to kind of muddy the waters a bit, but if you come from other UI frameworks that do things like the Elm architecture or MVU or that kind of stuff, that’s an approach that people generally like.

But there’s another option, and that’s Blazor. And this is what Blazor hybrid is.

So you can actually build an app in .NET MAUI that can run on macOS, Windows, iOS, Android, any of the watches or TVs that it supports. And you can write all of your app in .NET MAUI and write your UI in Blazor. And this is really cool. And the way it works is really awesome. Some people might have seen similar technologies where you can write a cross platform app using a web technology. So there’s things like ionic or cordova, react native - React native is different because it’s actually in the same category as MAUI.

I’ll come back to that. But often what you see is a wrapper. So you get a web app, which is basically a single page application. So the runtime is it runs inside the browser’s runtime as opposed to having service side rendered pages, and you wrap that in effectively what’s an executable that just runs a browser that doesn’t have any navigation or show anything other than your one single page application. These are a little bit limited in that they don’t have first party support for platform APIs. They also are still the runtime is still a browser, so you’ve got a single thread running in a browser. React native is a bit different because React native actually does compile down to native platform code. With Blazor hybrid, you’ve got another story altogether.

So with Blazor hybrid, it’s literally just the UI that’s rendered in a WebView. All of the other code runs as .NET managed code by the .NET runtime. So whether it’s AOT or JIT or whatever, that’s configurable as well. But the point is that it’s .NET managed code. A really good way of thinking about this is do you know the two different models of how Blazor works with WebAssembly and Blazor Server?

Jamie : Yeah. So I do, in that I’ve built a bunch of Blazor apps. My understanding is Blazor server, your app, still sort of the server side component, the API side, the UI, everything is still rendered on the server. And then there’s a SignalR connection where the UI running on the client then puts in a request for, “hey, the user has clicked this button, give me the UI changes that need to happen and I will display them on screen using like a similar to the DOM,” I think it’s similar to shadow DOM. The way that react works and then Blazor WebAssembly is the entire app and all of its stuff is downloaded into the browser, runs inside of WebAssembly and runs that way.

Matt : Yeah, that’s exactly right. Yeah. So the reason I was asking you about that is because a good way of thinking about how Blazor Hybrid apps works is that they basically work like Blazor server, except for the server is your device. So if you’re running your Blazor Hybrid app on iOS, it’s running exactly the same way: you’ve got a WebView rendering your UI, but all of the code isn’t running in that web view, it’s running on your device. And there’s that connection between the UI - I’m doing air quotes here, which you can’t see - “server.” But that server is also running locally as well. But the point is that it’s a compiled .NET managed code app running with all the benefits of that, with full access to platform APIs, true multithreading, all that sort of stuff, but then you’ve got the UI rendered in Blazor on the same device.

Jamie : Right, okay. So the way I’m kind of thinking about that is if folks don’t know Rider and ReSharper kind of work in that way, in that there is a client that runs like from a JetBrains Rider perspective: the IDE you are interacting with is the client. And when you want to do ReSharper like things or code inspection things, there is a server-like thing running on your computer that does all of the C# stuff. So they’ve kind of separated their app in a similar way, but they don’t use .NET MAUI or Blazor or anything like that. It just sort of works in a similar way.

Matt : Yeah, that’s right.

So Blazor Hybrid is kind of a best of both worlds in many sense, particularly if you’ve got a full stack solution and you’ve got a Blazor Web UI and you’ve got your mobile and desktop UI as well, you can share not just code between them. And by the way, with this full stack code sharing, I talk about that in the book and I show how you can share code across the stack. And I’ve got a talk which there’s a video online, I can give you the link last year where I showed Show to share show to do this as well. Expand on that a bit. And also talk about sharing code between a Blazor UI and a .NET MAUI UI, but you can also share UI as well. So if you’re doing Blazor Hybrid for your MAUI UI, you could have a whole bunch of UI components in a Razor class library and have those consumed by your Blazor UI and your .NET MAUI app as well, which is really cool.

Jamie : Yeah, so then instead of having to use like if your team’s specific skill set lies in doing Razor stuff, then you don’t need to have everyone relearn how to do XAML or indeed that declarative C# stuff. You could just say, “hey, we will just use this sort of Razor stuff that we can wrap in perhaps a Blazor app or just put in a common library and call it from there.” Am I understanding that correctly?

Matt : 100% exactly. Yeah.

I talk a bit more about this in the book as well, but even goes beyond that, right? If you’re say a larger enterprise with some particular branding and a particular way that you present your UI, you’re not just talking about sharing code between and not just talking about sharing UI between a desktop app and - sorry, a web app and a desktop and mobile app that’s essentially doing the same thing. If you’ve got a whole suite of different products, you can even share common code and common UI between all of them.

And then when your marketing department comes up and comes to you and says, “right, we’ve had the designers do a rebrand and now all of our updates, all of our apps need to be updated and now need to look a new way.” You can update your shared UI library and your Razor class library and then all of your Blazor web apps and your .NET MAUI Blazor Hybrid apps would all be updated straight away as well.

Jamie : That’s awesome because yeah, one of the things for me when it comes to XAML was like, “how do I style it?” I’m guessing there’s some kind of sort of CSS-like styling stuff, right?

Matt : So there is styling that you can do it’s in XML.

There is a way that you can use a CSS-like syntax, it’s called CSS in the documentation and you write it just like CSS. The reason I try to avoid that is I find that it can be confusing for Xamarin Forms or .NET MAUI developers because they think it’s actual CSS and they think that they can use all the CSS they use in web apps. And you can’t, there’s a specific set of styles that you can use in .NET MAUI and the CSS approach is a way that lets you write those in a CSS like format, but you’re still going to have the same set of styling things you can do. I prefer to use the kind of the default .NET MAUI way of just using a styles file in XML and I cover that in the book.

Jamie : Sure. And that makes sense, right? Because if you’re doing something, the framework way of doing it, then when you get stuck or when you get confused, you can go to your resources, the book, go to Google, go to Stack overflow wherever and say, “hey, I’m doing this thing in the way that the framework wants me to do it and it’s not working. What have I not done correctly? Or what am I misunderstanding or where have I gone wrong?” And anyone else who uses that framework should, in theory be able to pick up your question and go, “right, no, I understand what you’ve done there. Let’s talk about this thing and let’s see if we can fix it for you.”

Matt : Yeah, it’s the same with anything, right? With any kind of framework or platform? Yeah, I also, as I said, I find it helps reduce confusion because when you’re looking at a file that’s written as a CSS file and you’re trying to write some CSS and wondering why it’s not working, and then you realize, “oh, I’m actually not writing CSS, I’m writing .NET MAUI CSS.”

Jamie : Sure.

Matt : But I don’t want to diminish it. Some people like that approach and it’s definitely in use, otherwise I wouldn’t keep supporting it.

Jamie : Oh, totally. Yeah. Okay, so if we take a little bit of a step back, you mentioned a little bit of the history of how we got to .NET MAUI. It includes talking about Xamarin and Xamarin forms and going even back further to Mono and MonoDroid and MonoTouch and stuff like that.

So .NET MAUI very new. Are there Xamarin things I can do with .NET maui. So let’s say I am a Xamarin app developer and I’ve done things the Xamarin way since I picked it up. So I picked up Xamarin and .NET MAUI comes out and I get your book and I start learning it and I’m like, “right, okay. Yeah. But last year when I was doing Xamarin development, we did it this way."

Or is it the same sort of stuff, just evolved? I guess there’s like several parts to this question, right? Can I bring in Xamarin things I’ve done before as long as I format it correctly? Or is it like I’ve got to throw all of my knowledge away and start again?

Matt : No, not at all.

If you’re already a Xamarin developer or a Xamarin forms developer, you’ll find [.NET] MAUI very easy to learn. A lot of your existing knowledge and skills and everything you’ve learned is still applicable. What you’ll find is there are things that have changed, but the things that have changed are things that will make you not want to ever go back to Xamarin again.

So for example, there’s the generic host builder pattern that is now used in, in every .NET app. You now have that in .NET MAUI. You’ve got built in dependency injection, all that kind of good stuff that we’re used to, the luxuries that we’re used to when we build server or cloud apps in ASP .NET core. You’ve got that in .NET MAUI now as well.

The other things that you’ll find that are different are if you have been working with Xamarin for a long time and you’ve got a list of libraries that you’re very familiar and comfortable with, a lot of them haven’t been ported to MAUI. Some of them have got analogues that have been built by other people. So that’s kind of where I see some people getting tripped up, but I guess those are kind of implementation details. The skills and the knowledge that you’ve acquired by being a Xamarin developer will still be applicable in .NET MAUI.

Jamie : Right, okay.

So let’s say I’ve spent some time and I feel like this is leading on to the next bit, but let’s say I’ve spent some time previously learning MVVM or MVU or we talked about, you mentioned a whole bunch of other things, like Elm and stuff like that. Let’s say I’ve learned one way, one architecture pattern of separating my user interface from my services, right? Because that’s essentially what we’re doing. I mean, there’s loads and more to it than that, but that’s essentially what we’re doing.

If I’ve learnt one way of doing it, and there is a library to help me do that, I can literally just plug it in, right? I can go, “oh, cool, I will pull in the Community MVVM Toolkit.” Guess what? I could do MVVM in my app, right?

Matt : In that particular case, yes.

So the MVVM pattern is still very much applicable in .NET MAUI. I’ve got a whole chapter on it in the book, and I don’t want to harp on about this too much, but I’m actually really proud of that chapter because I think MVVM can be a bit of a daunting topic. It’s really not actually. It’s quite simple to understand, but it’s quite difficult to explain, I think, or quite difficult to learn. And I’m really proud of that chapter. It’s something that I spent a long time thinking about, “how am I going to explain this? How am I going to teach this?” So I put a lot of work into that and I’m quite happy with how that turned out. So the point being that, yes, MVVM is still in use, and you mentioned MVU, and that’s still in use via Community support as well.

In terms of plugging in your libraries that you’re familiar with, the MVVM Community Toolkit 100% that works with .NET MAUI. I use it all the time. I love it. Some other MVVM frameworks, it depends on the framework. Some of them have been ported to MAUI.

The other thing that I find is that an MVVM framework itself is probably not as necessary in .NET MAUI as it may have been in Xamarin forms. So I mentioned that the generic host builder pattern and dependency injection, a lot of the heavy lifting that the MVVM frameworks that we used in Xamarin Forms did was providing those capabilities for us. Now that they come out of the box, you really don’t need any kind of MVVM framework. You can build apps using the MVVM pattern just with .NET MAUI. And there’s a couple of useful things that you can plug in to make it a bit easier. Like the MVVM community toolkit. I’ve got a plugin available on NuGet called Page Resolver, which kind of makes things a bit easier with the MVVM pattern as well. But these are kind of lightweight. These are not opinionated heavyweight frameworks like some of the other ones that we used in Xamarin were.

Jamie : Cool. Okay. I mean, that makes sense, right? If the framework I feel like I’m overusing the word “framework,” but if .NET MAUI .NET provides me with the ability to do DI, then I don’t need something that has MVVM and DI anymore. Unless, of course, I’m used to and like the way that the DI works in my MVVM and DI framework. Right?

Matt : Yeah, absolutely.

In my day job at SSW, I’m part of a team that we’ve got a team that looks after kind of software architecture stuff. And we’re currently working on our new version of clean architecture template, as well as other architectures like vertical slice and all the other kind of things. And one of the lessons that we’ve learned as a group recently well, I say recently, over the past years or a few years, we’ve really come to the conclusion that having an architectural pattern, having a framework that is defined, is much more important than what framework or pattern you choose.

If you’ve got something that is really well defined, anyone can come along and say, “okay, this is how this has been built. If I need to change something or add a feature, this is how I’m going to do it.” The benefits of that outweigh the specific benefits of the particulars of any kind of implementation. Just having that well defined architecture is already a win.

So that’s a long winded way of saying in answer to your question. Yeah. If you’re already familiar with if your team is already using Prism, if your team is already using whatever other MVVM framework, and that’s how you work efficiently and that’s what you do. Absolutely. Keep doing it.

Jamie : Cool. All right.

Okay. Right. I’m going to throw this one out there because you’ve mentioned that you spent a lot of time thinking about how to teach people or get the ideas of MVVM across to people, and you’re quite proud of the chapter on MVVM. And you said that sometimes it’s difficult to impress upon people the, I suppose the point might be the wrong word, but the ideas behind MVVM.

Matt : Yeah.

Jamie : What is MVVM?

Matt : Good question.

MVVM is a design pattern that’s used for building UI apps in XAML. It’s short for Model, View, View-model. The order of those is potentially confusing, and the meaning of them is potentially confusing as well. Microsoft actually gave us this pattern alongside WPF. Effectively, it’s a design pattern that tells you to separate your concerns. So the model this is where it gets a bit confusing.

The model in MVVM is actually essentially your whole domain model or your service layer, whatever you want to call it. Right. So it’s your services, your entities, all that kind of stuff, all of your application logic. It’s not a model in the sense of MVC or an entity. Right. It’s not a modern. In that sense, it’s the model, the whole model of your app, that’s the M, in MVVM.

View, is obviously the UI. And that is defined as two things. It’s effectively layout and behaviour. Layout being what it says on the tin. This is what goes where on the screen. And behaviour is how those things behave in response to changes in the model. And I’ll come back with some definitions of those.

And the View model is the glue that holds it all together. So the View model is effectively, it does two things. It provides some glue between the view and the model, and it also provides state for the view.

So I’ll give you one example that’s out of the book, right? So a difference between UI behaviour and, say, state and UI logic, right? So, in the book, an example I give is a switch. Let’s say you’ve got a switch control on your screen. The state of that switch is whether it’s on or off. The behaviour of that switch might be that when it’s on, its background is green, and when it’s off, its background is red.

Where I see a lot of people getting tripped up. And I have heard this talked about a lot. Some people think that when you’re doing MVVM, you have to go all in an MVVM. And a lot of people think I can’t have any code in my UI at all. And that’s just not true. It’s just knowing what code goes where and what the purpose of that code is. So you can sometimes see people doing some mental gymnastics and jumping through some hoops to try and get the code that changes the background color of that switch out of the UI, out of the View altogether, and put it in the view model.

And that’s not correct, and you’re just giving yourself pain for no reason, right? It’s perfectly, perfectly reasonable in the MVVM pattern to have the code that defines what color the background of a switch is in the view. That’s where it belongs. Because it’s UI behaviour, it’s specific to the view. Whereas that state of the switch, the switch might be bound to a property because it might represent some property of your model. So that on off might represent a boolean property of an entity, or it might be something that’s in a service or what have you, and that belongs in the view model.

Jamie : Right.

Matt : Is that just rambling or did that make sense?

Jamie : No, that made sense to me. That made sense to me.

Yeah. I have found in the past, trying to explain MVVM to people difficult. And I felt that that was likely because of the VM part in the middle, because the View-model, when I’ve explained it to people, I haven’t said that the model is the model. I’ve just said I’ve said it’s kind of like the services that you’re using, because most of the apps that I’ve built have talked to APIs, right? So it would be like my view would display some data that is pulled in from the view model. And the view model’s data is populated by talking to the model - aka service - which goes off somewhere. Doesn’t matter where it goes, “hey, I will go get this data for you."

And like you said, it’s like separating those concerns. The view just displays stuff. So it may have some logic in there to do with how do I display this? Not how do I get this? And view model might be, yeah, the view model is like, here is the data you need to display. And maybe I need to because I’m view modern, maybe I need to do something with that data before I give you it.

Or maybe I need to provide some methods for like maybe there’s some sorting or some paging or something. Or maybe there’s, “go get me the data from the web.” And so the view doesn’t need to talk to the web, but the view needs to talk to the view model, which then figures out, “do I need to talk to the web? Or can I talk to my service?” Or maybe you push that decision even further back and say, right, okay, view talks to the view model and says, get me the data. View model says, I don’t have the data. I will go to where I need to get the data from. Hey, model, where do I get the data from? And the model says, don’t worry fam, I got you, and goes and gets the data.

Matt : Yeah, that’s really good synopsis. Yeah, that’s pretty accurate.

The only thing that I would say to bear in mind is that the view doesn’t really talk to the view model. So you don’t write code to wire that up. You use data binding. Are you familiar with data binding?

Jamie : I am, but let’s presume the listeners aren’t.

Matt : Yeah.

So if if you’re not using MVVM or not using data binding at all, you might have let’s take a simple example of an app with one page. And the page has a box in it that says, “type your name into this box and click this button.” And when you click this button, it changes the value of a label on the screen to have your name that you put in that box. Right.

So without data binding, when you click that button, it will raise an event. So there’ll be an event handler in the code behind, and that code behind will then directly read the contents of the text box and then directly write the text property of the label on screen.

With data binding, you don’t write code to do that. You just say, “this button has a command. And the command that executes when someone clicks it is this.” And with this text box, the text property of this text box is bound to this text property somewhere else. It doesn’t even have to be the view model, because you don’t have to have MVVM to do data binding, and then the label would probably be bound to that same property as well.

So in fact, if you’re doing data binding, you don’t even need to click the button, you can type in the box and the label will change in real time as you type. But the point being is that you bind parts of the UI to parts of what’s called your binding context. And that binding context in MVVM is a view model.

So the point being that the UI doesn’t necessarily talk to the view model, it’s just bound to it, right?

Jamie : Yeah. That’s the problem that I’ve noticed with a lot of people like myself who have come from WinForms, where in that situation, if you’re building something like that in a WinForms context, you have a button, you double click it, it creates an event handler. Like you were saying, you then in the event handler go, “hey, textBox.Text,” do any kind of validation you need, and then set that to “hey, label.Value”, or label.Text set that to the value of textBox.Text, which exactly, I guess it flies in the face of that command pattern.

I’m worried about saying command pattern because there’s a different pattern called command pattern, but that sort of relay, I suppose, and the binding as well, because this is my understanding, is that by adding an event handler, you’re interrupting the flow of the framework, which can do the binding for you. If you need to do any kind of validation, you can create perhaps a relay command that says, “when I click this button, go do some validation. Only when the validation passes, let me show that value in the text box or the label or wherever, otherwise don’t update the variable it’s bound to,” I guess, I don’t know, maybe I’m rambling a bit.

Matt : No, it makes sense, and there’s a few different ways of achieving that validation as well. But essentially you’re right. And the point is that we take away that need to write that kind of plumbing code and write that code that gets things from one place and sends them to another. You just bind it and you just say, “the text property of this label or this text box is represented by this property in this binding context. If it changes, change that. If that changes…” there’s actually an event called INotifyPropertyChanged that tells the UI that value has been updated. So the UI basically just listens for events.

Jamie : Right, I see.

Matt : The UI is then responsible for updating itself. And this is again part of the separation of concerns. And the single responsibility principle is that each part is just responsible for its own thing.

Jamie : Yeah, that makes perfect sense. And I feel like that’s the direction we should be going in with all of our code. Right? You don’t want something to be responsible for more than one thing you want it to be. The phrase I use is old hat: and it’s something that a lot of especially devs in the younger people than me is how I’ll put it. A lot of people who are younger than me tend to not get this, but I try to stick to what I call the Charles Emerson Winchester III rule: “I do one thing at a time. I do it very well and then I move on."

Your code should only ever do that one thing. It shouldn’t be if your code writes to the database, it shouldn’t be writing to the database, then putting an Http request, and then doing some logging, and then doing like changing the UI and then ordering a coffee and then falling over because it doesn’t have to order a coffee, all of that stuff. It should be my database code accesses the database and that’s it.

Matt : That’s right, yeah, exactly 100%.

Jamie : Okay, so where can folks go to learn about you and learn about the book then?

Matt : If you want to learn about me, probably the best place to start is GitHub. Just because I’ve got links on GitHub to everything else. So my GitHub ID is Matt-Goldman, M-A-T-T-G-O-L-D-M-A-N. On Twitter, I’m @mattgoldman. I can’t remember what I am on Mastodon, but there’s a link to it on my GitHub. I’ve got a YouTube channel as well, which is @goforgoldman. I’ve got a blog which is a website, which is goforgoldman.com.

Yeah, GitHub is probably the best place to start. The book is available, but the publisher is Manning. So you mentioned that you’ve ordered it, so thanks for that.

Jamie : No worries.

Matt : The book is available via the Manning website. It’s going to print right now, actually, so the print copies will be available in about two weeks from the time of the recording. So I think maybe when people are listening to this, it will already have been around for a while. You can get it from Amazon as well? Not Amazon Australia, disappointingly. So I can’t even buy it from Amazon in my own country. But if you get it from Manning directly, we actually have a discount code for your listeners.

Jamie : Oh, awesome.

Matt : Yeah, awesome. Yeah. So I can read that out if you like, or I can give you a link and give you the code and you can put it in the notes or whatever. I don’t know how you prefer to do that.

Jamie : Yeah, let’s do both because then people who - so a little peek behind the curtains for how I design the show, or my goal for the show is for people who are able to listen to the show can listen, and people who aren’t, either they have accessibility concerns or they’re just unable to listen at the moment. Maybe they can just read through a transcript better. There will be a transcript and both versions, the audio and the transcript will have the discount code in it.

Matt : Fantastic.

Jamie : Let’s do this.

Matt : Okay. All right, so the discount code is podnetcore23. So that’s Papa Oscar Delta November Echo Tango Charlie Oscar Romeo Echo 2 3.

It is valid from the 1 September from for three months. There’s a link, I mean, if you go to the Manning website, you’ll be able to find the book on there. There’s a link directly which is using a URL shortener which is http://mng.bz/orVv http MNG BZ and this is case sensitive. So it’s uppercase Q, uppercase P, lowercase R, number four.

Jamie : Sure. What I’ll do is for the folks who are listening along, that will be in the transcript as well. But also at the very bottom of the episode transcript and the stuff that’s showing inside your player, there’ll be a list of those. So it will have the discount code in there and the link to click to go ahead and find the book. There’s also a QR code that I’ve been sent as well, so maybe I can include that somehow. But how are you going to point up your phone at your phone screen whilst you’re listening? I’m not sure.

Matt : That’s the challenge, isn’t it?

Jamie : Best of luck. Yeah. Excellent. Okay. Well, Matt, it has been an absolute pleasure talking to you today. I’ve got a greater appreciation for all things .NET MAUI and I honestly can’t wait to receive the book so that I can build something with .NET MAUI.

I’ve got a whole bunch of ideas in my head that I want to get out there as apps, and even if it’s just, “hey, Mark,” so that’s the editor of the show, “hey Mark, I’ve got this great idea for an app. Why don’t you try it on your phone?” And then he says to me, “I’m not running any code that you’ve written on my phone,” and we have a big argument, but maybe that’s a different thing to worry about, but maybe that’s what I do.

Matt : I don’t know, maybe well, yeah, I’m glad to hear you ordered the book and I hope you enjoy it. And I’m also glad to hear you have a big backlog of projects for things you want to build. And by all means, give me a shout, ping me and let me know if you want me to help you out with any of that. I’m always happy to help.

Jamie : Awesome. Thank you ever so much.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest, Matt Goldman, for graciously sharing his time, expertise, and knowledge. Make sure to check out Matt’s book over at Manning and to use the discount code he mentioned to get 35% off your order of the book - remember, the discount code is only valid from September through to December of 2023.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice - head over to dotnetcore.show/review for ways to do that - reach out via our contact page, or join out discord server at dotnetcore.show/discord - all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places