Views in Swift & Kotlin
Life in the outer layer of Clean MVVM is platform-specific
At the outer layer of our Clean MVVM hierarchy are Views, including Activity and UIViewController, and these are represented by the blue 🔵 parts of our Clean architecture.
We can think of the view as the class that defines what to draw on the screen and how to draw it, but not when or why. The “when” is decided by the view model, and the “why” by the logic. Below is a summary of different types in this layer:
View classes should have only platform-specific code, related to what to draw — conditional business logic does not belong here. View classes should only interact with the ViewModel, not logic or repository classes. View classes can also be expected to implement navigation if we need to start a new UIViewController / Activity per user interactions.
🚫 Delegates 🚫 Blocks; 👍 Rx
As we said in our opening, avoid using delegates or closures when interacting with your ViewModel from your View. Here is an example of how to observe state changes in your View layer using ReactiveSwift:
Here is how you might observe event changes:
Next up
Finally, we discuss thoughts on effective cross-platform testing in Swift & Kotlin.
More in the series
- Clean MVVM Intro
- ViewModels in Swift & Kotlin
- Logic Classes in Swift & Kotlin
- Repositories and Domain Models in Swift & Kotlin
- API classes in Swift & Kotlin
- Views in Swift & Kotlin ← you are here
- Testing MVVM in Swift & Kotlin
- Testing Asynchronicity in Swift & Kotlin
- Clean MVVM Summary
Other series you might like
Clean API Architecture (2021)
Classes, execution patterns, and abstractions when building a modern API endpoint.
Android Activity Lifecycle considered harmful (2021)
Android process death, unexplainable NullPointerExceptions, and the MVVM lifecycle you need right now
About the author
Eric Silverberg is the CEO and founder of Perry Street Software, publisher of two of the world’s largest LGBTQ+ dating apps on iOS and Android.
