MVVM

Question 1

mvvm involves three layers:

Answer 1

The model layer contains data access objects and validation logic. It knows how to read and write data, and it notifies the view model when data changes.

The view model layer contains the state of the view and has methods to handle user interaction. It calls methods on the model layer to read and write data, and it notifies the view when the model’s data changes.

The view layer styles and displays on-screen elements. It doesn’t contain business or validation logic. Instead, it binds its visual elements to properties on the view model. It also receives user inputs and interaction, and it calls methods on the view model in response.

Question 2

How communication between layers looks like in mvvm?

Answer 2

“The view layer and model layer only communicate with the view model layer”

Question 3

Model layer in mvvm

Answer 3

The model layer is responsible for all create, read, update and delete (CRUD) operations.

Question 4

push-and-pull designs in model layer in mvvm

Answer 4

Push-and-pull designs require consumers to ask for data and wait for the response, which is the “pull” part. Consumers can also update model data and tell the model layer to send it, which is the “push” part.

Question 5

and observe-and-push designs in model layer in mvvm

Answer 5

Observe-and-push designs require consumers to “observe” the model layer, instead of asking for data directly. Like push-and-pull designs, consumers can also update model data and tell the model layer to “push” it.”

Question 6

Repository pattern diagram

Answer 6

“Repositories contain data access objects that can call out to a server or read from disk.”

The repository pattern provides a façade for networking, persistence and in-memory caching. This façade creates, reads, updates and deletes data on disk and in the cloud. The repository doesn’t expose to consumers how it retrieves or stores the data.

Question 7

Repository structure and types of layers of data access through repository

Answer 7

Under the hood, the repository has multiple layers of data access. Each implementation of a repository may implement all or only one of these layers:

cloud-remote API
persistence-store layer
in-memory-cache layer

Question 8

View layer

Answer 8

A view is a user interface for a screen. In MVVM, the view layer reacts to state changes through bindings to view model properties. It also notifies the view model of user interaction, like button taps or text input updates.

The purpose of the view is to render the screen. It knows how to layout and style the user interface elements, but doesn’t know anything about business logic.

In MVVM, you use one-way data binding to bind the UI elements from the view to the view model. This means the view model is the single source of truth. The view doesn’t update until the view model changes its state.

The view layer contains a hierarchy of views. Each parent view knows about its children and has access to their properties.

Question 9

View model layer purpose

Answer 9

The purpose of the view model is to decouple the view controller from the view.

Question 10

Idea of “pure mapping” in view model layers

Answer 10

View models take input signals and produce output signals, providing a clear boundary between view models and views.

Question 11

Structure of view model

Answer 11

view state
task methods
dependencies

Question 12

View state part of view model

Answer 12

View State is stored in the view model. The state is made up of public observable properties. Using RxCocoa, the user interface elements bind themselves to the observables when the view model is created.

Question 13

task method part of view model

Answer 13

Task Methods perform tasks in response to user interactions. The methods do some work, such as calling a sign-in API, and then updating the view model’s state. The view knows if the state changes because the observables signal new data. You usually mark task methods as @objc methods, because you have to target-action pair on a UI Control.

Question 14

Dependencies part of view model

Answer 14

Dependencies are passed to the view model through initializer injection. Task methods rely on the dependencies to communicate with other subsystems in the app, such as a REST API or persistent store. View models know how to use the dependencies, but have no knowledge of the underlying implementations.

Question 15

Creating the view in MVVM

Answer 15

“The view knows how to style and layout its subviews, as well as hook up user interface elements to the view model observables

“In Koober, view controllers create the view and the view model inside loadView(). The view controller creates the view model first and passes it to the view. Since Koober creates view layouts in code, views can have a custom initializer.”

“If you use Interface Builder to create view controllers and views, view controllers would contain implicitly unwrapped view model variables. Dependency containers would inject view models into view controllers using property injection instead of initializer injection. View controllers would pass the view model to the View inside viewDidLoad() or awakeFromNib().

Question 16

Container views in MVVM

Answer 16

“Each screen in Koober has a container view — a top-level view that contains other child views. The container view’s purpose is to build a complex screen out of modular views. Instead of throwing all the user interface into one massive view, keep your views small, focused and reusable.
The “view” in container view refers to a UIViewController and its UIView.”

Question 17

Structuring container views

Answer 17

A dependency container initializes a container view with its child views. A container view adds and displays child views in its view hierarchy.

Child views limit the responsibility of the top-level container view. The number of child views needed depends on the screen’s complexity. Each child view is reusable and performs all its work independently.

Question 18

“Communicating amongst view models

Answer 18

When view models signal out, they communicate what occurred rather than what to do. The application decides what to do. This provides flexibility — you can change how the app responds without changing the view model.

Question 19

Collaborating view models

Answer 19

“Normally state changes in a view model update a view. Sometimes, those state changes affect the entire app. View models don’t know how to post app-wide notifications; they take inputs and produce outputs. One way for view models to communicate with the app is to call into another view model, forming a graph of view models.

Question 20

View models have three ways to collaborate with each other:

Answer 20

Closures: For signaling out, view models take a closure as an initializer argument. The view model calls the closure when an event occurs.

Protocols: Each output signal is modeled with a single method protocol. Other view models that want to respond to outgoing signals must conform to the protocol. You should use a single protocol per signal; otherwise, you force the conformer to place all response logic into a single object.

