>> Tune in to this week's
On .NET where my good friend Shaun and Brandon
on talking about how to create user interfaces in
C# for .NET MAUI, so tune in. [MUSIC] Welcome back everyone
to another On .NET. I'm your host, James Montemagno. If you're like me, you've
probably heard a lot about XAML, XML based markup, to create
user interfaces for .NET MAUI. But there's another way, in fact, you can build
it all completely in C#. I brought in my good friends, Shaun and Brandon, to talk about the .NET Community Toolkit for .NET MAUI.
How's it going guys? >> Hey, James. Thanks
for having us on. >> Yeah. It's good
to have you both on. Brandon and I, we've only worked
together for about 25 years. Shaun, it's good to see you back over here on YouTube
and on Channel 9. >> Thank you. It's good to be here. >> Yeah. We know
Brandon because he's on all the videos all the time,
so we don't care about him. But Shaun, what's
really awesome is that you've been a long time contributor
to Xamarin and on .NET MAUI. You want to talk a little
bit about yourself and how you got involved in
the community toolkits? >> Yes, sure. I'm Shaun Lawrence, I'm
a software engineer. I've been working with .NET building
.NET apps and primarily WPF for the majority of my
career and then that's eventually evolved to Xamarin
and obviously now onto MAUI. Last year I built a
game in Xamarin Forms, which led me to end
up consuming loads of useful bits from the
old community toolkit, and then ultimately ended up
wanting to give back to that. I ended up contributing and then things led on and then I've become a maintainer of
the toolkit itself. >> Very cool. How
about you, Brandon? Okay, maybe not everyone
knows who you are. >> Thanks James. Yeah. My
name's Brandon Minnick. I work as a Developer
Advocate at Microsoft. Like James mentioned,
we used to work together back at Xamarin
back in the day. It's really exciting for me to
see Xamarin come to fruition. Being evolved into .NET MAUI, be brought into the .NET SDK, and it just so happens
to be that I'm one of those few weird people
that like to make their Xamarin Forms and
.NET MAUI UIs all in C#. So that's what we'll
be talking about today and showing you how to do it. >> Very cool. Now, we've done some previous episodes actually
on the .NET Community Toolkit, which works on all .NET
different applications if you're doing WPF or WinUI
or anything like that. Actually any .NET application
you can use it there. Specifically the MVVMs have so good. Then we just did an episode on just introductory to the .NET
MAUI Community Toolkit. If you missed that, go see it. I'll put it down in
the Show Notes and up over there on YouTube
and all the things. But what is this C# markup thing and why would I want to
create things in C#? Because you know me, I love my
XAML, I love my of data binding. Am I going to miss out on
all that stuff? What's up? >> Good question. Well, if you want, we've brought some slides and
so let's pull up some slides. I'll start with just a quick caveat that if you already know XAML, if you use XAML, you know it, you love it, you've been
successful with it, great. This is not an episode
bashing XAML at all, but rather to show off
that there is a way to do it without XAML doing
everything entirely in C#. We've created this NuGet package, this library called
CommunityToolKit.Maui.Markup that makes it even easier to make
all your UI code in C#. >> Okay, so you could already do it. Just like you could for XAML Forms. There is a C# API, but this is making you way more productive basically
if you want to go that route, because there are two
different types of developers. When I transitioned
from WinForms to WPF, the XAML thing clicked
immediately for me, I got it. But I work with so many developers
and I know both of you do too, that change is drastic
and some people are just really visual when it comes
to creating things in C#. >> Yeah. I know for me personally, when I joined Xamarin back when
we were our small little startup, I joined because I like C#. I like doing everything
in C#. Then I was introduced to XAML and I was like, nah, but I want to
do everything in C#. I've never used XAML before, so it didn't make any sense to me. Well, one of the
highlights we'll show off on a slide here with
one of the bullet points. But let's get on. We'll show off all the fun things. You will notice there are a couple of links at the
bottom of these slides. This link on the bottom right, codetraveler.io/maui-markup
is a web page that Shaun and I put together where you can find
everything from today's video. So including the slides links to the GitHub repo to
look at the source code, the sample app that we
made for the show today, you can find all of that there. If anybody does have any questions, we have our twitter handles
down here on the bottom left and that's the best way
to get in contact with us. I am @TheCodeTraveler
and Shaun is @Bijington, neither of which include our name so it's a little weird,
little confusing. >> Yeah. I'll put all links
down in the Share Notes >> Appreciate that. Well, let's kick it off and I'll hand
it over to Shaun. >> Okay. Thank you. I'm sure as James you know full well if you've
dealt with XAML in the past, refactoring things can actually
become quite painful at best. Obviously when you're
renaming things within C#, we don't have that problem because the compiler can actually tell
that there are references. If you decided to rename
your class, your view model, or even your properties, you'd automatically get
the refactoring done for you and managed for you
from Visual Studio. There are, of course, toolings
that have then solved the problem. You've got things like
[inaudible] that help in terms of XAML
refactoring side of things. But that's clear that
it is a pain point and someone has had to try
and solve that problem. Obviously with a quick benefit is there's less to a set up in
order to get this functionality. >> Yeah. I've often
had that issue where I gave a controller a
name for example, changed the name as XAML
and then I got to go change all my other code
all over the place. It's get it out of sync
basically is easier to do. >> Yeah. >> Yeah. To get to an easy win. Another one is performance. You do get slightly better
performance when you create your UIs in C# and
really what that boils down to is C# code is compiled whereas XAML is
interpreted at runtime. If you've done this in XAML, you'll probably recognize there's
that initialize component method and that runs at runtime and that's essentially parsing the
XAML that we've written. There is the XAML compiler
and that definitely helps, but XAMLC only compiles
some of the XAML, it doesn't get all of it. I should probably
change that to most of the XAML because it is really good. But anecdotally, I will say back in the day before we had
the XAML Compiler, I did a little test where I had an app that I wrote the
same UI twice, once in C#, once in XAML, and the
C# page loaded in about 70 milliseconds compared to 150 milliseconds
for the XAML page. Now that was before XAMLC. The XAML Compiler does
get it pretty close, so it's mostly negligible. But the C# UI will always load
just a little bit faster. >> If you want to tweak and tune performance basically
is what you're saying. Then also now at least
the compilation for XAML is on by default in all
.NET MAUI applications, which is also awesome. I think one thing too that sometimes I forget is compiled bindings, there's actually some other
layers of things that you can do where you may not
have to do in C#, correct? >> Yeah. Compiled bindings will also help load things
even faster as well. I highly recommend those
for XAML users too. >> You just got to
remember to do it. >> I am a big XAML fan. I'm similar to you James. I think it did just
click when I started. Until you start to deal with these obscure things like trying
to refer to a static constant. I don't know if you can read
that particularly well, but you see the AutomationId there, how lengthy that is. I always have to look up the
syntax in XAML to remember how to refer to a
constant like that. Whereas obviously if you look at
the C# equivalent down below, it's much more readable. >> That makes some sense
because in the XAML, you just don't have access to static variables and what
you're doing here is you have to actually like add a bunch of stuff to make that compilation
or that interpreting part, actually figure out where that
stuff is. It is pretty verbose. >> Yeah. Another good
example is converters. If you've ever wanted to tweak the binding result that comes
back just a little bit, XAML requires a lot of ceremony. We have to create a whole new class that implements I value converter. Then everything's objects,
nothing's type safe, which is a bummer, so we have to do casting and
hope it doesn't crash our app. At the end of the day, we finally get we can do it with our bindings so is enabled binding here that uses our converter that
we just initialized. In C# with our library, it's so much easier. You can do it just in
line with the binding. We have a couple of parameters
where you can put in a function, so we have the convert function
here that will just convert the binding to the length
of text of an entry. If that length is not zero, then we'll convert that to the bool true and
likewise to convert back. If it is true we'll
convert it to either one or zero, and we
just do it in line. We just put in our
little C# function here, we don't have to
make a do interface, we don't have to worry about
any of the other stuff so converters become a lot simpler. >> That's pretty cool.
I like that a lot. >> I want one big selling point, I think we're quite keen on. It potentially reduces
the barrier to entry because obviously if you're
coming in to learn .NET MAUI, you're going to have to learn C# irrespective of whether you're
going to use XAML or not. By removing the XAML element, that's one extra thing that
you don't have to consider. If you think about
all of the platform specific APIs that you're going
to have to deal with potentially, MVVM would be a practice. I guess MAUI offers the potential to break out of that mechanism
and use a different architecture, and then other things like
asynchronous programming. There are a lot of concepts
people are going to have to comprehend or learn on their
journey to building an application, so if we can remove
any parts of that. >> Makes sense. I always
want to make things easier and not more
complex, all right? >> Yes, exactly. As part of the work that we've
been doing on the toolkit, we've been trying to heavily
document what's available, so in terms of the markup, we're showing off what can be done guiding users
through how to get started. We'll show how to
consume the package for our NuGet and then how we can go in and actually start to
use some examples. Typically wherever we've got pages, we try to show how you could do it in the old way without
using our package. If you want to set up a binding
to a text property on an entry, you have to create the entry then
we'd have to go set binding, that which becomes quite verbose. >> Very cool. Then below
it is like the new things, like these really are
extension methods right there. They are extensions to
what it is that really improve the C# markup
ability basically. >> Yeah, precisely. Like I said, we've removed a
little bit of that so we're saying we're going
to bind our entry to a text property and the property
that we're going to bind it to. >> Very cool. >> We give a brief
overview and then you can click around and
you can start to see that this quite more complex things that can be done and
you can break it down. Here's providing a converter, if we did the old way as
per Brandon's example, mentioning how you
could do it with XAML. If you've got something
that you want to reuse across multiple controls, then there is some potentially value in creating that converter still. But then you've got the in line that Brandon showed off where you
don't have to create that. >> Oh, cool. That's really nice. I like that there's
flexibility there. If you did have a bunch of
converters that you were using in XAML and you wanted to
do a little bit of both, you can pick and choose basically, like what works for
you in your code. >> Exactly, yeah, because I think primarily I've been XAML base, but I think there are
times when I do create C#, so I do make use of this
package now because it's certainly reduced the amount
of code that you have to write. As another slight part
of it, as I mentioned, we show off everything
that's available within the C# package itself. But wherever we're trying to
write examples in terms of the toolkit that you spoke about with the rest of
the team yesterday, what we do, we show a piece of
functionality that we offer, how we can use it within XAML, how you can then use it within C#, and you can see that becomes
really quite lengthy. Then we will already provide
you a markup and you can start to see how then it really
starts to simplify things. >> That's very nice. Yeah, that's very cool. It's nice because, like, you're
already using the tool kit, and if you're going to
create something C#, why not use this C# markup tool, it's like a nice
self-promotion in a way. Like, hey, just so you know, this thing exists right over
here and it's like way shorter. >> Yes. XAML is a big part of the Xamarin
days and certainly part of MAUI, so it's trying to bring attention to the package to show that there are different
ways of doing it. You don't have to
be stuck in XAML or even you can mix and match
between the two, as we said. >> Very cool. >> Thanks. The only other thing is, we're working hard to get
these docks up and running, but feedback is definitely valuable. This is because we're trying to make it as user
friendly as possible in terms of functionality and
then also the docs as well. If there is any feedback, we're more than willing or
more than happy to receive it. >> Are the docs open source as well? Like if someone found a bug and
they make changes to it as well. >> They are, yes. In fact we had someone
the other day do the same thing. They
reported the bug. At the top of the page there
was send feedback button, and I believe it will take you to be able to create
feedback for that issue. >> Cool. Nice. >> Yes, we have a Microsoft
Docs repository up on GitHub, which houses ours and some
of the other ones like the MVVM and the .NET toolkits
and the Windows toolkits. This is all open source. People can contribute and contributions
are definitely welcome. >> Very cool. >> Yeah, that's awesome. >> Fix our typos. >> Yeah. Basically,
all Brandon says. That's the best type of poll
request, to be honest with you. I think a lot of people, sometimes it's hard to
get into open source. I don't need to create a whole
new feature. Any new thing? No. Just get in the docs, update some codes, some
comments, things like that. Those things are super helpful. I know for me as a library
creator it saves me because it makes other developers' lives better because they can read the
docs instead of all my typos. Cool. Do you all want
to see it in action? What's the next steps
here? We've got some docs. >> Absolutely. Yeah. >> I had to set up the Visual
Studio Code just because I like how it has a split view. But it's .NET MAUI. You can use Visual Studio NPC, you can use Visual Studio for Mac. But if we're looking
at code side by side, what we have here today, this is just the hello world app. Like when you create
a .NET new MAUI app, this is what it gives you. You get this all hello
world with a little click me counter, pretty standard. Here on the right, is the XAML that we get
for free in the template. What we did today to
show that side by side is we just took that
same XAML and C#-ified it. >> Got it. >> We have the same code from a
different class here on the left. When we compare the two, I mean, obviously they're different. We have C# versus XAML,
different languages. We have to specify the class here and now we're in the
constructor for main page, whereas XAML, we do that up here. But once we had some of that, we can start to see
the similarities. Right away you'll see a scroll view and inside of that scroll view is a vertical stack layout where
we have a spacing of 25, a padding of 30 and so far none of this is
from our markup library. The good stuff comes in here with
these fluent extension methods. Here, when we add the children
to this vertical stack layout, now we can start taking advantage of these extension methods that make it really easy to initialize
our components in C#. For example, this label has
text that says hello world. It's got a font size of 32
recentering things horizontally. In C# we do the same thing. We can say, ".text, hello world; .font of size 32 center horizontal," and that both
boils down to the same code. Really the only difference here
is the semantic properties, we're working on adding that. That will be brought in soon depending on when
you're watching this video. Maybe it already is brought in. But for the most part, everything you can do in XAML can also be done in C#,
and that's our goal. If you find a property that can't be initialized or initialize easily in C# with a nice float
extension method, let us know. We're happy to add it in. We're trying to obviously hit off or knock off all the
most common ones first. But for the most part. We got everything taken care of
for this hello world sample app. We take the liberty of turning
it into some MVVM stuff too. We've got some bindings
where we bind to the labels text property and even
do a little conversion here. >> Cool. >> Where we take the cout, which is an int in our view model, and then turn that
into the string for the label text. Lots of good stuff. This font method has a couple
parameters like bold or italic. Let's see if will IntelliSense
come up? Not really. But that's where you can
set your font size or font families, bold or italic. Like Sean showed off in the
docs we have this size. The image down here has a
width request, height request. Well, we figured why type out all
those letters we'll just call it size and you can set your width size to 250 and your height size to 310. It makes things really easy to do. Selfishly, I like it because
it's also easy to read. It flows really nicely. Everything is top to bottom, left to right, similar to how
we're used to it in XAML as well. >> Well, I think one thing
that's nice here is well, the template, the file
new is relatively simple. You showed the app is just like
clicking buttons and some labels. I think the thing that impresses
me and I could imagine a more complex user interface is or some of those nice helper
methods that you just described. Actually, the fonts or
you're doing size and bold or you're actually setting multiple properties on
a single line of code. Same thing with the size. I think also when you talk about
readability, it's fascinating. Because center horizontal, that's actually not really what
those words are in the property. But it's also in
what is assigned to, the horizontal options,
which is center. Which horizontal options, people may not even understand what that means, but they may understand
center horizontally. Then I would say on top of that, I think one thing that
you pointed out early is that it's different, but it's not completely foreign. If you were going back
and forth between XAML or you're coming from XAML
and you would prefer C#, for example, you're
going to naturally learn all those things
in the C# markup. Yeah. Also, like Shaun mentioned, you can do both. These aren't mutually exclusive. Even in the sample app for the
.NET MAUI community toolkit, we have some content
pages are done in C# with this markup and some
content pages are done in XAML. It's not all or one of the other. It might be easier sometimes
to make a page in C#. One of the reasons we do it
is so that we can inherit that page and leverage it
across multiple pages, which we can use C# for that. Whereas XAML makes that
a little bit more tough. Try them out. You can use both. You can use one. You can
use the other. That's okay. These are all just
equally great options for our .NET MAUI developers. >> Well, I think you said it right. It's about choices and
about productivity. If you're a developer that
loves XAML, go use XAML. If you're a developer that loves C#, use C# and obviously, the markup extensions
to be more productive. It's really cool to see side
by side and to walk through some of the perks and benefits of why you might
want to go this route. >> That's right.
Awesome. Well, thanks, Brandon and Shaun for coming on. What I'll do, of course, is put links everywhere in
the show notes below. If you're on YouTube or on
the Docs page over there to not only to Brandon
and Sean on Twitter, to the GitHub repos, the code samples,
and everything else. Thanks again, guys, for coming
on. I really appreciate it. >> Thanks, James. >> Thank you very
much for having us. >> Awesome and thanks
everyone for tuning in to this week's On .NET, I really appreciate it. You've made it this
far in the video. If you're ever on YouTube,
you can go ahead, jam on that like button. Hit that subscribe button and ring that notification bell
to become part of the notification squad over
here and you get notified every single time we put our brand new
video right here on YouTube. Well, that's going to do it for this week's On .NET so until next time, I'm James Montemagno,
and thanks for watching. [MUSIC]
