Mastering MVVM with SwiftUI
Views, Models, and View Models
|1||Views, Models, and View Models 03:37|
|2||The Problem 04:49|
|3||A Solution 07:05|
|4||Fixing Code Smells 07:51|
|5||Hiding the Model Layer 06:12|
|6||Meet Thunderstorm 05:50|
|7||Setting Up the Project 06:33|
|8||Populating the Locations View 10:17|
|9||Displaying Weather Data 08:17|
|10||Populating the Location View 08:22|
|11||Displaying Weather Data in the Location View 08:37|
If you have been reading or watching Cocoacasts for some time, then you know that the Model-View-ViewModel pattern is one of my preferred patterns for architecting applications. I have been using MVVM for several years in various projects and it continues to prove its value in every project I work on.
A question I hear often is how to apply the Model-View-ViewModel pattern in a project that uses SwiftUI for its user interface. SwiftUI and MVVM are a superb combination. Even Apple has started using the pattern in some of their examples. They don't name the pattern by name, though. They refer to view models as UI or user interface models. I prefer the term view model because that is what I am used to and it is an object that drives the view hence the name view model.
Apple emphasizes that views need to be lightweight and that is in alignment with the role views play in the Model-View-ViewModel pattern. A view is dumb and lightweight. Its sole responsibilities are presenting data to the user and responding to user interaction. Other tasks are delegated to the view's view model.
By keeping the views of your project lightweight and decoupling business logic from your views, your project automatically becomes easier to unit test. A view model is unaware of the view it drives and that promotes testability. View models are easier to unit test than you might think.
View models also have other benefits. Previewing the user interface of a view can be flaky, especially if the data the view presents needs to be fetched from a remote API. You learn in this series how MVVM and protocol-oriented-programming solve issues like this. Like unit tests, previews shouldn't be affected by external factors, such as the unpredictability of the network. It makes development slow and frustrating.
What You Will Learn
In this series, we build an application from the ground up so you you understand how the pieces of the puzzle fit together. It isn't a complex puzzle, but there are pitfalls and subtle details you need to be aware of.
The good news is that the Model-View-ViewModel pattern has a gentle learning curve. It isn't difficult to pick up and you can gradually adopt it in projects that use a different architectural pattern. Because this series shows you how to build an application from scratch, we cover more than just the MVVM pattern, including unit testing, reactive programming, and protocol-oriented-programming.
UIKit or SwiftUI
If you are interested in learning about the Model-View-ViewModel pattern, but you aren't ready to adopt SwiftUI, then I suggest taking a look at Mastering MVVM with Swift. In Mastering MVVM with Swift, we refactor a UIKit application that uses the Model-View-Controller pattern. The concepts are similar. The key differences are the absence of view controllers in a SwiftUI application and the technology used to build the user interface.
Build with Me
If you are new to the Model-View-ViewModel pattern, then I encourage you to follow along with me. We build an application from scratch using Xcode 14 and Swift 5.7. The application is fairly basic so you should be able to follow along even if you don't have much experience using SwiftUI.