MVVM for iOS & Swift

read

View Model (VM)

The VM is a 1-1 with view controller.

It is actually simply a composition pattern, by separating responsibility from the View Controller (VC).

View Model stands between the Model and the View Controller, and provide the data that a view controller needs to display in it’s views.

View Controller NO longer access the model directly.

If the model has a NSDate, then the VM will have the NSDateFormatter that knows how to display the date as a string for the view.

A VM does not know about the view.

It does not know stuff about presentation, but it does provide the data for presenting.

Note that is “data” for presenting is not the actual model, but a intermediatry object (aka boundary object).

Networking call is a grey area. Neither VM nor VC defines where the network logic should go.

But it is safer to be in VM. Or use another composition pattern with a network object.

It is actually not much different.

The introduction of a View Model simply extract the business/app logics out of a View Controller.

It uses a composition pattern, so a VC now will have a VM. In doing so, you can now write tests for the VM (which has the important business logics).

Remember, VM does not know anything about the VC.

Just like VC does not know anything about the model.

VM and VC can communicate via delegates or Functional Reactive Programming (FRP).

You would have have know delegate pattern, which is widely used in Apple’s frameworks. It can work, except it is verbose.

A better way is FRP, which you would have heard in the form of Reactive. A good introduction to FRP is the Swift Bond tutorial by raywenderlich

(alas, Swift does not support binding out of the box, so a tool like ReactiveKit is much needed)

This very cool framework was first known as Bond, Swift Bond.

It’s successor is ReactiveKit, which is now made up of a few components:

Compared to other libraries doing the same think (like Reactive Cocoa), ReactiveKit looks great.