Category: Generics

Loading async data for SwiftUI views

Post author By Toomas Vahter
Post date November 13, 2023

Sometimes we need to invoke an async function for fetching data before presenting a SwiftUI view. Therefore, a common flow is showing a spinner while the data is being fetched and then showing the main view. Moreover, if an error occurs, we show a failure view with a retry button. Let’s dive in how to build such view in a generic way.

As said before, our container view, let’s call it ContentPrepareView (similar naming to Apple’s ContentUnavailableView), has three distinct states: loading, failure, and success (named as “content” in the enum).

	extension ContentPrepareView {
	enum ViewContent {
	case loading
	case content
	case failure(Error)
	}
	}

view raw ViewContent.swift hosted with ❤ by GitHub

We’ll go for a fully generic implementation where each of the view state corresponds to a view builder. This gives as flexibility if in some places we want to use custom loading views or different failure view. But on the other hand, most of the time we just want to use a common loading and failure views, that is why we set default values for loading and failure view builders (see below). In addition to view builders, we need an async throwing task closure which handles the data fetching/preparation. If we put it all together, then the ContentPrepareView becomes this:

	struct ContentPrepareView<Content, Failure, Loading>: View where Content: View, Failure: View, Loading: View {
	@State private var viewContent: ViewContent = .loading

	@ViewBuilder let content: () -> Content
	@ViewBuilder let failure: (Error, @escaping () async -> Void) -> Failure
	@ViewBuilder let loading: () -> Loading
	let task: () async throws -> Void

	init(content: @escaping () -> Content,
	failure: @escaping (Error, @escaping () async -> Void) -> Failure = { FailureView(error: $0, retryTask: $1) },
	loading: @escaping () -> Loading = { ProgressView() },
	task: @escaping () async throws -> Void) {
	self.content = content
	self.failure = failure
	self.loading = loading
	self.task = task
	}

	var body: some View {
	Group {
	switch viewContent {
	case .content:
	content()
	case .failure(let error):
	failure(error, loadTask)
	case .loading:
	loading()
	}
	}
	.onLoad(perform: loadTask)
	}
	// redacted
	}

view raw ContentPrepareView.swift hosted with ❤ by GitHub

Since loading, failure and success views can be any kind of views, then our view needs to be a generic view. The body of the view has a switch-case for creating a view for the current view state. One thing to note here is that the onLoad view modifier is a custom one, and the idea is that it makes sure that the content preparation work only runs once per view life-time (onAppear() or task() can run multiple times). The reasoning is that we want to have an experience where we show the loading spinner only when the view is presented the first time, not when it appears again. The loadTask function is async and has responsibility of running the passed in async task closure and updating the current view state.

	struct ContentPrepareView<Content, Failure, Loading>: View where Content: View, Failure: View, Loading: View {
	// redacted
	@MainActor func loadTask() async {
	do {
	viewContent = .loading
	try await task()
	viewContent = .content
	}
	catch {
	viewContent = .failure(error)
	}
	}
	}

view raw LoadTask.swift hosted with ❤ by GitHub

In this example we used a custom FailureView and it is a small view wrapping Apple’s ContentUnavailableView. It sets a label, description and handles the creation of the retry button.

	struct FailureView: View {
	let error: Error
	let retryTask: () async -> Void

	var body: some View {
	ContentUnavailableView(label: {
	Label("Failed to load", systemImage: "exclamationmark.circle.fill")
	}, description: {
	Text(error.localizedDescription)
	}, actions: {
	Button(action: {
	Task { await retryTask() }
	}, label: {
	Text("Retry")
	})
	})
	}
	}

view raw FailureView.swift hosted with ❤ by GitHub

Here is an example how to use the final ContentPrepareView. For demo purposes, it fails the first load and allows succeeding the second.

	struct ContentView: View {
	// Demo: first load leads to an error
	@State private var showsError = true

	var body: some View {
	ContentPrepareView {
	VStack {
	Image(systemName: "globe")
	.imageScale(.large)
	.foregroundStyle(.tint)
	Text("Hello, world!")
	}
	.padding()
	} task: {
	try await Task.sleep(nanoseconds: 3_000_000_000)
	// Demo: Retrying a task leads to success
	guard showsError else { return }
	showsError = false
	throw LoadingError.example
	}
	}
	}

	enum LoadingError: LocalizedError {
	case example

	var errorDescription: String? {
	"The connection to Internet is unavailable"
	}
	}

view raw Usage.swift hosted with ❤ by GitHub

ContentPrepareViewExample (GitHub, Xcode 15.0.1)

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.

Support me on Patreon

Donate with Paypal

Buy me a coffee

Tags async, iOS, loading, Swift, SwiftUI

Combine CoreData Foundation Generics iOS Swift SwiftUI Xcode

Using CoreData with SwiftUI

Post author By Toomas Vahter
Post date January 19, 2020
1 Comment on Using CoreData with SwiftUI

CoreData is Apple’s object graph and persistence framework. It provides data sources for synchronising data with view. Let’s take a look on how to use those data sources in SwiftUI views. Starting with NSFetchedResultsController what is used for list and collection views, after that observing NSManagedObject directly from SwiftUI view and lastly subscribing to managed object context notifications.

NSFetchedResultsController

