KVO – Augmented Code

In model-view-view model (MVVM) architecture the view model observes the model and provides data for the view by transforming it when needed. When the user interacts with the view and changes the data in it then the view model’s responsibility is to propagate those mutations back to the model object. Therefore, the important part in MVVM is how to manage data flows between objects. This time we’ll take a look on observing key-value observing (KVO) compatible model objects with Combine framework in SwiftUI view. The example view what we’ll build looks like this:

SwiftUI view with text fields for setting first name, last name, and street address. Under that is a label with recipient, postal address, and package contents descriptions. Under that is a button for adding more items to the package. — SwiftUI view which enables editing package related information and displays a summary of the package.

Model layer

The model object represents a package which contains information about the recipient, the sender, and the contents. The recipient and the sender are represented by a Person object which includes a first name, a last name, and a postal address. The contents is an array of immutable PackageContent objects. In Swift, we can use KVO by specifying @objc and dynamic modifiers on properties. Dynamic means that method dispatch is using objective-c runtime and therefore all the types must be representable in objective-c runtime. This immediately adds restrictions to the types we can use. When writing pure Swift code I do not recommend using KVO but sometimes we just need to use it. One example is NSManagedObject from the CoreData framework. But in this app we are not dealing with NSManagedObject but with a simple NSObject subclass instead.

	final class Package: NSObject {
	@objc dynamic var recipient = Person()
	@objc dynamic var sender = Person()
	@objc dynamic var contents = [PackageContent]()
	}

	final class Person: NSObject {
	@objc dynamic var firstName: String = ""
	@objc dynamic var lastName: String = ""
	@objc dynamic var postalAddress = CNPostalAddress()
	}

	final class PackageContent: NSObject {
	init(title: String, weight: Int) {
	self.title = title
	self.weight = weight
	}

	let title: String
	let weight: Int
	}

view raw PackageKVO.swift hosted with ❤ by GitHub

KVO compatible model object.

View Layer

The view object is responsible for describing the UI and rendering data represented by the view model. We have a simple form for modifying the recipient’s first name, last name, and the street name (for keeping this UI simple I left out all the other postal address related properties). At the bottom of the view we have a text object which just describes the package and a button for adding new items to the package’s contents. Whenever any of the package’s properties change, the view needs to reload. View reload is done through the @StateObject property wrapper (read mode about observing view models in MVVM in SwiftUI and @StateObject and MVVM in SwiftUI).

	struct ContentView: View {
	@StateObject var viewModel = ViewModel(package: .makeExample())

	var body: some View {
	ScrollView {
	VStack(spacing: 16) {
	Text("Recipient")
	.font(.headline)
	InputView(title: "First name",
	value: $viewModel.recipientFirstName)
	InputView(title: "Last name",
	value: $viewModel.recipientLastName)
	Text("Address")
	.font(.headline)
	InputView(title: "Street",
	placeholder: "e.g. 37 Christie St",
	value: viewModel.street)
	Text("Summary")
	.font(.headline)
	Text(viewModel.summary)
	.frame(maxWidth: .infinity, alignment: .leading)
	Button("Add item", action: viewModel.addRandomItem)
	}
	.padding()
	}
	}
	}

view raw ContentView.swift hosted with ❤ by GitHub

View Model layer

The view model’s responsibility is to observe the model object and propagating view changes to the model. It acts as a transformation layer where we can transform any data in the model to anything suitable for displaying. In the example below we are reading CNPostalAddress and only returning street name and reading multiple properties and returning a summary string. View models make it easy to contain such logic and also make it more easy to test.

Foundation framework defines a publisher named NSObject.KeyValueObservingPublisher which can be used for observing KVO compatible properties. One of the approaches is to use this publisher and then bind the model changes to the view model’s own property. Combine framework provides a convenient assign operator which takes a target publisher as an argument. Convenient because we can connect it with @Published properties in the view model. @Published properties automatically notify the ObservableObject’s objectWillChange publisher which is observed by a SwiftUI view. As soon as the property changes, SwiftUI view picks up the change and reloads itself. Note that we’ll also need to propagate changes back to the model when user updates the view and therfore the @Published property. This can be achieved by connecting property’s publisher with dropFirst, removeDuplicates and assign publishers where the latter assigns the value to the model object. Drop first is used for ignoring the initial value of the property. One downside is that now we can have the same information both in the view model and in the model. But on the other hand it makes the data streams easy to read and no need to have extra observation for triggering the view reload by manually calling send() on the objectWillChange publisher.

	@Published var recipientFirstName: String = ""

	// Model -> View Model
	package.recipient.publisher(for: \.firstName)
	.assign(to: &$recipientFirstName)

	// View Model -> Model
	$recipientFirstName.dropFirst()
	.removeDuplicates()
	.assign(to: \.firstName, on: package.recipient)
	.store(in: &cancellables)

