Bindings in Swift. Take the first steps to MVVM

Good day. This article will be useful to those who are tired every day of struggling with data volatility in the interface, those who do not yet know the existence of MVVM, and those who doubt that this pattern can be successfully applied in practice when developing iOS applications. Interested, I ask for cat.

Formulation of the problem

At the moment, I can’t imagine how you can safely introduce MVVM to UIKit. This refers to the very MVVM that I saw in Xamarin Forms and which impressed me so much. Most likely, for this you will have to write a framework on top of UIKit and bind the developer to this framework. We will follow the path of least resistance: we will use what Apple gives us. But at the same time, we will strive for a more declarative description of the UI.

The first and most important thing that attracted me to MVVM was the dynamic linking of ViewModel and View. This allows us to describe business logic in isolation from the presentation. We are already used to describing logic in ViewController. And this is real hell. Let's aim to minimize code in the ViewController. First you need to learn to understand that the state of our ViewModel has changed and this change must be reflected in the UI. Apple offers us to use, for example, KVO. ReactiveCocoa would simplify this task. But we have Swift. And we want to make our decision as simple and clean as possible. Here is how our colleagues suggest solving this problem:

• Exploring KVO Alternatives With Swift
• Bindings, Generics, Swift and MVVM
• Solving the binding problem with Swift
• Swift bond

By the way, do not forget about the upcoming release of Reactive Cocoa 3.0 . But while the Bond library is the most suitable for our task. While I was working on what I will show below, Bond was just starting out and did not fit my requirements. Even now, it doesn’t suit them a bit, plus everything seemed to me that the developer somehow complicated everything. I wanted to simplify everything as much as possible. But, to tell the truth, when I got into a dead end while working on my vision of how data should be associated with representations, I kept finding answers in the Bond sources .

Dynamic

Let's start with the small and, at the same time, the most important thing. We need to be able to learn about changes in the state of a variable and somehow react to these changes. Let me remind you that we strive for simplicity and conciseness. And in this case, Swift appears in all its glory. It gives us generics, lambdas with awesome syntax, observable properties. So let's make something out of it.

class Dynamic {
  init(_ v: T) {
    value = v
  }
  var value: T {
    didSet {
      println(value)
    }
  }
}

Now we have the opportunity to monitor the change in value value . In practice, it will look something like this:

let dynamicInt: Dynamic = Dynamic(0)
println(dynamicInt.value)
dynamicInt.value = 1
dynamicInt.value = 17

Add listener support for our mutable entity. The listener will be an anonymous function, into the argument of which we will pass the new value value .

class Dynamic {
  typealias Listener = T -> ()
  private var listeners: [Listener] = []
  init(_ v: T) {
    value = v
  }
  var value: T {
    didSet {
      for l in listeners { l(value) } }
  }
  func bind(l: Listener) {
    listeners.append(l)
    l(value)
  }
  func addListener(l: Listener) {
    listeners.append(l)
  }
}

The addListener method simply adds a handler to its list of listeners, and the bind method does the same, but it immediately calls the added listener and passes it the current value .

let dynText: Dynamic = Dynamic("")
dynText.bind { someLabel.text = $0 }
dynText.addListener { otherLabel.text = $0 }
dynText.value = "New text"

Thanks to the use of generics, we do not need to check or cast data types. The compiler will do this for us. For example, in the following case, the code will not be compiled:

let dynInt: Dynamic = Dynamic(0)
dynInt.bind { someLabel.text = $0 }

The compiler knows that the argument of our listener is of type Int and we cannot assign the value of this argument to the text field of the object of the UILabel class , since the type of this field is String . Moreover, thanks to the simplified syntax of anonymous functions, we were able to add listeners without too much writing. But there is no limit to perfection. We can define a couple of operators, or overload the ones available with the goal of further reducing the code.

func >> (left: Dynamic, right: T -> Void) {
  return left.addListener(right)
}
infix operator >>> {}
func >>> (left: Dynamic, right: T -> Void) {
  left.bind(right)
}

let dynText: Dynamic = Dynamic("")
dynText >>> { someLabel.text = $0 }
dynText >> { otherLabel.text = $0 }
dynText.value = "New text"

Simplification of work with UIKit

Agree, it’s unpleasant to constantly describe the same lambdas for linking text and UILabel. I want simplicity:

viewModel.someText >>> label

Nothing is impossible. After all, we can easily come to such a syntax. The implementation idea is again kindly borrowed from Bond . The idea is simple: we will store at the object of some kind a field that has a listener, and we can bind this listener to a dynamic object.

final class PropertyModifier {
  typealias Modifier = (T) -> ()
  let modifier: Modifier
  init (_ l: Modifier) {
    self.modifier = l
  }
}

An object of the PropertyModifier class will be created by the view itself, and a lambda will be passed to the constructor with code that changes the value of a certain field of the view.

