Life in the outer layer of Clean MVVM is platform-specific
At the outer layer of our Clean MVVM hierarchy are Views, including
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
Activity per user interactions. …
In our series on Clean MVVM, we have shared real-life lessons shipping a major mobile client on multiple platforms for more than a decade. Clean MVVM is an architectural approach for building consistent apps in Swift and Kotlin, to maximize architectural and code design re-use. At its best, Clean MVVM enables you to copy-and-paste Swift into Kotlin, or Kotlin into Swift, and just twiddle the syntax.
Below are the key points across all articles in this series, helpfully summarized:
API classes initiate network calls to one remote service, specific to the Repository you are implementing. Though it may be tempting for your API class to itself interact with the network, don’t do it — instead, inject an HTTP client (such as Retrofit on Android) into your API class that itself provides general-purpose network access, including adding necessary authorization parameters and headers.
Each feature area is broken up into a specific interface that defines the necessary GET/POST/PUT/DELETE operations for that feature. API classes are always injected into Repositories. …
What comes after an API response?
APIs are like the engines of apps — every app has them, and they provide the fuel that makes the app work. But what happens after an API call completes? How is the data managed, munged, and manipulated before it is (ultimately) rendered in a View on iOS or Android?
Perry Street Software has been publishing apps since 2010, and in this series of blog posts, we introduce the Clean MVVM architecture for consistent cross-platform code in Swift and Kotlin.
The center of our abstraction — Repositories and Domain Models — is the part that should also be most closely aligned from a code perspective. In our Clean architecture diagram, Repository and Domain Model classes are represented by yellow 🟡 . …
Explore the ecosystem of classes that power well-designed ViewModels
In our Clean MVVM architecture, we see that there is in fact a larger ecosystem of classes that all enable the ViewModel to do its work. The first and most overlooked of these enabling classes are called Logic classes.
Logic classes are stateless wrapper classes that apply conditional logic based on data retrieved from repositories.
Logic classes are represented by the red 🔴 parts of the diagram in our Clean architecture. A ViewModel updates its state or emits an event based on these decisions. Logic classes do not know anything about the View or the ViewModel. …
In the early days of mobile, client testing primarily revolved around UI testing. Apple shipped a technology called UIAutomation, which it ended up deprecating completely in 2016 with the release of Xcode 8. The Android testing samples repository did not get created until 2014.
Because of the top-down approach required by UI testing, tests will break if you significantly redesign your UI. Furthermore, UI testing does not by itself handle the various logical states that arise from dependent systems, such as network failure responses. Confirming that a button changes color when tapped is frequently less valuable than confirming the app responds correctly when receiving a 500 response from a server. …
Everyone’s heard of a ViewModel, but what do they actually do?
A view model represents the data that you want to display on your view/page, whether it be used for static text or for input values (like textboxes and dropdown lists) that can be added to the database (or edited). It is something different than your domain model. It is a model for the view.
Mobile development has aspired toward “write once, run anywhere” since the earliest days of Java. When iPhone first launched, we saw companies like Facebook try to implement a generalized, WebView-based approach, before abandoning that effort and going native. Only a few years later in 2015, Facebook would try again with React Native, adopted with great fanfare by companies like Airbnb only to be undone a few years later.