view raw ViewModel.swift hosted with ❤ by GitHub

Observing model and view changes.

Another approach what we can use is providing properties in the view model which return a Binding. This allows us to write the transformation code inside the get and set closures. This is what we have done with the street property. Note that we’ll still need to observe the model as the model can change at any point. Binding just provides a way of accessing the value. Therefore, we’ll need to set up an observation and calling send() on the objectWillChange publisher.

	// Observing changes
	package.recipient.publisher(for: \.postalAddress)
	.notifyObjectWillChange(objectWillChange)
	.store(in: &cancellables)

	// Providing a binding for the view
	var street: Binding<String> {
	let package = self.package
	return Binding<String>(
	get: {
	package.recipient.postalAddress.street
	},
	set: { newValue in
	let postalAddress = package.recipient.postalAddress.mutableCopy() as! CNMutablePostalAddress
	postalAddress.street = newValue
	package.recipient.postalAddress = postalAddress
	}
	)
	}

	extension Publisher where Self.Failure == Never {
	public func notifyObjectWillChange(_ objectWillChange: ObservableObjectPublisher) -> AnyCancellable {
	return self.sink { _ in
	objectWillChange.send()
	}
	}
	}

view raw ViewModel.swift hosted with ❤ by GitHub

Providing a binding for the view.

If we go back to the SwiftUI view and connect all the properties then the full implementation of the view model looks like this:

	extension ContentView {
	final class ViewModel: ObservableObject {
	private let package: Package
	private var cancellables = [AnyCancellable]()

	init(package: Package) {
	self.package = package

	// Model -> View Model
	package.recipient.publisher(for: \.firstName)
	.assign(to: &$recipientFirstName)
	package.recipient.publisher(for: \.lastName)
	.assign(to: &$recipientLastName)

	package.recipient.publisher(for: \.postalAddress)
	.notifyObjectWillChange(objectWillChange)
	.store(in: &cancellables)
	package.publisher(for: \.contents)
	.notifyObjectWillChange(objectWillChange)
	.store(in: &cancellables)

	// View Model -> Model
	$recipientFirstName.dropFirst()
	.removeDuplicates()
	.assign(to: \.firstName, on: package.recipient)
	.store(in: &cancellables)
	$recipientLastName.dropFirst()
	.removeDuplicates()
	.assign(to: \.lastName, on: package.recipient)
	.store(in: &cancellables)
	}

	// Example of using published property
	@Published var recipientFirstName: String = ""
	@Published var recipientLastName: String = ""

	// Example of using bindings for propagating values
	var street: Binding<String> {
	let package = self.package
	return Binding<String>(
	get: {
	package.recipient.postalAddress.street
	},
	set: { newValue in
	let postalAddress = package.recipient.postalAddress.mutableCopy() as! CNMutablePostalAddress
	postalAddress.street = newValue
	package.recipient.postalAddress = postalAddress
	}
	)
	}

	var summary: String {
	let contents = package.contents
	.map({ "\($0.title) \($0.weight)" })
	.joined(separator: ", ")
	return """
	Recipient: \(package.recipient.firstName) \(package.recipient.lastName)
	Postal address: \(CNPostalAddressFormatter().string(from: package.recipient.postalAddress))
	Contents: \(contents)
	"""
	}

	func addRandomItem() {
	let weight = Int.random(in: 200…300)
	let item = PackageContent(title: "Light bulb", weight: weight)
	package.contents.append(item)
	}
	}
	}

view raw ViewModel.swift hosted with ❤ by GitHub

View model implementation for the view.

Summary

Key-value observing is getting less and less used after the introduction of Combine and SwiftUI. But there are still times when we need to connect good old KVO compatible NSObject subclasses with a SwiftUI view. Therefore, it is good to know how to handle KVO in SwiftUI views as well.

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Project

SwiftUIMVVMKVOObserving (GitHub, Xcode 12.1)

Support me on Patreon

Donate with Paypal

Buy me a coffee

When writing code in Swift it is often needed to observe changes in other objects. We can use Apple’s key-value observation but it has some implications: requires to use NSObject and dynamic dispatch through Objective-C runtime. This time, let’s build a simple key-value observation in Swift what does not require to use NSObject at all. Although it is far from being as feature complete as Apple’s implementation, it delivers the basic use-case which is often all what we need.

Custom KeyValueObservable protocol

The approach we take here is defining a protocol, providing default implementations for all the functions. Then we can make any class to conform to this protocol, but as we need to store observation related information, then the class needs to define a property holding an instance of ObservationStore. Secondly, it is required to send key-value change notification manually using didChangeValue(for:).