Observables: For outgoing signals, a view model exposes a mutable observable subject that other view models can modify by pushing new state onNext(_:).

Question 21

Navigating in mvvm

Answer 21

Model-driven navigation
System-driven navigation
Combination

Question 22

Model-driven navigation in mvvm

Answer 22

In model-driven navigation, view models contain a view enum describing all possible navigation states. The system observes this and navigates to the next screen when the value changes.

Container views and container view models handle navigation for their children. Children view models signal out to the container view model that handles navigation at the top level.

Child views can signal out in two ways:

Collaborating view models signal to each other when a view enum value changes. Child view models get injected with a higher level view model and call task methods when navigation should occur.

Shared observable view state holds a mutable Observable subject property with the current view enum value. A dependency container injects child view models with the Observable subject. Any child view model can push a new view enum value. The container view model observes the value and navigates to the next screen when it changes.

Question 23

System-driven navigation

Answer 23

System-driven navigation is any navigation managed by the system. For example, gestures that trigger scroll view page navigation, or tapping a Back button in a navigation stack, automatically navigate the user to the previous screen.

“In pure MVVM, you override all these gestures, and the view model handles the user interaction. For most apps, this is overkill. A better option is to work with the system and leverage what’s already designed for you by Apple. As soon as an MVVM implementation causes friction with the built-in system paradigms, consider using an MVVM implementation that combines model-driven navigation and system-driven navigation

Question 24

Combination navigation in mvvm

Answer 24

You can use built-in, system-driven navigation to your advantage, while still implementing an MVVM architecture. For example, you can use model-driven navigation to move a navigation stack forwards and use system-driven navigation to move backwards.

Koober’s onboarding flow uses a combination of model-driven and system-driven navigation.

The onboarding view model switches between three states: welcome, sign in, and sign up. Tapping the Sign In button on the welcome screen changes the view model state to “sign in.” The onboarding view reacts to the change, and it pushes the sign-in screen onto the navigation stack. Tapping the Back button on the sign-in screen’s navigation bar uses system-driven navigation to pop the screen from the stack

Question 25

Managing state on navigation in mvvm

Answer 25

Creating new views on navigation

Reusing views on navigation

Question 26

Creating new views on navigation in mvvm

Answer 26

“Creating a new view each time a view is presented is easier to manage. The view and view model aren’t held in memory when the view is offscreen.
The system deallocates views each time the application dismisses them. When the application creates them again, the view model populates the view with the correct initial state. With this option, you don’t need to worry about state changes when the view is offscreen.”

Picture:
“The main-view-custom-container handles the transition between the finding-your-location screen and the map screen. It creates the finding-your-location and the map screens right before any transitions. After presenting the map, it destroys and deallocates the finding-your-location screen.”

Question 27

Reusing views on navigation

Answer 27

Reusing views makes sense when they need to preserve their state. System containers, like tab bars and navigation controllers, reuse views on navigation.
Tab bars hold onto a list of view controllers that live in memory. Navigation controllers reuse views when moving backwards in the stack.

Question 28

Pros of MVVM

Answer 28

1. View model logic is easy to test independently from the user interface code. View models contain zero UI — only business and validation logic.
2. View and model are completely decoupled from each other. View model talks to the view and model separately.
3. MVVM helps parallelize developer workflow. One team member can build a view while another team member builds the view model and model. Parallelizing tasks gives your team’s productivity a nice boost.
4. While not inherently modular, MVVM does not get in the way of designing a modular structure. You can build out modular UI components using container view and child views, as long as your view models know how to communicate with each other.
5. View models can be used across Apple platforms (iOS, tvOS, macOS, etc.) because they don’t import UIKit. Especially if view models are granular.

Question 29

Cons of MVVM

Answer 29

1. There are steep learning curve with RxSwift (compared to MVC.) New team members need to learn RxSwift and how to properly use view models. Development time may slow down at first, until new team members get up to speed.
2. Typical implementation requires view models to collaborate. Managing memory and syncing state across your app is more difficult when using collaborating view models.
3. Business logic is not reusable from different views, since business logic is inside view specific view models.
4. There’s no Apple-provided binding mechanism on iOS like there is on macOS.
5. It can be hard to trace and debug, because UI updates happen through binding instead of method calls.
6. View models have properties for both UI state and dependencies. This means that view models can be difficult to read, because state management is

Question 30

Binding view - view model state

Answer 30

The view binds its user interface elements to the behavior subjects, and the view model updates them internally.

Question 31

Are repositories classes or protocols?

Answer 31

Repositories are protocols

Each repository is created based on protocol

protocol UserSessionRepository { }
class KooberUserSessionRepository: UserSessionRepository { }

Question 32

What are models in MVVM? What they inherit?

Answer 32

They are codable

Question 33

EVENT: Change view state in view model

What happens in view model?

Answer 33

EVENT: Change view state in view model

What happens in view model?

Question 34

Private and Public encapsulation for Subjects

Answer 34

public var view: Observable {
return viewSubject.asObservable()
}

private let viewSubject: BehaviorSubject

Question 35

RemoteUserSession contains an AuthToken.

AuthToken is?

Answer 35

a typealisased String.

Question 36

What you shouldn’t import to view model?

Answer 36

View Model without UIKit

You’ll notice, when looking at the view model files in the sample project, that none of them import UIKit and are completely independent of UIKit. This ensures you can test the view model logic without access to any UIKit elements.