NSFetchedResultsController is used for providing data in table and collection views. It supports sorting and filtering data and arranging data into sections. We can use delegate for getting change callbacks. NSFetchedResultsControllerDelegate contains several methods:

	// Diffable data source (new in iOS 13)
	optional func controller(_ controller: NSFetchedResultsController<NSFetchRequestResult>, didChangeContentWith snapshot: NSDiffableDataSourceSnapshot)
	optional func controller(_ controller: NSFetchedResultsController<NSFetchRequestResult>, didChangeContentWith diff: CollectionDifference<NSManagedObjectID>)

	// Manually updating table view and collection view
	optional func controller(_ controller: NSFetchedResultsController<NSFetchRequestResult>, didChange anObject: Any, at indexPath: IndexPath?, for type: NSFetchedResultsChangeType, newIndexPath: IndexPath?)
	optional func controller(_ controller: NSFetchedResultsController<NSFetchRequestResult>, didChange sectionInfo: NSFetchedResultsSectionInfo, atSectionIndex sectionIndex: Int, for type: NSFetchedResultsChangeType)
	optional func controllerWillChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>)
	optional func controllerDidChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>)

view raw DataSources.swift hosted with ❤ by GitHub

In SwiftUI we are not going to directly manipulate views. Only what we need to do is letting SwiftUI view know that data is about to change. Let’s take a look on simple app with list of items stored by CoreData. Data is represented by ColorItem where only stored value is hex string of the color (e.g. #AA22BB).

	final class ColorItem: NSManagedObject {
	@NSManaged var hex: String
	}

view raw ColorItem.swift hosted with ❤ by GitHub

ColorItems are managed by ContentView’s view model. View model creates NSFetchedResultsController, performs fetch and provides array of fetched ColorItems to the SwiftUI’s List. In addition, view model is delegate of the NSFetchedResultsController (requires view model to be NSObject subclass). As view model is ObservableObject, we can very easily let SwiftUI view know that it should refresh. We need to do two things: firstly, implementing controllerWillChangeContent delegate method and calling send() on objectWillChange publisher. Secondly, view model property must use @ObservedObject property wrapper in SwiftUI view. Result is that SwiftUI view subscribes to objectWillChange publisher and refreshes whenever publisher emits an event.

	extension ContentView {
	final class ViewModel: NSObject, NSFetchedResultsControllerDelegate, ObservableObject {
	private let colorController: NSFetchedResultsController<ColorItem>

	init(managedObjectContext: NSManagedObjectContext) {
	let sortDescriptors = [NSSortDescriptor(keyPath: \ColorItem.hex, ascending: true)]
	colorController = ColorItem.resultsController(context: managedObjectContext, sortDescriptors: sortDescriptors)
	super.init()
	colorController.delegate = self
	try? colorController.performFetch()
	}

	func controllerWillChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>) {
	objectWillChange.send()
	}

	var colors: [ColorItem] {
	return colorController.fetchedObjects ?? []
	}
	}
	}

	extension ColorItem {
	static func resultsController(context: NSManagedObjectContext, sortDescriptors: [NSSortDescriptor] = []) -> NSFetchedResultsController<ColorItem> {
	let request = NSFetchRequest<ColorItem>(entityName: "ColorItem")
	request.sortDescriptors = sortDescriptors.isEmpty ? nil : sortDescriptors
	return NSFetchedResultsController(fetchRequest: request, managedObjectContext: context, sectionNameKeyPath: nil, cacheName: nil)
	}
	}

view raw ViewModelFetchedResults.swift hosted with ❤ by GitHub

And finally let’s see the ContentView implementation. NSManagedObject has objectID property what we can use in List for identifying every ColorItem. Cell is custom view what we’ll take a look at next.

	struct ContentView: View {
	@ObservedObject var viewModel: ViewModel

	var body: some View {
	NavigationView {
	VStack {
	List(viewModel.colors, id: \.objectID) { (colorItem) in
	Cell(colorItem: colorItem)
	}
	}.navigationBarTitle("Colors")
	}
	}
	}

view raw ContentViewFetchedResults.swift hosted with ❤ by GitHub

NSManagedObject

NSManagedObject implements ObservableObject protocol and therefore it is possible to use it together with @ObservedObject property wrapper and getting SwiftUI view refreshed automatically when any of the ColorItem properties change. NSFetchedResultsController required a little bit of code for setting up delegate but that is not the case with NSManagedObject.

	struct Cell: View {
	@ObservedObject var colorItem: ColorItem

	var body: some View {
	HStack {
	Text(verbatim: colorItem.hex)
	Spacer()
	Rectangle().foregroundColor(Color(colorItem.uiColor)).frame(minWidth: 50, maxWidth: 50)
	}
	}
	}

view raw Cell.swift hosted with ❤ by GitHub

In addition, if there are cases where we would like to observe specific property, then Combine provides publisher for key path. Because NSManagedObject supports key-value observing we can use the publisher and subscribe to individual property changes.

	let cancellable = color.publisher(for: \.hex).sink { (string) in
	print(string)
	}

view raw KVOPublisherSink.swift hosted with ❤ by GitHub

Subscribing to CoreData notifications

