A brief review of Model-View-ViewModel coding patterns with UWP development.
- [Instructor] If you have built a Windows app in the past, you are likely familiar with a software architectural pattern known as MVVM. Meaning Model-View-ViewModel. There is a lot of content out there about MVVM, and many developers have their own opinions on some of the nuances of MVVM. In this opinion, I will provide a brief refresher on MVVM, and provide some tips that have really helped me. MVVM is a good practice because it makes your code scalable and maintainable. More specifically, with your views, models, and ViewModels all separated, it is easy to change things around without impacting the entirety of your app.
For example, if you started using a different service provider for your backend, you can change the ViewModels to access the data, but the views will be fine. With that in mind, let's do a quick overview of MVVM. First, the model. The model represents the data that we are actually working with. In our example, a project is one of our models. Many times, the model is just a list of properties, and can referred to as POCOs, or plain old CLR objects. This means the models do not use interfaces, or methods that are used in the framework in which they're being consumed.
Next, the view. The view is what actually displays the information. For UWP development, this is where you will write XAML code. The view will be bound to the ViewModel, and will integrate with the exposed ViewModel properties. Typically, there's not much business logic in the view, if any. Finally, the ViewModel. Views and ViewModels have a one to one relationship. For each view, you typically have a ViewModel. The ViewModel can expose methods, commands, and other properties that will provide the view with all of the necessary functionality. When constructing the ViewModel, I find it always helps to consider what you want the user of your application to be able to do on your view.
Each user action usually relates to a method or set of methods in the ViewModel. With that in mind, here are two tips that have helped me with MVVM. Keep it simple for your use case, and design around your app. Think about the needs of your app, and make sure you design around that. In the app we are building, the only UI updates that we're going to make, is the result of changing an observable collection, by either adding or moving an object from the collection. We're not going to modify any individual properties of the objects in the collection. Since by definition, the observable collection is observable by UI, we won't need to implement the INotifyPropertyChanged interface.
If you wanted to change individual properties of the objects, you would need to implement that interface. Next, don't be afraid to write a little bit of code behind in your views. Especially when you're prototyping, or building demo applications. More specifically, handling the UI event handlers in your code behind, is usually okay, and you can always bring it out later. You'll see this in practice in shortly, but it is okay to call a ViewModel method from a button click event handler in the code behind. Rather than binding to a specific command in the ViewModel. Note, one caveat to this advice, is if you want to go cross-platform with your app, and share all of the ViewModel code across each platform.
In that case, you'll likely want to bind your UI directly to ViewModel commands, rather than in the view code behind. With that said, I encourage you to do some research on MVVM, if you are not already comfortable with the practice. There are tons of resources available regarding MVVM. Now, we're going to build an app.
- Working with .NET for UWP app development
- Establishing application architecture
- Configuring Azure services
- Configuring the mobile app service backend
- Testing and publishing the service backend
- Using Facebook authentication
- Using XAML
- Client server abstraction API
- Using the UWP community toolkit
- Styling app views
- Creating adaptive views
- Testing an app for multiple user accounts
- Publishing to the Windows Store
- Sideloading app packages