In the last couple parts of the series we were talking about different aspects of XAML. We know enough to start our project.
Project Overview
At the beginning of the series I told you that I had written a book in which I demonstrated how to build this project using a different programming language (Python) and a different technology (Kivy). As I’m building the .NET MAUI version as we move on, I don’t have the final app to show you at this moment, but we’re trying to re-create the same app, so let me use the screenshots from the other project here. Some details may differ in the final version, but we’re aiming at something roughly similar. So, here are the screenshots of the InstructionsPage that displays the other pages with explanations. The app is going to contain three pages that need access to data (SettingsPage, RacePage and GameOverPage and two pages that don’t (InstructionsPage and SplashScreenPage).
So, when the game starts you will see a splash screen, which we are going to implement a bit later because we don’t want to see it each time we launch the app during development. Then the SettingsPage will be displayed. Here you can see it along with the instructions. The annotations in red are not part of the page – these are the instructions. So, here you can see what you are expected to do. Just read through the instructions.
When you hit the Ready button, you will navigate to the RacePage, which is the main page of the app. You will spend most of your time on this page unless you lose right away. Here’s the RacePage with the instructions:
As you can see, there is the Bets panel in the bottom part of the page. We’re going to implement it as a reusable content view that will be replaced by the Results content view after each race. When this happens, the RacePage will look like this:
So, now you can see the results of the race. You can also see the name and the image of the slug that has won nest to the racetrack.
When the game is over, you will see the GameOverPage. It should look something like this:
As you can see, it’s a simple racing and betting game. The version that I created while writing the book was meant only for desktop, so I don’t have any screenshots for you of the Android version yet. We’ll be creating the mobile version as we go. I’m still not completely sure how exactly this will look. Anyway, how is the app going to be implemented?
Implementation
Now that we know what we’re going to create, we’ll start implementing the application step by step.
In the next part of the series we will create the pages for our app. We’ll also use a couple content views in the pages, which you can think of as custom reusable components. I already mentioned the Bets and Results panels in the RacePage, but there will be more.
Next, we will implement the differences in the pages for mobile devices. The controls must be arranged in a different way on desktop and mobile devices and there is a way in .NET MAUI to handle it.
After that, we’ll be talking about markup extensions and we’ll implement some in the project. We’ll see how to share resources.
Our application needs data. There’s the concept of data binding in .NET MAUI and this is going to be our next topic.
Next, we’ll see how to handle collections in .NET MAUI, and in particular, how to use the CollectionView control with data binding.
Sometimes it’s not that easy to implement data binding, for example because the properties are of completely different types. Fortunately, value converters come to the rescue here. We’re going to discuss them in detail and implement some in our app.
After we cover all the topics above, we’ll polish up our app by adding some styles and graphical assets to it. We’ll also see how to draw, handle themes and visual states.
With all that in place, we’ll start implementing the app logic. We could implement the app using pages and code-behind files like we’ve been doing so far. But then the logic would all be in the code-behind files, which would make it tightly coupled with the pages. To decouple logic from representation, we’re going to implement the MVVM (Model-View-ViewModel) pattern. This is a very popular pattern in frameworks that use XAML. We’ll be talking about this pattern in more detail later on in the series and we will be implementing it step by step.
After we discuss the MVVM pattern, we’ll create an appropriate folder hierarchy in order to implement it. As you already know how to create views and layouts in XAML, we’ll start by implementing the views (actually, we’ll have implemented them by that time). Now, in the previous sentence I used the term view twice, each time with a different meaning. The first time I meant views like labels, buttons or sliders. The second time I meant views as part of the MVVM pattern where the first V stands for View. If there are any doubts as to what is meant in the future, I’ll use the term control to refer to labels, switches or entries.
After that we’ll create the models and view models and put it all together to work.
So, what are we waiting for? Let’s get started.