private var UILabelPropertyKeyTextModifier: UInt8 = 0
extension UILabel {
  var textModifier: PropertyModifier {
    if let pm: AnyObject = objc_getAssociatedObject(self, &UILabelPropertyKeyTextModifier) {
      return pm as PropertyModifier
    } else {
      let pm = PropertyModifier { [weak self] in self?.text = v; () }
      objc_setAssociatedObject(self, &UILabelPropertyKeyTextModifier, pm, objc_AssociationPolicy(OBJC_ASSOCIATION_RETAIN_NONATOMIC))
      return pm
    }
  }
}

I note that in extension we cannot describe stored fields, so ObjC Runtime and the functions objc_setAssociatedObject , objc_getAssociatedObject come to the rescue . Now we can do this:

viewModel.someText >>> label.textModifier.modifier

Let's simplify:

func >> (left: Dynamic, right: PropertyModifier) {
  left.addListener(right.modifier)
}
func >>> (left: Dynamic, right: PropertyModifier) {
  left.bind(right.modifier)
}
viewModel.someText >>> label.textModifier

Much better. But that is not all. We can highlight some of the most used property of the view and assign it the PropertyModifier by default.

protocol BindableObject {
  typealias DefaultPropertyModifierTargetType
  var defaulPropertytModifier: PropertyModifier { get }
}
extension UILabel: BindableObject {
  typealias DefaultPropertyModifierTargetType = String?
  var defaulPropertytModifier: PropertyModifier {
    return textModifier
  }
}
func >> (left: Dynamic, right: B) {
  left.addListener(right.defaulPropertytModifier.modifier)
}
func >>> (left: Dynamic, right: B) {
  left.bind(right.defaulPropertytModifier.modifier)
}

That's all. UILabel has got a standard PropertyModifier that changes the values ​​of the text field . And we came to the appointed goal, namely, we can create a relationship as follows:

viewModel.someText >>> label

Teams

One of the noteworthy concepts in Xamarin Forms that I liked was the teams. In fact, we can describe a command using two functions: one returns true or false , indicating that the command can be executed, and the second - the action that the command performs. Let's say we have a button ( UIButton ). The button has an enabled field , the button can be pressed by the user, after which some action should happen. Remember that we strive for declarative descriptions of interface behavior? So let's extend this idea to our controls.

final class Command {
  typealias CommandType = (value: T, sender: AnyObject?) -> ()
  weak var enabled: Dynamic?
  private let command: CommandType
  init (enabled: Dynamic, command: CommandType) {
    self.enabled = enabled
    self.command = command
  }
  init (command: CommandType) {
    self.command = command
  }
  func execute(value: T) {
    execute(value, sender: nil)
  }
  func execute(value: T, sender: AnyObject?) {
    var enabled = true
    if let en = self.enabled?.value { enabled = en }
    if enabled { command(value: value, sender: sender) }
  }
}
protocol Commander {
  typealias CommandType
  func setCommand(command: Command)
}
func >> (left: B, right: Command) {
  left.setCommand(right)
}
private var UIButtonPropertyKeyCommand: UInt8 = 0
extension UIButton: Commander {
  typealias CommandType = ()
  func setCommand(command: Command) {
    if let c: AnyObject = objc_getAssociatedObject(self, &UIButtonPropertyKeyCommand) {
      fatalError("Multiple assigment to command")
      return
    }
    objc_setAssociatedObject(self, &UIButtonPropertyKeyCommand, command, objc_AssociationPolicy(OBJC_ASSOCIATION_ASSIGN))
    command.enabled?.bind { [weak self] in self?.enabled = $0; () }
    addTarget(self, action: Selector("buttonTapped:"), forControlEvents: .TouchUpInside)
  }
  func buttonTapped(sender: AnyObject?) {
    if let c: Command = objc_getAssociatedObject(self, &UIButtonPropertyKeyCommand) as? Command {
      c.execute((), sender: sender)
    }
  }
}

So, we have a command that has an enabled field and a function that must be executed when the execute method is called . We must associate our team with a button. To do this, we entered the Commander protocol with the setCommand method . We implement our protocol for UIButton by associating the dynamic field of the enabled command with the corresponding UIButton property . We also overloaded the >> operator for convenience. What do we get as a result:

class PageModel {
  let nextPageEnabled: Dynamic = Dynamic(true)
  lazy var openNextPage: Command<()> = Command (
    enabled: self.nextPageEnabled,
    command: {
      [weak self] value, sender in
      //Open next page
    })
}
class MyViewController: UIViewController {
  @IBOutlet weak var nextButton: UIButton!
  let pageModel = PageModel()
  override func viewDidLoad() {
    nextButton >> pageModel.openNextPage
    super.viewDidLoad()
  }
}

Conclusion

At our disposal appeared dynamic objects that we can associate with anything. We now have commands that allow us to describe the action by clicking on the button more expressively. And this is enough to simplify our UIViewController . Behind the scenes were map and filter for Dynamic , bidirectional binders and simplified work with UITableView . But you can take a look at this yourself. A project demonstrating the capabilities of this approach is available on GitHub . I recommend taking a look at it.

Thanks for attention. Comments, suggestions and criticism are welcome.