Learn Swift and iOS Development
Master iOS development through in-depth tutorials and comprehensive courses on Swift, SwiftUI, UIKit, Core Data, and more.
Master iOS development through in-depth tutorials and comprehensive courses on Swift, SwiftUI, UIKit, Core Data, and more.
Discover the newest tutorials on Swift and iOS development
Discover the newest tutorials on Swift and iOS development
Showing 181 to 192 of 716 posts
2:01
Before we refactor the AddLocationViewModel class, I would like to take a few minutes to explain my motivation for using RxSwift and RxCocoa. There are several reasons.
5:01
It is time to refactor the AddLocationViewController class. We start by removing any references to the Core Location framework, the import statement at the top, the geocoder property, the geocode(addressString:) method, and the processResponse(withPlacemarks:error:) method.
8:21
Before we use RxSwift and Combine to improve the current implementation of the Model-View-ViewModel pattern, I want to show you how you can roll your own solution using closures. I like to refer to this solution as DIY bindings or Do It Yourself bindings.
3:08
How do we bind the various components of the Model-View-ViewModel pattern together? That is the question we focus on in the next few episodes. It is a problem most developers new to the MVVM pattern struggle with. It isn't difficult to use the Model-View-ViewModel pattern to push data from the controller layer to the view layer. We already covered that extensively in this series. What do we need to change to automatically update the user interface if the user interacts with the application or the environment changes?
5:28
You should now have a good understanding of what the Model-View-ViewModel pattern is and how it can be used to cure some of the problems the Model-View-Controller pattern suffers from. We can do better, though. Data is currently flowing in one direction. The view controller asks its view model for data and populates the view it manages. This is fine and many projects can greatly benefit from this lightweight implementation of the Model-View-ViewModel pattern.
4:07
Writing units tests for the view models of the WeekViewController class is just as easy as writing unit tests for the DayViewModel struct. We start with the unit tests for the WeekViewModel struct.
8:17
Unit testing the DayViewModel struct isn't very different from unit testing the view models of the SettingsViewController class. The only tricky aspect is creating a DayViewModel object in a unit test.
7:59
In this episode, we unit test the view models of the settings view controller. We start with the SettingsTimeViewModel struct. Create a new file in the Test Cases group and select the Unit Test Case Class template.
2:47
Because we moved a fair bit of logic from the view controllers of the project to the view models, we gained an important advantage, improved testability. As I mentioned earlier in this series, unit testing view controllers is known to be difficult. View models, however, are easy to test and that is the focus of the next few episodes.
6:26
Let's apply what we learned in the previous episodes to the week view controller. The week view controller currently configures the cells of its table view. That is something we want to change. The refactoring of the week view controller involves four steps. We create a view model for each table view cell. The WeekViewModel struct generates a view model for each table view cell. We define a protocol to which the view models for the table view cells conform. The WeatherDayTableViewCell class has the ability to configure itself using a view model.
4:06
The settings view controller manually configures each table view cell, using a view model. Why can't the table view cell configure itself? Can we make it autoconfigurable?
4:05
In the previous episode, I mentioned that we are repeating ourselves in the tableView(_:cellForRowAt:) method of the SettingsViewController class. We can resolve this problem with protocol-oriented programming.