When we need to observe changes in persistent store we can observe notifications sent by the framework. As NotificationCenter supports publishers, we can subscribe to it, unpack data from notification and do something with the data. For making this easier we can introduce a separate type. It will unpack the user info dictionary and filter by type. This allows to easily observe, for example, ColorItem insertions. Or, if we would like to receive every possible change, we can specify NSManagedObject as the generic type.

	private var cancellables = [AnyCancellable]()

	let cancellable = NotificationCenter.default.publisher(for: .NSManagedObjectContextObjectsDidChange, object: managedObjectContext)
	.compactMap({ ManagedObjectContextChanges<ColorItem>(notification: $0) }).sink { (changes) in
	print(changes)
	}
	cancellables.append(cancellable)

	struct ManagedObjectContextChanges<T: NSManagedObject> {
	let inserted: Set<T>
	let deleted: Set<T>
	let updated: Set<T>

	init?(notification: Notification) {
	let unpack: (String) -> Set<T> = { key in
	let managedObjects = (notification.userInfo?[key] as? Set<NSManagedObject>) ?? []
	return Set(managedObjects.compactMap({ $0 as? T }))
	}
	deleted = unpack(NSDeletedObjectsKey)
	inserted = unpack(NSInsertedObjectsKey)
	updated = unpack(NSUpdatedObjectsKey).union(unpack(NSRefreshedObjectsKey))
	if deleted.isEmpty, inserted.isEmpty, updated.isEmpty {
	return nil
	}
	}
	}

view raw ManagedObjectContextChanges.swift hosted with ❤ by GitHub

Summary

We took a look at how to use NSFetchedResultsController and NSManagedObject in SwiftUI views. We saw that integrating NSFetchedResultsController requires only a little bit of code and using NSManagedObject even less. In addition, we looked at subscribing to CoreData notifications and unpacking notification payload.

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.

Example project

CoreDataCombineSwiftUI (Xcode 11.3)

Support me on Patreon

Donate with Paypal

Buy me a coffee

Tags AnyCancellable, CoreData, List, NSDeletedObjectsKey, NSFetchedResultsController, NSInsertedObjectsKey, NSManagedObject, NSManagedObjectContext, NSObject, NSRefreshedObjectsKey, NSUpdatedObjectsKey, objectWillChange, ObservableObject, ObservedObject, persistence, persistent, SwiftUI

Foundation Generics iOS macOS Swift

Persistent reusable container for item collections in Swift

Post author By Toomas Vahter
Post date October 27, 2019
No Comments on Persistent reusable container for item collections in Swift

Let’s build a container where we can store collections of items conforming to a protocol. All the collections are identified by a case in enum. For making the container reusable, we’ll use protocols as requirements on keys and items in collections. Moreover, the container should be archivable and unarchivable.

Creating a reusable container

Container’s implementation wraps a dictionary and adds methods for conveniently adding an item for key. Key must implement Hashable and RawRepresentable: then it can be used in Dictionary and converting it to representation suitable for storing on disk.

Every item needs to implement ContainerItem protocol what requires to implement methods used when archiving and unarchiving the item. Thanks to Codable protocol in Swift, it is very simple to transform the item to data and back. ContainerItem provides default implementations for its own methods when the type is conforming to Codable. Therefore, when some type wants to implement ContainerItem, then it only needs to conform to ContainerItem and Codable and default implementations will do the rest.

	final class Container<Key: Hashable & RawRepresentable> {
	private var storage = [Key: [ContainerItem]]() {
	didSet {
	didChange()
	}
	}

	init(content: [Key: [ContainerItem]] = [:]) {
	storage = content
	}

	func add(_ item: ContainerItem, key: Key) {
	if var current = storage[key] {
	current.append(item)
	storage[key] = current
	}
	else {
	storage[key] = [item]
	}
	}

	func items<T: ContainerItem>(forKey key: Key) -> [T] {
	guard let all = storage[key] else { return [] }
	return all as! [T]
	}

	var didChange: () -> Void = {}
	}

	protocol ContainerItem {
	init?(jsonData: Data)
	var jsonDataRepresentation: Data { get }
	}

	extension ContainerItem where Self: Codable {
	init?(jsonData: Data) {
	guard let object = try? JSONDecoder().decode(Self.self, from: jsonData) else { return nil }
	self = object
	}

	var jsonDataRepresentation: Data {
	return try! JSONEncoder().encode(self)
	}
	}

view raw PersistentReusableContainer.swift hosted with ❤ by GitHub

Reusable container storing collections of items

Archiving and unarchiving the container and it’s content

Let’s first extend the container with write method. As enum cases are used as keys in dictionary, then let’s implement write method for enums what have String as RawValue. (what should be a preferred way in this use case as its provides the most readable representation of the key). We can then map dictionary entries so that key is converted to String and value to array of JSON data objects. NSKeyedArchiver provides a simple way of storing Dictionary with archivable types (like String and array of Data).

For initialising the container from data on disk, we need to make sure that we convert JSON data back to the correct type. Therefore we can extend the container for this specific enum case and converting data back to the correct type. When using enums it is easy to switch over the possible cases and then converting list of data objects to list of known types.

	struct EventItem: ContainerItem, Codable {
	let date: Date
	let title: String
	let description: String
	}

	struct NoteItem: ContainerItem, Codable {
	let text: String
	}

	enum CalendarKeys: String {
	case homeEvents, workEvents, notes
	}

	extension Container where Key == CalendarKeys {
	convenience init(contentsOfURL url: URL) throws {
	let data = try Data(contentsOf: url)
	let contents = try NSKeyedUnarchiver.unarchiveTopLevelObjectWithData(data) as! [Key.RawValue: [Data]]
	let converted = contents.compactMap({ (keyValuePair) -> (Key, [ContainerItem])? in
	guard let key = Key(rawValue: keyValuePair.key) else { return nil }
	switch key {
	case .homeEvents, .workEvents:
	return (key, keyValuePair.value.compactMap({ EventItem(jsonData: $0) }))
	case .notes:
	return (key, keyValuePair.value.compactMap({ NoteItem(jsonData: $0) }))
	}
	})
	self.init(content: Dictionary(uniqueKeysWithValues: converted))
	}
	}

	extension Container where Key.RawValue == String {
	func write(to url: URL) throws {
	let converted = storage.map { (keyValuePair) -> (String, [Data]) in
	return (keyValuePair.key.rawValue, keyValuePair.value.map({ $0.jsonDataRepresentation }))
	}
	let data = try NSKeyedArchiver.archivedData(withRootObject: Dictionary(uniqueKeysWithValues: converted), requiringSecureCoding: false)
	try data.write(to: url, options: .atomicWrite)
	}
	}

