My #MAUI Day talk - part 3
This is part 3 in a series recapping my talk from MAUI Day (in London). This will make much more sense if you read part 1 and part 2 first.
The tools we get "out of the box" for working with XAML in MAUI basically come down to creating a sparsely populated application and the need to type everything by hand (with a bit of intellisense).
I've created some tools (and experiments) that make getting from nothing to a basic project architecture much easier, and from an empty file to useful appropriate XAML content much faster.
The MAUI App Accelerator is a Visual Studio extension that enables the creation of MAUI apps through a wizard-style interface. (Remember I said I like GUIs.)
It allows you to specify :
It then produces an application with all these options, all correctly configured and with dependencies and initialization already done.
It doesn't sound like the most revolutionary thing in the world, but it can definitely save minutes and maybe even hours to go from nothing to a complex working application full of correctly configured and useful dependencies.
That's great for new apps, but what about extending existing apps?
Well, version 2.0 is "coming very soon", and among numerous other improvements is the ability to use the same wizard to add new pages and features. Of course, it does this with the same level of integration into the existing app, so it automatically registers dependencies, adds resources, and correctly configures and initializes all it adds.
So, that's great, we can now build the basic structure of our application much faster, but what about getting the XAML we want inside the pages of the app?
I have two ideas to show on that subject.
First is the Pro XAML Toolbox.
This is a variation on the default Toolbox, but it adds more useful and appropriate content to the page. Many options are configurable, and items can be dragged where desired or double-clicked to be added where the cursor is.
While that allows the creation of XAML much faster than typing by hand, I still think there is a faster way.
For most data types in a ViewModel, it's possible to make a reasonable assumption about the UI controls that can be used to display and allow interaction with them.
When those assumptions are codified (in a configurable way--of course), then it's possible to generate the XAML corresponding to a particular ViewModel file.
My preferred way of implementing this is to simply drag the ViewModel file onto the View and have the XAML code be automagically added.
When doing this, the file is analysed, and appropriate elements are created depending on the types, their names and if they can be changed.
See below that:
It's also possible to open the ViewModel, select some properties and choose "Copy as XAML" which you can paste wherever you want.
As with the Pro XAML Toolbox, this isn't going to always give you exactly what you need, but it is much quicker and easier to make small modifications to something that is almost right than it is to type the entire thing from scratch.
This isn't all just me showing off. I'd much rather that someone else had created the above (and shown how XAML can be made more maintainable.)
The above is to show that other things are possible.
Given that this is possible, why has no one else done anything like this before? (There are a few command-line-based template options available, but nothing else with a GUI or as much flexibility. And nothing beyond that.)
Ok, we've seen that while everyone agrees that most XAML is bad, it doesn't have to be that way. I've also shown that there are ways of writing XAML to make it much easier and more pleasurable to work with, and that it's possible to create tools to make working with XAML files easier.
Is this as far as we can go?
Is this as good as it can get?
Microsoft doesn't seem interested or motivated to consider any big changes.
No one else is doing anything in this area.
That's not going to stop me.
In part 4, I share an idea I've had about a possible future evolution in working with XAML.