Add observer function returns an instance of Observation what can be used for removing the added observation. If the observer does not need to be removed during the lifetime of the observer, it can be ignored. Observation is always cleaned up automatically next time any key value changes happen after observer is deallocated. This is due to the fact that observation handler captures observer weakly and during key-value changes, it is checked if the object is still alive or not.

	protocol KeyValueObservable where Self: AnyObject {
	/// Stores all the added observations.
	var observationStore: ObservationStore<Self> { get }

	/// Sends key-value change notification to all the observers for this key path.
	func didChangeValue(for keyPath: PartialKeyPath<Self>)

	/// Adds observer for key path and returns observation token.
	/// – Note: Observation token is only useful if it is needed to remove observation before observer is deallocated. When observer is deallocated, then observation is removed when next key value change is handled.
	@discardableResult func addObserver<Observer: AnyObject, Value>(_ observer: Observer,
	keyPath: KeyPath<Self, Value>,
	options: Observation.Options,
	handler: @escaping (Observer, Value) -> Void) -> Observation

	/// Removes added observation.
	func removeObservation(_ observation: Observation)
	}

view raw KeyValueObservable.swift hosted with ❤ by GitHub

Adding default implementations

When adding observer, we create an observation handler what captures self and observer weakly. Handler returns boolean, what tells if the handler is still valid or not. Handler is not valid when observer has been deallocated since the last change. Otherwise handler is valid and should not be removed automatically.

	extension KeyValueObservable {
	@discardableResult func addObserver<Observer: AnyObject, Value>(_ observer: Observer, keyPath: KeyPath<Self, Value>, options: Observation.Options, handler: @escaping (Observer, Value) -> Void) -> Observation {
	let observation = Observation()
	let observationHandler: (PartialKeyPath<Self>) -> Bool = { [weak self, weak observer] changedKeyPath in
	guard let self = self else { return false }
	guard let observer = observer else { return false }
	guard changedKeyPath == keyPath else { return true }
	handler(observer, self[keyPath: keyPath])
	return true
	}
	observationStore.observationInfos[observation] = observationHandler

	if options.contains(.initial) {
	handler(observer, self[keyPath: keyPath])
	}

	return observation
	}

	func removeObservation(_ observation: Observation) {
	observationStore.observationInfos.removeValue(forKey: observation)
	}

	func didChangeValue(for keyPath: PartialKeyPath<Self>) {
	observationStore.observationInfos = observationStore.observationInfos.filter({ (_, handler) -> Bool in
	return handler(keyPath)
	})
	}
	}

view raw KeyValueObservable.swift hosted with ❤ by GitHub

Supporting objects to key-value observing

As mentioned before, ObservationStore is needed to added to every class conforming to KeyValueObservable protocol. It stores all the observations and restricts the access to modifying the observations directly from the observable class.

Observation is a simple struct containing an identifier and subtype defining the observation options. In this basic case, it just has initial option what assures handler is called immediately when adding an observer.

	final class ObservationStore<T> {
	fileprivate var observationInfos = [Observation: (PartialKeyPath<T>) -> Bool]()

	var observations: [Observation] {
	return observationInfos.map({ $0.key })
	}

	func removeAll() {
	observationInfos.removeAll()
	}
	}

	struct Observation: Hashable {
	fileprivate let identifier = UUID()

	struct Options: OptionSet {
	let rawValue: Int
	static let initial = Options(rawValue: 1 << 0)
	}
	}

view raw KeyValueObservable.swift hosted with ❤ by GitHub

Conforming to KeyValueObservable

In this small example a class Event conforms to KeyValueObservable and ViewController observers the title change and updates a label.

	final class Event: KeyValueObservable {
	let observationStore = ObservationStore<Event>()

	var title: String = "Initial Title" {
	didSet {
	didChangeValue(for: \Event.title)
	}
	}
	}

	final class ViewController: UIViewController {
	let event = Event()

	@IBOutlet weak var label: UILabel!

	override func viewDidLoad() {
	super.viewDidLoad()
	event.addObserver(self, keyPath: \.title, options: .initial) { (observer, title) in
	observer.label.text = title
	}
	}

	@IBAction func changeTitle(_ sender: Any) {
	event.title = "New Title"
	}
	}

view raw Observing.swift hosted with ❤ by GitHub

Summary

This time we added basic support for observing key paths without using key-value observing APIs known already from Objective-C times. The added KeyValueObservable protocol is easy to add to existing classes but requires manually calling didChangeValue(for:) for every property change.

Inspiration came from Observers in Swift part 2 (Swift by Sundell).

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Resources

Observers in Swift part 2 (Swift by Sundell)