view raw PersistentReusableContainer.swift hosted with ❤ by GitHub

Providing methods for archiving and unarchiving

Summary

Wrapping dictionary with another type can be useful inmany cases where we have a known list of keys. Specialising generic types is an efficient way of adding more features to it and keeping type information intact. Thanks to Codable protocol we were able to make types archivable and unarchivable.

	let container = Container<CalendarKeys>()

	let event1 = EventItem(date: Date(), title: "title1", description: "description1")
	container.add(event1, key: .homeEvents)
	let event2 = EventItem(date: Date(), title: "title2", description: "description2")
	container.add(event2, key: .workEvents)
	let note1 = NoteItem(text: "text3")
	container.add(note1, key: .notes)

	let homeEvents: [EventItem] = container.items(forKey: .homeEvents)
	let workEvents: [EventItem] = container.items(forKey: .workEvents)
	let notes: [NoteItem] = container.items(forKey: .notes)

	let url = URL(fileURLWithPath: NSTemporaryDirectory()).appendingPathComponent("Test")
	do {
	try container.write(to: url)
	}
	catch {
	print(error as NSError)
	}

	do {
	let restoredContainer = try Container<CalendarKeys>(contentsOfURL: url)
	let homeEvents: [EventItem] = restoredContainer.items(forKey: .homeEvents)
	let workEvents: [EventItem] = restoredContainer.items(forKey: .workEvents)
	let notes: [NoteItem] = restoredContainer.items(forKey: .notes)
	print("Home events: ", homeEvents)
	print("Work events: ", workEvents)
	print("Notes: ", notes)
	}
	catch {
	print(error as NSError)
	}

view raw PersistentReusableContainer.swift hosted with ❤ by GitHub

Example usage of the container

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.

Example

PersistentGenericContainer (Xcode 11.1)

Tags Codable, container, enum, generic, Hashable, JSON, NSKeyedArchiver, NSKeyedUnarchiver, RawRepresentable, reusable

Generics iOS Swift UIKit

Testing networking code with custom URLProtocol on iOS

Post author By Toomas Vahter
Post date May 26, 2019
2 Comments on Testing networking code with custom URLProtocol on iOS

Testing networking code might sound tricky at first but in reality, it just means using custom URLProtocol what returns data we would like to. This allows testing the networking module without mocking URLSession. Using this approach we could do so much more, even integrating a third party networking library.

Networking class wrapping URLSession

Firstly, let’s set up a simple WebClient class what uses URLSession for initiating networking requests. It has a fetch method for loading URLRequest and transforming the response to expected payload type using Codable. As payload can be any type, we use generics here. Note that we need to pass in the payload type as a variable because we need the exact type when decoding the JSON data. How can we test this as URLSession would try to send an actual request to designated URL? As unit tests should behave exactly the same all the time and should not depend on external factors, then using a separate test server is not preferred. Instead, we can intercept the request and provide the response with custom URLProtocol.

	final class WebClient {
	private let urlSession: URLSession

	init(urlSession: URLSession) {
	self.urlSession = urlSession
	}

	func fetch<T: Decodable>(_ request: URLRequest, requestDataType: T.Type, completionHandler: @escaping (Result<T, FetchError>) -> Void) {
	let dataTask = urlSession.dataTask(with: request) { (data, urlResponse, error) in
	if let error = error {
	DispatchQueue.main.async {
	completionHandler(.failure(.connection(error)))
	}
	return
	}
	guard let urlResponse = urlResponse as? HTTPURLResponse else {
	DispatchQueue.main.async {
	completionHandler(.failure(.unknown))
	}
	return
	}
	switch urlResponse.statusCode {
	case 200..<300:
	do {
	let payload = try JSONDecoder().decode(requestDataType, from: data ?? Data())
	DispatchQueue.main.async {
	completionHandler(.success(payload))
	}
	}
	catch let jsonError {
	DispatchQueue.main.async {
	completionHandler(.failure(.invalidData(jsonError)))
	}
	}
	default:
	DispatchQueue.main.async {
	completionHandler(.failure(.response(urlResponse.statusCode)))
	}
	}
	}
	dataTask.resume()
	}
	}

	extension WebClient {
	enum FetchError: Error {
	case response(Int)
	case invalidData(Error)
	case connection(Error)
	case unknown
	}
	}

view raw WebClient.swift hosted with ❤ by GitHub

Creating custom URLProtocol for unit tests

URLProtocol is meant to be overridden. Firstly, we’ll need to override canInit(with:) and return true here allowing URLSession to use this protocol for any URL request. Secondly, it is required to override canonicalRequest(for:) where we can just return the same request. Thirdly, startLoading, where we have the loading logic which uses class property for returning appropriate response. This allows us to set this property in unit tests and then returning the result when URLSession handles the fetch request. Finally, URLProtocol also needs to define stopLoading method what we can just leave empty as this protocol is not asynchronous.

	final class TestURLProtocol: URLProtocol {
	override class func canInit(with request: URLRequest) -> Bool {
	return true
	}

	override class func canonicalRequest(for request: URLRequest) -> URLRequest {
	return request
	}

	static var loadingHandler: ((URLRequest) -> (HTTPURLResponse, Data?, Error?))?

	override func startLoading() {
	guard let handler = TestURLProtocol.loadingHandler else {
	XCTFail("Loading handler is not set.")
	return
	}
	let (response, data, error) = handler(request)
	if let data = data {
	client?.urlProtocol(self, didReceive: response, cacheStoragePolicy: .notAllowed)
	client?.urlProtocol(self, didLoad: data)
	client?.urlProtocolDidFinishLoading(self)
	}
	else {
	client?.urlProtocol(self, didFailWithError: error!)
	}
	}

	override func stopLoading() {}
	}

view raw TestURLProtocol.swift hosted with ❤ by GitHub

Using TestURLProtocol for mocking network requests in unit tests

Setting up a unit test requires to set the TestURLProtocol’s loadingHandler and returning the data we would like to. Then we create URLSessionConfiguration and set our TestURLProtocol to protocolClasses. After that we can use this configuration for initialising URLSession and using this session in our WebClient which handles fetch requests. That is pretty much all we need to do for testing networking requests.

	final class WebClientTests: XCTestCase {
	override func tearDown() {
	TestURLProtocol.loadingHandler = nil
	}

	struct TestPayload: Codable, Equatable {
	let country: String
	}

	func testFetchingDataSuccessfully() {
	let expected = TestPayload(country: "Estonia")
	let request = URLRequest(url: URL(string: "https://www.example.com")!)
	let responseJSONData = try! JSONEncoder().encode(expected)
	TestURLProtocol.loadingHandler = { request in
	let response = HTTPURLResponse(url: request.url!, statusCode: 200, httpVersion: nil, headerFields: nil)!
	return (response, responseJSONData, nil)
	}

	let expectation = XCTestExpectation(description: "Loading")
	let configuration = URLSessionConfiguration.ephemeral
	configuration.protocolClasses = [TestURLProtocol.self]
	let client = WebClient(urlSession: URLSession(configuration: configuration))
	client.fetch(request, requestDataType: TestPayload.self) { (result) in
	switch result {
	case .failure(let error):
	XCTFail("Request was not successful: \(error.localizedDescription)")
	case .success(let payload):
	XCTAssertEqual(payload, expected)
	}
	expectation.fulfill()
	}
	wait(for: [expectation], timeout: 1)
	}
	}

view raw WebClientTests.swift hosted with ❤ by GitHub

Summary

Testing networking code at first might sound daunting. But actually it just boils down to using custom URLProtocol and providing response we need to in our test.

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.

Example project

TestingNetworkRequests (Xcode 5.0, Xcode 10.2.1)

Resources

Testing Tips & Tricks (WWDC’18, 417)

Tags Codable, Generics, mocking, networking, testing, URLProtocol, URLRequest, URLSession

Generics iOS Swift UIKit

Instantiating view controllers from UIStoryboard on iOS

Post author By Toomas Vahter
Post date March 31, 2019
No Comments on Instantiating view controllers from UIStoryboard on iOS

There are several ways how to create user interfaces on iOS: programmatically, xib per view or using storyboard for multiple views. Personally I tend to use xibs and programmatically created layouts more but sometimes I also use UIStoryboard – depends on the situation on hand. Therefore I like to present two small additions to UIStoryboard API what makes instantiating view controllers more compact and convenient to use.

	let storyboard = UIStoryboard(name: "Main", bundle: nil)
	let viewController = storyboard.instantiateViewController(withIdentifier: "contacts") as! ContactsViewController

view raw UIStoryboard.swift hosted with ❤ by GitHub

The approach I would like to present is a generic instantiate view controller method. It implies that in storyboard, the view controller’s identifier is set to the name of the view controller class.

When Storyboard ID for the view controller is set to the class name, it is now easy to derive the identifier from a type. It should be noted that in Swift, NSStringFromClass returns string with format <module name>.<class name>. Therefore it required to parse the returned string and taking only the class name part.

	extension UIStoryboard {
	func instantiateViewController<T: UIViewController>(withType type: T.Type) -> T {
	let className = NSStringFromClass(type).split(separator: ".").last!
	return instantiateViewController(withIdentifier: String(className)) as! T
	}
	}

view raw UIStoryboard.swift hosted with ❤ by GitHub

In addition, with convenience method for getting storyboard, we can get to end result which is more compact and also avoids having identifier strings in the code.

	extension UIStoryboard {
	class var main: UIStoryboard {
	return UIStoryboard(name: "Main", bundle: nil)
	}
	}

	let viewController = UIStoryboard.main.instantiateViewController(withType: ContactsViewController.self)

view raw Storyboard.swift hosted with ❤ by GitHub

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.

Tags Generics, instantiateViewController, NSStringFromClass, UIStoryboard

Generics iOS Swift UIKit

Navigating using flow controllers and responder chain on iOS

Post author By Toomas Vahter
Post date November 18, 2018
1 Comment on Navigating using flow controllers and responder chain on iOS

Every app consists of different flows for achieving a specific goal. For example, there is a sequence of views for sign up. When sign up flow ends, we need to move to so called main view what represents the main functionality of the app. There are definitely a lot of different ways how to handle app navigation and each of the approach have their own pros and cons. With this in mind, the approach I am going to demonstrate this time, is how to use flow controllers and using responder chain to connect flows to each other.

Navigating from flow to flow

Flow controller is a UIResponder coordinating a single flow in an app. It handles showing views, injecting dependencies and storing intermediate values required to pass from one view controller to another. Navigation from one flow to another happens using responder chain. This also enables us to use sending actions to nil first responder in story boards and xib files. Using responder chain adds extra flexibility when restructuring an app or changing flows a lot. There is only a little code needed to set up new flows. It is a kind of lightweight approach to coordinator pattern where delegation is replaced with responder chain.

Setting up protocols

As a first step we define two protocols: one for defining entry points and the second one for accessing flow controllers from any responder in responder chain. Flow controllers are going to conform to specialised presenting protocol and responders (typically view controller), which trigger navigation, conform to one of the controlling protocols. FlowPresenting protocol is going to define a single function what is used for presenting a first view in the flow. I find examples to be the best way of learning new approaches, therefore let’s build a sample app with three flows: app, login and main flow.

	protocol FlowControlling {}

	protocol FlowPresenting {
	func showInitialView()
	}

view raw FlowControlling.swift hosted with ❤ by GitHub

Controlling app flow

AppFlowController is the controller handling presenting new flows. It conforms to AppFlowPresenting protocol what defines entry points to all the different flows. In addition, it handles inserting active flow to responder chain which enables easy access to flow controller from any presented view controller. Finding a flow controller from responder chain is implemented using a generic function. This enables implementing new getters for other flow controllers with just one line.

	protocol AppFlowControlling: FlowControlling {
	var appFlowController: AppFlowPresenting { get }
	}

	protocol AppFlowPresenting: FlowPresenting {
	func showMainView()
	}

	extension AppFlowControlling where Self: UIResponder {
	var appFlowController: AppFlowPresenting {
	return flowController()
	}
	}

	extension UIResponder {
	func flowController<T>() -> T {
	var current: UIResponder? = self
	repeat {
	if let presenter = current as? T {
	return presenter
	}
	current = current?.next
	} while current != nil
	fatalError()
	}
	}

view raw AppFlowController+Protocols.swift hosted with ❤ by GitHub

In the current sample app, AppFlowController is going to handle representing all of the flows in the app. This is because all the current flows are consisting of one branch in a so called tree of flows. If we would have a more complex application, other flow controllers would handle their own subset of flows and would insert those flows into responder chain (like AppFlowController is inserting LoginFlowController and MainFlowController into responder chain). This kind of architecture allows creating a tree like structure of flows and separating them from each other – there is not going to be a single controller handling all the flows.

	final class AppFlowController: UIResponder, AppFlowPresenting {
	private let dependencyManager: DependencyManager
	private let window: UIWindow

	init(window: UIWindow, dependencyManager: DependencyManager) {
	self.dependencyManager = dependencyManager
	self.window = window
	}

	// MARK: Presenting Flows

	func showInitialView() {
	let controller = LoginFlowController(window: window)
	controller.showInitialView()
	activeFlow = controller
	}

	func showMainView() {
	let controller = MainFlowController(window: window, dependencyManager: dependencyManager)
	controller.showInitialView()
	activeFlow = controller
	}

	// MARK: Managing the Responder Chain

	var activeFlow: FlowPresenting? = nil

	override var next: UIResponder? {
	return activeFlow as? UIResponder
	}
	}

view raw AppFlowController.swift hosted with ❤ by GitHub

In the example app we do not use storyboard for initialising the first view (“Main Interface” field in target settings is empty). Instead, we set up a window ourself and use AppFlowController for presenting the first view. In addition, we inject a manager storing a set of dependencies view controllers might require. Having approach like this, we do not need singletons and instead, flow controllers insert dependencies into view controllers. Using dependency injection keeps the overall dependency graph nice and clean.

	final class AppDelegate: UIResponder, UIApplicationDelegate {
	var window: UIWindow?
	private var appFlowController: AppFlowController?
	private let dependencyManager = DependencyManager()

	func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
	let window = UIWindow(frame: UIScreen.main.bounds)
	window.rootViewController = UINavigationController()
	self.window = window
	appFlowController = AppFlowController(window: window, dependencyManager: dependencyManager)
	appFlowController?.showInitialView()
	window.makeKeyAndVisible()
	return true
	}

	override var next: UIResponder? {
	return appFlowController
	}
	}

view raw AppDelegate.swift hosted with ❤ by GitHub

Creating login flow controller

LoginFlowController has similar set up as AppFlowController with exception of not inserting a subsequent flow into responder chain. In the sample app, login flow does not branch into several other login related flows. At the end of login flow, AppFlowController is used to present main content view. Due to generic function we added to UIResponder extension, login flow controller accessor consists of a single line.

	final class LoginFlowController: UIResponder, LoginFlowPresenting {
	let window: UIWindow

	init(window: UIWindow) {
	self.window = window
	}

	func showInitialView() {
	let viewController = UIStoryboard.main.instantiateViewController(withIdentifier: "login")
	(window.rootViewController as? UINavigationController)?.setViewControllers([viewController], animated: false)
	}

	func showSignUp() {
	let viewController = SignUpViewController()
	(window.rootViewController as? UINavigationController)?.pushViewController(viewController, animated: true)
	}

	func showAccountDetails() {
	let viewController = UIStoryboard.main.instantiateViewController(withIdentifier: "accountdetails")
	(window.rootViewController as? UINavigationController)?.pushViewController(viewController, animated: true)
	}
	}

	protocol LoginFlowPresenting: FlowPresenting {
	func showAccountDetails()
	func showSignUp()
	}

	protocol LoginFlowControlling: FlowControlling {
	var loginFlowController: LoginFlowPresenting { get }
	}

	extension LoginFlowControlling where Self: UIResponder {
	var loginFlowController: LoginFlowPresenting {
	return flowController()
	}
	}

view raw LoginFlowController.swift hosted with ❤ by GitHub

Let’s see how view controllers in the login flow trigger navigation. LoginViewController conforms to LoginFlowControlling. This makes loginFlowController accessor available and we can use it for triggering navigation. It should be noted that loginFlowController accessor returns an object conforming to LoginFlowPresenting and does not explicitly declare the type of LoginFlowController. This means that LoginViewController does not know about LoginFlowController, instead, it just knows that the returned object implements methods listed in LoginFlowPresenting protocol. Less coupling makes it easier to test and restructure app in the future.
Another important point to note here is that it is so easy to add navigation capability to any other view controller. Flow controller does not need to be injected and in the end, we just need to make two changes in the whole view controller – protocol extension takes care of adding getter to the interface and triggering navigation is just a single line of code.

	final class LoginViewController: UIViewController, LoginFlowControlling {
	@IBAction func createAccount(_ sender: Any) {
	loginFlowController.showSignUp()
	}
	}

view raw LoginViewController.swift hosted with ❤ by GitHub

Navigating from login to main view

AccountDetailsViewController is the last view controller in the login flow and it should trigger navigation to the main flow. As seen in previous paragraph, triggering navigation requires only two changes. This is also the case here.

	final class AccountDetailsViewController: UIViewController, AppFlowControlling {
	@IBAction func goToFirst(_ sender: Any) {
	appFlowController.showMainView()
	}
	}

view raw AccountDetailsViewController.swift hosted with ❤ by GitHub

Summary

This time we took a look on how to use flow controllers and responder chain to easily manage navigation from one view to another. In the end we implemented a scalable architecture where adding navigation trigger points just require a few changes. Scalability comes from the fact that flows can be arranged into tree like structure and there is no requirement to have a single object managing all the flows. Moreover, we added a dependency injection capability to flow controllers which make it so much easier to test components separately and not worrying about singletons.

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.

Example Project

FlowController (GitHub) Xcode 10.1, Swift 4.2.1

References

Using Responders and the Responder Chain to Handle Events (Apple)
Generics (Swift)
Tree (data structure) (Wikipedia)

Tags app architecture, dependency injection, flow, iOS, navigation, Responder chain, Swift

Generics Swift

Singly linked list with generics in Swift

Post author By Toomas Vahter
Post date August 12, 2018
No Comments on Singly linked list with generics in Swift

In this post we will go over basic usage of generics in Swift by building a simple singly linked list.

Introduction to generics

Generic code is code where the functionality is described without using specific types. Meaning, the code can use any types what match with constraints (if there are any). It’s best to take a look on an example. See how separate functions can be replaced with a single implementation.

	// non-generic functions
	func someFunctionInt(_ values: [Int]) {}
	func someFunctionString(_ values: [String]) {}
	// generic
	func someFunction<T>(_ values: [T]) {}

	// non-generic functions
	someFunctionInt([1, 2, 3])
	someFunctionString(["a", "b", "c"])
	// generic
	someFunction([1, 2, 3])
	someFunction(["a", "b", "c"])

	// Type constraint
	func someSortFunction<T: Comparable>(_ values: [T]) -> [T] {
	return values.sorted()
	}
	let sorted = someSortFunction([3, 7, 5, 1])
	print(sorted) // [1, 3, 5, 7]

view raw SwiftGenericsExample.swift hosted with ❤ by GitHub

Generic implementation defines a placeholder for a type (in angle brackets), in those examples T was used (can be something else but it is the most common placeholder). If multiple type placeholders are needed, placeholders are separated with commas. In addition, it is possible to constrain the type, for example, requiring the type to conform to comparable protocol allowing to use comparisons in the generic function’s implementation. It’s the bare minimal knowledge required for getting started with generics. There is a lot more about it.

Singly linked list

Singly linked list is a data structure where every node knows about the next node, but not about the preceding node. The benefit of such data structure is efficiency when inserting and removing nodes. On the other hand it does not allow random access of nodes.
Defining a generic linked list is quite easy. First we need a LinkedList struct storing the first node. Node stores a value and the next node. When inserting or removing nodes from the list, next property is updated. Therefore node needs to have reference semantics for making sure all the objects are pointing at the correct next object (in value semantics new instances would be created when mutating the next property and it would break the continuity of the list).

	struct LinkedList<T> {
	final class Node<T> {
	let value: T
	init(_ value: T, next: Node<T>? = nil) {
	self.value = value
	self.next = next
	}

	var next: Node<T>? = nil
	}

	var first: Node<T>? = nil
	}

view raw SinglyLinkedList.swift hosted with ❤ by GitHub

As said before, inserting and removing nodes is just a matter of updating the next properties. Therefore when inserting a node, its next node is the current node’s next node and the current node’s next node is the inserted node.

	extension LinkedList {
	@discardableResult func insert<T>(_ node: Node<T>, after: Node<T>) -> Node<T> {
	node.next = after.next
	after.next = node
	return node
	}

	@discardableResult mutating func prepend(_ node: Node<T>) -> Node<T> {
	node.next = first
	self.first = node
	return node
	}

	@discardableResult func remove(after node: LinkedList<T>.Node<T>) -> LinkedList<T>.Node<T>? {
	let removed = node.next
	node.next = node.next?.next
	return removed
	}
	}

view raw MutatingSinglyLinkedList.swift hosted with ❤ by GitHub

And finally, using generic linked list.

	print("Populating parking lot.")
	var parkingLot = LinkedList<String>()
	parkingLot.prepend(LinkedList.Node("Car"))
	let truck = parkingLot.prepend(LinkedList.Node("Truck"))
	parkingLot.insert(LinkedList.Node("Chopper"), after: truck)
	parkingLot.forEach(body: { print($0.value) })
	print("Empty: \(parkingLot.isEmpty)")
	/*
	Populating parking lot.
	Truck
	Chopper
	Car
	Empty: false
	*/
	print("Rearranging parking lot.")
	parkingLot.remove(after: truck)
	parkingLot.forEach(body: { print($0.value) })
	/*
	Rearranging parking lot.
	Truck
	Car
	*/
	print("Populating numbers.")
	var numbers = LinkedList<Int>()
	let first = numbers.prepend(LinkedList.Node(1))
	numbers.insert(LinkedList.Node(2), after: first)
	numbers.forEach(body: { print($0.value) })
	/*
	Populating numbers.
	1
	2
	*/

view raw UsingSinglyLinkedList.swift hosted with ❤ by GitHub

Summary

In this post we took a quick look at how to write generic code and applied that knowledge on generic version of singly linked list. It should be noted that here we used only the basics of generics and for example the linked list implementation could also benefit from associated types allowing to replace Node with for example, Element.

Playground

SinglyLinkedList (GitHub)

References

Generics in Swift (Apple)
Linked lists (Wikipedia)

Tags Generics, LinkedList, Playground, Swift

Generics iOS

Making a property observable from outer scope using generic class Observable

Post author By Toomas Vahter
Post date April 8, 2018
No Comments on Making a property observable from outer scope using generic class Observable

We will look into how to make a property observable using a separate class managing the observers. It is an alternative and simple way of observing property changes without using ReactiveSwift, Key-Value Observing or anything else similar. It can be an excellent glue between Model and View Model in MVVM or between View and Presenter when using VIPER architecture.

Creating a class Observable

	final class Observable<T> {
	init(_ value: T) {
	self.value = value
	}

	var value: T {
	didSet {
	changeHandlers.forEach({ $0.handler(value) })
	}
	}

	typealias ChangeHandler = ((T) -> Void)
	private var changeHandlers: [(identifier: Int, handler: ChangeHandler)] = []

	/**
	Adds observer to the value.
	- parameter initial: The handler is run immediately with initial value.
	- parameter handler: The handler to execute when value changes.
	- returns: Identifier of the observer.
	*/
	@discardableResult func observe(initial: Bool = false, handler: @escaping ChangeHandler) -> Int {
	let identifier = UUID().uuidString.hashValue
	changeHandlers.append((identifier, handler))
	guard initial else { return identifier }
	handler(value)
	return identifier
	}

	/**
	Removes observer to the value.
	- parameter observer: The observer to remove.
	*/
	func removeObserver(_ observer: Int) {
	changeHandlers = changeHandlers.filter({ $0.identifier != observer })
	}
	}

view raw Observable.swift hosted with ❤ by GitHub

The class Observable holds a value what can be of any type. Now when the value is store by the class itself we can use Swift’s property observer and then calling change handlers. This allows creating an object with observable properties and observing those properties from other objects. Moreover, it is possible to remove any of the added observers.
Let’s take a look on an example of class “Pantry” what has a property holding array of jams. In the example we will add two observers: one reacting to changes and the other one what will also react to the initial value. When one of the observer is removed and the array of jams changes, only one of the observers is triggered.

	final class Pantry {
	let jams = Observable([Jam(flavour: .apple)])

	func add(jam: Jam) {
	jams.value.append(jam)
	}
	}

	struct Jam {
	enum Flavour: String {
	case apple, orange
	}

	let flavour: Flavour

	init(flavour: Flavour) {
	self.flavour = flavour
	}
	}

	let pantry = Pantry()
	print("Adding count and contents observers.")
	let observer = pantry.jams.observe { (jams) in
	print("Pantry now has \(jams.count) jars of jam.")
	}
	pantry.jams.observe(initial: true) { (jams) in
	let contents = jams.map({ $0.flavour.rawValue }).joined(separator: ", ")
	print("Jams in pantry: \(contents)")
	}
	print("Adding jam to pantry.")
	pantry.add(jam: Jam(flavour: .orange))

	print("Removing count observer.")
	pantry.jams.removeObserver(observer)
	print("Adding jam to pantry.")
	pantry.add(jam: Jam(flavour: .apple))

	/*
	Adding count and contents observers.
	Jams in pantry: apple
	Adding jam to pantry.
	Pantry now has 2 jars of jam.
	Jams in pantry: apple, orange
	Removing count observer.
	Adding jam to pantry.
	Jams in pantry: apple, orange, apple
	*/

view raw ObservingPantry.swift hosted with ❤ by GitHub

Today we learned how to very easily make a property observable from outer scope of the object owning the property.
Thank you for reading.

Download ObservableProperty playground.

Tags Generics, Key-value observing, Reactive, Swift