Marisi Brothers

Swift UI previews on iOS 12 and below

2020-06-05T00:00:00+00:00

This article explains how to use SwiftUI on iOS 12 or below projects. Specifically, to display previews of existing views and view controllers during development.

Preview a view controller using SwiftUI

The simplest thing to start with would be to display a view controller that represents a screen. For example, if had the following view controller:

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .lightGray
        let label = UILabel()
        label.text = "Hello world"
        label.backgroundColor = .gray

        view.addSubview(label)
        label.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            label.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            label.centerYAnchor.constraint(equalTo: view.centerYAnchor),
        ])
    }
}

We can implement UIViewControllerRepresentable to instatiate a ViewController for SwiftUI to use and then implement PreviewProvider to make Xcode render it.

import SwiftUI

// This prevents a runtime crash in case somebody initialises
// this type on a device with a version earlier than on an iOS 13
// as SwiftUI is not available
@available(iOS 13, *)
struct ViewControllerPreview: UIViewControllerRepresentable {
    func makeUIViewController(context _: Context) -> ViewController {
        return ViewController()
    }

    func updateUIViewController(_: ViewController, context _: Context) {}
}

// This is needed since the `some` keyword is only available on
// iOS 13 and above
@available(iOS 13, *)
struct ViewController_Previews: PreviewProvider {
    static var previews: some View {
        ViewControllerPreview()
    }
}

This produces the following preview, note that I’ve selected a iPhone SE (2nd generation) simulator on Xcode:

With a small snippet of code we can see how the ViewController looks without having to run the simulator and navigate to that screen.

Notes:

The project can have a deployment target of iOS 12 or below but an iOS 13 simulator needs to be selected for the preview to shoe. Xcode seems to use the selected simulator to render the preview.
To prevent runtime crashes, it is convenient to mark all SwiftUI related types with @available(iOS 13, *). This will ensure iOS does not try to load SwiftUI on an iOS 12 device.

Preview a custom `UIView` using SwiftUI

The next step is to preview a custom view, for example if we had the following:

class ContentView: UIView {
    init() {
        super.init(frame: .zero)
        setupViews()
    }

    required init?(coder _: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    private func setupViews() {
        let label = UILabel()
        label.text = "I am a ContentView"
        label.backgroundColor = .orange
        label.numberOfLines = 0
        addSubview(label)

        label.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            label.leadingAnchor.constraint(equalTo: leadingAnchor),
            label.trailingAnchor.constraint(equalTo: trailingAnchor),
            label.topAnchor.constraint(equalTo: topAnchor),
            label.bottomAnchor.constraint(equalTo: bottomAnchor),
        ])
    }
}

We would then create a preview of the ContentView by implementing UIViewRepresentable and PreviewProvider.

@available(iOS 13, *)
struct ContentViewWrapped: UIViewRepresentable {
    func makeUIView(context _: Context) -> UIView {
        return ContentView()
    }

    func updateUIView(_: UIView, context _: Context) {}
}

@available(iOS 13, *)
struct ContentViewWrapped_Previews: PreviewProvider {
    static var previews: some View {
        ContentViewWrapped()
    }
}

This results in a preview that stretches to the size of the simulator that is selected.

To constrains the view to it’s intrinsic size we would set it to fixedSize() and set the preview layout to sizeThatFits:

@available(iOS 13, *)
struct ContentViewWrappedFixed_Previews: PreviewProvider {
    static var previews: some View {
        ContentViewWrapped()
            .fixedSize()
            .previewLayout(.sizeThatFits)
    }
}

Unfortunately this does not have the intended result:

We would expect something similar to this:

Note that the above expected image was created using a Text component from SwiftUI:

@available(iOS 13, *)
struct Text_Previews: PreviewProvider {
    static var previews: some View {
        Text("I am a ContentView")
            .background(Color.orange)
            .previewLayout(.sizeThatFits)
    }
}

As of the time writing this article it does not look like SwiftUI’s UIViewRepresentable can calculate the size of a simple UIView that uses Auto Layout. Calculating the size manually and overriding intrinsicContentSize SwiftUI renders the view with that size. Therefore, using fixedSize() does not seem to work with custom views using Auto Layout. I guess we can go back to making views like we did on iOS 5 prior to the release of Auto Layout.

Hopefully, I’m either misunderstanding how SwiftUI works or this is a bug. Otherwise, if it is not possible to wrap UIView subclasses using UIViewRepresentable, it would make adopting SwiftUI on existing apps more difficult as one could not use the existing custom views with new SwiftUI code.

A way to bypass this problem is to place the custom UIView in a view controller and then preview the view controller. This is done by creating a ViewPreviewer type that implements UIViewControllerRepresentable and adding an extension to UIView to have a nicer entry point.

import SwiftUI

extension UIView {
    @available(iOS 13, *)
    func embedForPreview() -> some View {
        return ViewPreviewer(contentView: self)
    }
}

@available(iOS 13, *)
private struct ViewPreviewer: UIViewControllerRepresentable {
    let contentView: UIView

    func makeUIViewController(context _: Context) -> UIViewController {
        return ViewControllerContainer(view: contentView)
    }

    func updateUIViewController(_: UIViewController, context _: Context) {}
}

private class ViewControllerContainer: UIViewController {
    let container: UIView

    init(view: UIView) {
        container = view
        super.init(nibName: nil, bundle: nil)
    }

    required init?(coder _: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        view.addSubview(container)
        container.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            container.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            container.centerYAnchor.constraint(equalTo: view.centerYAnchor),
            container.leadingAnchor.constraint(greaterThanOrEqualTo: view.leadingAnchor),
            container.topAnchor.constraint(greaterThanOrEqualTo: view.topAnchor),
        ])
    }
}

We can then preview the ContentView view using:

@available(iOS 13, *)
struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
            .embedForPreview()
    }
}

By default the preview is shown in a simulator:

To make the preview bounding box smaller a fixed size for the preview can be provided:

@available(iOS 13, *)
struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
            .embedForPreview()
            .previewLayout(.fixed(width: 200, height: 200))
    }
}

This results on:

This is not ideal but at least it allows as to see how the view would layout on different sizes. For example, using .previewLayout(.fixed(width: 100, height: 100))

Conclusions

I find it useful to have previews of view controller using SwiftUI since this is faster that having to launch the simulator and navigate to that screen. Also, it helps with decoupling view controllers as it needs to be easy to initialise them when implementing UIViewControllerRepresentable.

Since this approach is simple and it helps with development while keeping production code the same, this is a handy trick for any codebase that uses Xcode 11.

I’d like to thank Nahuel Marisi for reviewing this article.

New home: Moving to Jekyll

2020-05-28T00:00:00+00:00

We have a new home. The blog is now generated using Jekyll and hosted on GitHub Pages. This article describes the thought process for this decision.

The blog had been hosted on Blogger since 2015. At the time it got us up and running quickly. Gradually we noticed several limitations but we stuck with it to focus on writing articles.

Reasons to leave Blogger

Hard to modify theme and layout of the blog. For example adding a link the author’s Twitter profile was a lengthy and cumbersome task.
No support for code formatting, we had to copy/paste the HTML formatter code into Blogger.
Lack of version control support, we could not use a git repository to provide content to the blog.

Reasons for choosing GitHub Pages

Low maintenance, GitHub takes all hosting responsibilities.
Free for public pages.
Git integration, an article can be pushed to the master once it’s ready to make it live.

Reasons for choosing Jekyll

Integrates with GitHub Pages. When new changes are pushed, GitHub Pages runs Jekyll to generate the HTML and deploys it.
It can run on localhost, changes to the blog can be checked locally before making them available to everybody.
Updating the layout of the site is straightforward.
Configuration is in the repository, so it can be version controlled.
Post’s metadata, such as the author, is in one place. It is defined within the post’s markdown file in the front matter.
Active open source project. The platform is likely to exist in the foreseeable future.
Many people use this tool, so there are many resources online to find answers to questions one might have.
Supports markdown files.

The downsides of Jekyll

Debugging of templates and configuration is limited. Running Jekyll locally logs some errors when something is incorrect but many times it fails silently with one wondering why something not being displayed.
Uses many conventions, such as where files should be placed so it’s not obvious what is wrong when something does not load.
Existing templates are limited and only provide a starting point. As far as I know it’s not possible to combine templates.

Decisions made during migration

Use a minimalist theme to make the blog simpler and more mobile friendly to focus on the content.
Drop features such as tag specific pages in order to release sooner. I’m confident I can rebuild any missing relevant features fairly quickly.
Drop ability to post comments since most of them were unrelated spam messages.
Remove some unrelated images on the articles to reduce noise.

Conclusion

Even though I’ve only been using Jekyll for a few days, I’ve already seen the benefits compared to Blogger when it comes to customisation. If you need more control over the layout of your blog, Jekyll is a great option.

I’d like to thank Nahuel Marisi for reviewing this article.

Workaround for serializing Codable fragments

2018-07-20T09:54:00+00:00

TL;DR - Wrap the Codable type in an array and use a JSONDecoder to convert it to Data

Serialization of data has been immensely improved by the introduction of Codable. This interface provides an api with much less boilerplate than the classic NSCoding.

Currently Swift provides decoders and encoders for 2 types of data, JSON and property list:

One of the limitations is that neither of them support single values, also known as fragments. For example:

let json = "A string".data(using: .utf8)!
do {
	try JSONDecoder().decode(String.self, from: json)
} catch {
	// Error Domain=NSCocoaErrorDomain Code=3840 "JSON text did not start
	// with array or object and option to allow fragments not set."
	// UserInfo={NSDebugDescription=JSON text did not start with array
	// or object and option to allow fragments not set.}
}

The issue related to JSON is raised on the Swift JIRA, SR-6163. The reason this happens is because JSONDecoder is implemented using JSONSerialization but it doesn’t provide an option to allow fragments which is where the error comes from.

Real life example

A popular tool for persistency in Swift is Disk. One of it’s features is the ability to save a Codable type to disk:

public extension Disk {
	static func save<T: Encodable>(_ value: T, to directory: Directory, as path: String) throws {
		// Implementation using JSONEncoder
	}
}

The library is great but it’s limited by the Swift issue, if we try to save a string it’ll fail:

try Disk.save("A string", to: .documents, as: "filename.extension") // fails

No compiler errors are given because String is Encodable but this will throw the following error:

Error Domain=NSCocoaErrorDomain Code=4866 “Top-level String encoded as string JSON fragment.” UserInfo={NSCodingPath=( ), NSDebugDescription=Top-level String encoded as string JSON fragment.}

Both the API and the documentation (Disk currently supports persistence of the following types: Codable, …) suggest this should work. However, since Disk is implemented using JSONEncoder for serialization it doesn’t.

Note that I used Disk as an example because it’s well documented, has good tests and works very nicely. The fact that I’m pointing a bug doesn’t mean it’s anything other than great.

One possible (and temporary) solution to this problem

Since Swift does not support fragments a reliable and somewhat questionable implementation is to wrap the Encodable type into an array to guarantee it’ll encode:

private extension Encodable {
	func encode() -> Data? {
		return try? JSONEncoder().encode([self])
	}
}

This serialized Data can then be stored into the disk or sent somewhere.

To retrieve the original Codable type we can revert the process. We decode the data, take the first item in the array and cast it to the corresponding type. Note that this returns a generic parameter because there is no easy way to encode the original type.

extension Data {
	func decode<T: Decodable>() -> T? {
		return (try? JSONDecoder().decode([T].self, from: self))?.first
	}
}

Going back to the original example from SR-6163, these extensions can be used like this:

let jsonPrimitive = "A string"
let encodedData = jsonPrimitive.encode()
let decodedValue: String? = encodedData?.decode() // "A string"

Conclusions

The proposed workaround is by no means elegant or space efficient but it reliably converts any Codable type to Data and back to Codable. Therefore, this is good tool to have in your toolbelt until swift provides a decoder/encoder that allows fragments as Codable provides a very convenient way of serializing objects.

I’d like to thank Nahuel Marisi, Daniel Haight and Neil Horton for reviewing this article.

Caveats of Swift default protocol extensions

2018-03-27T19:14:00+00:00

TL;DR - Think carefully whether or not you need to add a default implementation to a property defined on a protocol

Be prepared to avoid wasting a day of painful debugging caused by an obscure scenario in Swift! Swift 2 introduced the ability to add extensions to protocols, for example:

protocol SomeProtocol {
	var property: String { get }
}

extension SomeProtocol {
	var property: String {
		return "Default value"
	}
}

This is a great language feature but it introduces the potential for subtle bugs when modifying the protocol. In this post I’ll cover 2 cases: renaming a property, and changing the type of a property.

Case 1: Renaming a property defined in a protocol

Protocols can define properties to be implemented by the conforming type. For example, an http request can be modelled by the following:

enum HTTPMethod {
	case get
	case post
}


protocol HTTPRequest {
	var httpMethod: HTTPMethod { get }
}

In the majority of cases the http method used by iOS apps will be a GET request, so it’s sensible to define that all http requests default to .get:

extension HTTPRequest {
	var httpMethod: HTTPMethod {
		return .get
	}
}

A POST http request could be defined like this:

struct ExampleHTTPRequest: HTTPRequest {
	var httpMethod: HTTPMethod = .post
}

An HTTPClient can then make http requests using the httpMethod defined in the HTTPRequest protocol:

struct HTTPClient {
	func make(httpRequest: HTTPRequest) {
		// some implementation using the http method
	}
}

let client = HTTPClient()
client.make(httpRequest: ExampleHTTPRequest()) -> uses a POST

Imagine that some time later the httpMethod gets renamed to method:

protocol HTTPRequest {
	var method: HTTPMethod { get }
}

extension HTTPRequest {
	var method: HTTPMethod {
		return .get
	}
}

After this change, when the http client makes the HTTPRequest for the original ExampleHTTPRequest the HTTPMethod is now get because it is using the default implementation of HTTPRequest defined in it’s extension:

let client = HTTPClient()
client.make(httpRequest: ExampleHTTPRequest()) -> uses a GET!

Note that the ExampleHTTPRequest didn’t change but the behaviour when used in the HTTPClient is different. The ExampleHTTPRequest still defines var httpMethod: HTTPMethod = .post making it hard and confusing to debug.

Case 2: Changing the type of a property defined in a protocol

In this second case instead of renaming the property we’ll change the type. Let’s start by telling the story of JohnDoe and JaneDoe, 2 devoted athletes. The first thing they learnt as a Person was to Walk:

protocol Walking {}

protocol Person {
	var moveAction: Walking? { get }
}

struct Walk: Walking {}

Since not every Person can walk, the moveAction is optional with a nil default:

extension Person {
	var moveAction: Walking? {
		return nil
	}
}

Once JohnDoe and JaneDoe learned how to Walk they looked like this:

struct JohnDoe: Person {
	var moveAction: Walking? = Walk()
}

struct JaneDoe: Person {
	var moveAction: Walking? = Walk()
}

After learning how to Walk they figured it was time to have a Race:

struct Race {
	var people: [Person]

	func start() {
		people.forEach { person in
			// use person's moveAction
		}
	}
}

let firstRace = Race(people: [JohnDoe(), JaneDoe()])
firstRace.start()

Both of them managed to Walk in this Race:

firstRace.people[0].moveAction // returns Walk
firstRace.people[1].moveAction // returns Walk

After JohnDoe won the Race by a great distance, the next step was to learn how to run:

protocol Running {}

A Person could now run:

protocol Person {
	var moveAction: Running? { get }
}

extension Person {
	var moveAction: Running? {
		return nil
	}
}

Lazy JohnDoe was confident that his Walk was good enough to win the next Race and didn’t learn how to Run. However, JaneDoe who was much more clever than JohnDoe (and knew a thing or two about Swift) updated her moveAction to include Running so she could Run:

struct JaneDoe: Person {
	var moveAction: Running? = Run()
}

The 2nd Race was on! The whistle went and the race started:

let secondRace = Race(people: [JohnDoe(), JaneDoe()])
secondRace.start()

To JohnDoes surprise he had suddenly forgotten how to Walk as a Person whereas JaneDoe Run like the wind:

secondRace.people[0].moveAction // returns nil for JohnDoe
secondRace.people[1].moveAction // returns Run for JaneDoe

JohnDoe couldn’t move and lost the race without knowing what hit him. There wasn’t even a compiler error/warning to tell him what happened. Some people have gone as far as saying he couldn’t take the pressure and choked…

However, a careful inspection of the Swift code tells us that poor JohnDoe was stripped of his ability to Walk as a Person when the Person protocol’s moveAction was modified to Running. This is due to the fact that our default extension is now returning nil for JohnDoe when he is considered a Person. When accessing a property the reference type of the variable matters. When the instance of JohnDoe is considered a Person, the moveAction property from the Person default extension is used, i.e. Running?. Whereas when the instance is refered as JohnDoe the property used is the one defined by JohnDoe, i.e. Walking?:

(secondRace.people[0] as Person).moveAction // returns nil
(secondRace.people[0] as! JohnDoe).moveAction // returns Walk

The type for moveAction defined by JohnDoe is Walking? compared to Running? for Person. This subtle changes means JohnDoe no longer can Walk as Person

Conclusions

If you’re thinking that deprecating the old property is the way to go, it does not work. Deprecations don’t have any effect whatsoever on the conforming type as that type can define it’s own properties overriding the protocol ones:

protocol ExampleProtocol {
	@available(*, deprecated, renamed: "newProperty")
	var oldProperty: String { get }

	var newProperty: String { get }
}

extension ExampleProtocol {
	@available(*, deprecated, renamed: "newProperty")
	var oldProperty: String {
		return "Default value"
	}

	var newProperty: String {
		return "Default value"
	}
}

The following ExampleStruct has no warning or errors:

struct ExampleStruct: ExampleProtocol {
	var oldProperty: String
}

Neither changing it’s type produces an error/warning:

struct ExampleStruct: ExampleProtocol {
	var oldProperty: Int
}

Therefore, I suggest that you think carefully when adding default implementations in extensions. If you absolutely must change a property that has default defined I suggest 2 approaches:

Have complete confidence that you can propagate the change to every consuming type of your protocol
Remove the default implementation to force all consumers to implement it

This is specially important when modifying public interfaces since it’s likely that you’ll have no visibility of the projects that make use of that protocol. All in all, these solutions are not great and it’s probably best to avoid having public extensions adding defaults altogether.

I’d like to thank Nahuel Marisi, Daniel Haight and Neil Horton for reviewing this article.

Using Swift 4’s Codable protocol to configure your UI test environment

2017-11-26T21:36:00+00:00

TL;DR - Take advantage of the new Swift 4 Codable protocol to encode the launch environment of your UI tests

Native UI testing in iOS does not allow direct interaction from the UI test to the app target. In other words, the test code cannot change the state of the app code while it is running.

XCUITests allow for information to be sent to the app by either the launchArguments: [String] or the launchEnvironment: [String : String]. These 2 properties can be read from the ProcessInfo. Historically, I’ve used the launchEnvironment to send specific flags, for example ["UITest-has-completed-onboarding": "true"]. However, this can get messy as more options are required and a lot of code is needed to be able to send more complex data.

The introduction of Codable in Swift 4 provides a much simpler approach for this kind of communication. In essence, a type that represents the launch environment can be encoded and decoded with very little effort thanks to Codable.

The example

Define a UITestEnvironment type that conforms to Codable with any relevant data for your UI test environment. For example:

Note: This type has to be included in both the app target and the test target.

struct UITestEnvironment: Codable {

	static let Key = "UITestEnvironmentKey"

	let hasCompletedOnboarding: Bool

	// Any other keys or data you'd like
}

Add a function to encode an Encodable type into a base64 JSON string to your test target:

extension Encodable {
	func base64EncodedJSONString() -> String? {
		guard let encodedData = try? JSONEncoder().encode(self) else { return nil }
		return encodedData.base64EncodedString()
	}
}

Add a function to decode a Decodable type from a base64 JSON string to your app target:

extension Decodable {
	static func decode(from base64EncodedJSONString: String) -> Self? {
		guard let jsonData = Data(base64Encoded: base64EncodedJSONString) else { return nil }
		return try? JSONDecoder().decode(self, from: jsonData)
	}
}

On your UI tests create the environment you need for that test, encode it and pass to the launchEnvironment:

let originalArguments = UITestEnvironment(hasCompletedOnboarding: true)
let encodedArguments = originalArguments.base64EncodedJSONString()!

let app = XCUIApplication()
app.launchEnvironment = [UITestEnvironment.Key: encodedArguments]
app.launch()

Read the launch environment from ProcessInfo and decode the data into UITestEnvironment on the app target where it is relevant to alter the state of the running app:

if let encodedEnvironment = ProcessInfo.processInfo.environment[UITestEnvironment.Key],
	let decodedEnvironment = UITestEnvironment.decode(from: encodedEnvironment) {
	// Do something with the test environment
}

That’s it! This is a very simple way to transmit information between your UI tests and your app. Since the only requirement for a UI test environment is that it conforms to Codable you may have multiple types for different tests instead of one UITestEnvironment.

I’d like to thank Nahuel Marisi for reviewing this article.

2 years later

2017-10-03T15:00:00+00:00

Today marks the second anniversary of marisibrothers.com, a blog by my brother and myself. I’ve learned a lot from reading blogposts, so creating a blog to share knowledge in this format made sense.

We chose Blogger to host it with Google Analytics because it was easy to get started. I’ve found Blogger is ok to begin with, the main difficultly is changing the layout of the blog. All the blog urls point to our own domain and we write our posts in markdown, meaning we could easily migrate to another provider should we wish to.

Originally, we started doing one post every week, alternating between my brother and myself. However, we found it hard to keep both the pace and the quality of the content. We now aim for one post a month.

We work in software development, so the content has been around this with a focus on iOS. Some posts have been specific, others high-level and one has become an open source library.

A few stats as of today (3rd October 2017):

20 posts by Luciano
12 posts by Nahuel
The most popular post has 11,000+ views, interestingly Swift 3.2 made it’s content obsolete

Finally, I’d like to thank the following people for being kind enough to review my posts over the years (alphabetically ordered):

It took years to start a blog but I’m happy we did. I encourage you to write about anything you find interesting.

Learning a new programming language today

2017-09-20T19:20:00+00:00

TL;DR - Understand the core concepts of a language and then alternate between learning details and putting them into practice

A language is a means to an end. Quickly picking up programming languages allows developers to build anything. I’ve recently been learning Java to contribute to a Spring backend. I’ve found that once the foundations of the language have been learned, a great way of learning is to develop a process of cycling through learning details, then putting them into practice.

Getting started - Understand core principles

The first thing to do is understand the core concepts of the language and the main use cases. If you can, get an experienced engineer to mentor you. This way you’ll cover the mundane setup stuff and be running code in no time. Spend about a day or two here, enough time to know everything to get you started but not too much that you end up bored and lose motivation.

Ask yourself the following questions:

What tools do developers generally use and why?
- A good starting point is to ask what’s the most appropriate text editor / IDE to use.
- Understand why developers use these tools and what others exist but they don’t use. Remember that if all you have is a hammer, everything looks like a nail.
What’s the type system?
- Is it static or dynamic?
- Is it strongly or weakly typed?
What’s the programming paradigm?
- Is it object-oriented, functional, etc?
- Is it limited to a specific paradigm or does it support numerous? It’s common for a language to support multiple paradigms
Is it compiled or interpreted?
- Sometimes the division is not so clear, see Just-in-time compilation and Bytecode compilation

Most of the above high-level questions don’t have an absolute answer which is why exploring these questions and answers is key. This will allow you to establish strong foundations, on which to learn the details.

Learn the details

At this point you’ll hopefully have some vague idea of what the language does and how to execute some code. So now it’s time to get to grips with how to write it.

Learn some syntax, for example:
- How are variables and functions declared?
- What are the available control flows? e.g. if statements, for loops
- What are the core data structures and how do you create them? (e.g. arrays and dictionaries)
What kind of features does it have? For example:
- Does it have reference and value types? And how are they used?
- Can you define interfaces/protocols?
- How do you write concurrent code?
- If it’s strongly typed, does it have generics?
What’s available in the language’s standard library?
What are the main conventions people follow?
- Check a code style guide, for example
- Do developers rely on 3rd party libraries? If so what the most common ones? For example, I’ve found that modern Java codebases use RxJava

Dive in head first

Theory is great, but we learn much more through experience. Nobody learns how to ride a bike by reading a book about it. Try out one of the following in order to gain experience:

Contribute to an existing project at your workplace, pair with another developer if you can.
- I’ve found that going into an established codebase where good practices are followed has been awesome. It’ll be easier to add new small features by extending existing code or by following existing patterns.
- Code reviews by other developers will help point out issues quickly.
Contribute to an existing open source project. It’s common for projects to mark issues that outsiders can pick up, this is a great place to start.
Create your own project. Find something you’re keen on creating and build it with the language you’re learning.

Lastly, stay out of your comfort zone and push yourself to constantly learn.

I’d like to thank Emily Woods for reviewing this article.

Lazy collections

2017-05-16T12:35:00+00:00

TL;DR - The lazy evaluation of collections can improve the performance of your app when working with large collections.

Swift introduced the posibility of lazy evaluation in our code. While many people seem to be aware of lazy variables, I find fewer users of lazy collections. In this brief article, we’ll look at how we can use lazy evaluation with collections, which can bring performance benefits when dealing with particularly large collections.

Lazy map

Let’s have a look at what happens when we ran map on a standard array.

let array = Array<Int>(0..<1000)
let mappedArray = array.map { (value: Int) -> Int in
    print("incrementing: \(value)")
    return value + 1
}

print("First element mapped: \(mappedArray[5])")

In here, map will apply our closure to every single element of the array, even though we’re only interested in the fifth one. If you run this code in the Playground, the output should be something like:

incrementing: 0
incrementing: 1
incrementing: 2
incrementing: 3
incrementing: 4
    ...
incrementing: 999
First element mapped: 6   

The larger the array is, and the more computationally intensive your closure is, the more pointless work you end up doing if you’re not interested in all of the element of this array.

Using a lazy collection

Every collection provides the lazy property that gives us a “view” into this collection, that lazily provides higher order operations like map and filter. The actual type of the lazy property is LazyMapRandomAccessCollection. Let’s go back to our original example, but use lazy instead this time:

let array = Array<Int>(0..<1000)
let mappedArray = array.lazy.map { (value: Int) -> Int in
    print("incrementing: \(value)")
    return value + 1
}

print("First element mapped: \(mappedArray[5])")

Output:

incrementing: 5
First element mapped: 6

This time, map is only applied to the element we’re interested (fifth), saving us a favolous amount of pointless work.

Filter

Just as you can use map with lazy collections, you can also use filter. Let’s have a look at a quick example:

let array = Array<Int>(0..<1000)
let filteredArray = array.lazy.filter {
    print("filtering: \($0)")
    return $0 < 10
}

print("first filtered result: \(filteredArray.first!)")

Output:

filtering: 0
first filtered result: 0

As we see, filtering only runs once (for the first result), instead of the 1000 times it would run if we were not using a lazy collection. It’s worth noting that filter returns LazyFilterBidirectionalCollection, which unlike its random access counterpart, does not accept an integer as a subscript.

Prefix

A lazy filter can easily be combined with the prefix function to limit the number of results filter returns. It’s often the case that we’re only interested in the first occurence of an object in a collection. By using evaluation and prefix we can stop as soon as we find the first occurence. Without using a lazy collection, filter would still go through the whole collection.

let array = ["green", "blue", "red", "orange", "green", " purple", "red"]
let filteredSequence: AnySequence = array.lazy.filter {
    print("filtering: \($0)")
    return ($0 == "red")
}.prefix(1)

print(Array(filteredSequence))

Output:

filtering: green
filtering: blue
filtering: red
["red"]

Note here that we’re making sure that our collection is evaluated as a sequence. There are two prefix version. The collection one which returns a BiDirectionalSlice and the sequence one which returns AnySequence. Only the sequence version evaluates lazy, while the collection one will iterate through the whole collection. The drawback of using a sequence is that we lose the use of subscripts.

Memory leak in Swift: Assigning a function to a closure

2017-04-03T17:59:00+00:00

TL;DR - Assigning a function to closure property creates a strong reference to the owner of the function potentially creating a retain cycle

Swift has first class functions, meaning that a function is treated like any other object, i.e. it’s possible to:

Pass a function as an argument into another function
Return a function as a value from a another function
Assign a function to a variable
Store functions in data structures

I have found one caveat related to this. Let’s say you have a view that has a closure property that gets called when a button is pressed.

class View {
	var onButtonPressed: (()-> Void)?
}

This View is owned by a ViewController and it handles the button being pressed by assigning it’s handleButtonAction function to the onButtonPressed closure property of the View.

class ViewController: UIViewController {
	let customView = View()
	
	init() {
		super.init(nibName: nil, bundle: nil)
		customView.onButtonPressed = handleButtonAction
	}
	
	required init?(coder aDecoder: NSCoder) { fatalError() }
	
	func handleButtonAction() { /* some implementation */ }
}

Since Swift allows for functions to be assigned to closures I thought that customView.onButtonPressed = handleButtonAction was an elegant way of linking the implementation of the handler, defined in it’s own function, to the button action. However, this seemingly harmless code will create a retain cycle. Thanks to Xcode 8 memory debugger it’s easy to visualise this:

This happens because when the handleButtonAction function is assigned to the onButtonPressed closure self is implicitly captured since self is the owner of handleButtonAction. The strong reference to self from the handleButtonAction function is indicated by the blue arrow.

Unit testing the retain cycle

While finding a solution to break this cycle it’s good to have a unit test that proves this. The following test will fail if the ViewController has a retain cycle:

func testViewControllerNotRetained() {
	// Create two variables for the view controller,
	// one strong and one weak
	var sut: ViewController? = ViewController()
	weak var weakSut = sut
	
	// Nilling out the strong reference should release the object,
	// making the weak reference also nil
	sut = nil
	XCTAssertNil(weakSut)
}

Breaking the cycle

A solution to this problem can be to assign a new block that captures self weakly and call the function inside it using the weak self:

view.onButtonPressed = { [weak self] in
	self?.handleButtonAction()
}

In this case we can go for unowned since the View will not exist beyond the lifecycle of the ViewController:

view.onButtonPressed = { [unowned self] in
	self.handleButtonAction()
}

This solution is certainly less elegant than the original direct assignment. This is why it’s so easy to forget that assigning a function retains the owner of that function potentially creating a retain cycle.

I’d like to thank Nahuel Marisi and Neil Horton for reviewing this article.

Common unit testing techniques on iOS

2017-03-13T19:40:00+00:00

TL;DR - Most if not all unit test cases on iOS can follow the same commonly known pattern: GIVEN a set of initial conditions, WHEN something happens, THEN something is expected.

Note: Code snippets are written in Swift 3 using XCTest assertions

Preamble: Key definitions

The structure of a unit test almost always follows this pattern:

Given a set of initial conditions
- When something happens
- Then something is expected

The object being tested is generally referred as the system under test (SUT). Objects that interact with the SUT and are needed to be able to write a unit test are called test doubles. I’ll use the term mock instead of test double since it’s more commonly used even though technically it’s not correct. Swift does not have mocking frameworks because reflection is limited and for pure swift objects it’s not possible to change the implementation of methods. Therefore, in Swift we need to implement our mocks manually. A real object can be substituted by a mock using dependency injection.

Typical kind of unit tests

Unit testing in iOS has come a long way since the iOS SDK was released in 2008. It’s no longer rare to see iOS developers unit testing the majority of the code they write. The following are some of the most common cases for unit tests:

Assert a method returns an expected value given:
- An input
- The state of a dependency
Assert properties instantiated depending on parameters
Assert a method in a mock gets called
Assert that calling a method in the SUT has a side effect in:
- The SUT
- A mock
Assert that a change in a (mocked) dependency has a side effect in the SUT

Unit Test Examples

1a. Assert a method returns an expected value given an input:

A method that returns the element in a array if it exists could look something like this:

extension Array {
	subscript (safe index: Int) -> Element? {
		return indices ~= index ? self[index] : nil
	}
}

The unit tests for this method can be done by treating the SUT as a black box. The following test class shows how three test cases can be written to test the behaviour of the safe index function. The code is intentionally verbose to demonstrate the example better.

class ArrayTests: XCTestCase {

	func testIndexWithinBoundsReturnsElement() {
		// GIVEN
		let sut = [1, 2, 3]
		
		// WHEN
		let itemAtIndex = sut[safe: 1]
		
		// THEN
		XCTAssertEqual(itemAtIndex, 2)
	}
	
	func testNegativeIndexReturnsNil() {
		let sut = [1, 2, 3]
		let itemAtIndex = sut[safe: -1]
		XCTAssertNil(itemAtIndex)
	}
	
	func testOutOfboundsIndexReturnsNil() {
		let sut = [1, 2, 3]
		let itemAtIndex = sut[safe: 3]
		XCTAssertNil(itemAtIndex)
	}
}

1b. Assert a method returns an expected value given the state of a dependency

The business logic for deciding whether to show an alert to the user requesting for location permissions could be implemented like this:

struct OnboardingState_Untestable {
	func shouldShowEnableLocationAlert() -> Bool {
		guard CLLocationManager.locationServicesEnabled() else { return true }
		return false
	}
}

The problem of this implementation is that the shouldShowEnableLocationAlert method uses CLLocationManager internally to return it’s output. Therefore, to test this method we need mock and inject this dependency. Defining a protocol that CLLocationManager can automatically conform to:

protocol LocationManagerType: class {
	static func locationServicesEnabled() -> Bool
}
extension CLLocationManager: LocationManagerType {}

Modifying shouldShowEnableLocationAlert to pass the LocationManagerType type as a parameter defaulting to the CLLocationManager will allow to mock the dependency in a unit test. Note that this does not affect how this method is used in production. This kind of dependency injection is called Interface injection and in this case we are injecting a type as opposed to an instance because the CLLocationManager method we need to mock is a class function. The updated OnboardingState would be:

struct OnboardingState {
	func shouldShowEnableLocationAlert(locationManager: LocationManagerType.Type = CLLocationManager.self) -> Bool {
		guard locationManager.locationServicesEnabled() else { return true }
		return false
	}
}

Mocking a class function as opposed to an instance function is generally messier because classes are singletons. There is only one class definition per instance of a program. Hence, the mocked state needs to be global. Using protocol conformance we can mock the CLLocationManager:

class MockedLocationManager: LocationManagerType {
	static var mockedLocationServicesEnabled = true
	static func locationServicesEnabled() -> Bool {
		return mockedLocationServicesEnabled
	}
}

A subclass of XCTestCase can override the setUp and tearDown methods. These functions get called before and after each test. It’s common to initialise the SUT on setUp but not necessary. It’s good practice to implement the tearDown method to deinitialise your SUT and mocks, specially the reference type ones. Otherwise, these objects will continue to exists while other tests run potentially interfering with them. This post explains possible issues in more detail. The 2 test cases for the OnboardingState can be:

class OnboardingStateTests: XCTestCase {
	
	var sut: OnboardingState!
	
	override func setUp() {
		super.setUp()
		// GIVEN
		sut = OnboardingState()
	}
	
	override func tearDown() {
		sut = nil
		super.tearDown()
	}
	
	func test_shouldShowEnableLocationAlert_returnsTrue_when_locationServicesAreDisabled() {
		// WHEN
		MockedLocationManager.mockedLocationServicesEnabled = false

		// THEN
		XCTAssert(sut.shouldShowEnableLocationAlert(locationManager: MockedLocationManager.self))
	}
	
	func test_shouldShowEnableLocationAlert_returnsFalse_when_locationServicesAreEnabled() {
		MockedLocationManager.mockedLocationServicesEnabled = true
		XCTAssertFalse(sut.shouldShowEnableLocationAlert(locationManager: MockedLocationManager.self))
	}
}

2. Assert properties instantiated depending on parameters

Let’s say that a person is represent by the following struct and the JSON parsing is implemented in a similar way as Apple explains.

struct Person {
	let name: String
	let age: Int
}

extension Person {
	init?(dictionary: [String: Any]) {
		guard let name = dictionary["name"] as? String,
			  let age = dictionary["age"] as? Int else {
				return nil
		}
		self.name = name
		self.age = age
	}
}

One of the tests would be to assert that for a given valid dictionary a valid Person is created. Personally, I don’t mind having more than one assertion in a test if they are related. For example, the following test asserts both the name and age properties:

class PersonTests: XCTestCase {

	func test_allPropertiesAreSetCorrectlyForAValidDictionary() {
		// GIVEN
		let validDictionary: [String: Any] = ["name": "John Doe", "age": 35 ]
		
		// WHEN
		let sut = Person(dictionary: validDictionary)
		
		// THEN
		XCTAssertEqual(sut?.name, "John Doe")
		XCTAssertEqual(sut?.age, 35)
	}
}

3. Assert a method in a mock gets called

Commonly we need to download images from a URL, for example when displaying them in a UITableView. This task can be done by the following ImageFetcher which uses an OperationQueue and adds some kind of image operation that takes a URL and performs a network request to retrieve it. If we pop this screen we probably want to cancel all current image operations as they are no longer relevant. To do this we call the cancelAllOperations method on the queue.

class ImageFetcher {
	
	private let operationQueue: OperationQueue
	init(operationQueue: OperationQueue = OperationQueue()) {
		self.operationQueue = operationQueue
	}
	
	func fetch(imageURL: URL, completion: (UIImage?) -> Void) {
		// some implementation adding an image operation to the queue
	}
	
	func cancelFetchingAllImages() {
		operationQueue.cancelAllOperations()
	}
}

To be able to test this we pass the OperationQueue in the initialiser, this is know as Constructor injection. Using inheritance we can mock the OperationQueue and count the number of times cancelAllOperations is called. In our test case we can assert that cancelAllOperations gets called exactly once when cancelFetchingAllImages is called.

class MockOperationQueue: OperationQueue {
	var cancelAllOperationsCountCallCount = 0
	override func cancelAllOperations() {
	 	// In this case super is called to avoid having
	 	// side effects that are not true
		super.cancelAllOperations()
		cancelAllOperationsCountCallCount += 1
	}
}

class ImageFetcherTests: XCTestCase {
	
	var sut: ImageFetcher!
	var mockOperationQueue: MockOperationQueue!
	
	override func setUp() {
		super.setUp()
		// GIVEN
		mockOperationQueue = MockOperationQueue()
		sut = ImageFetcher(operationQueue: mockOperationQueue)
	}
	
	override func tearDown() {
		mockOperationQueue = nil
		sut = nil
		super.tearDown()
	}
	
	func test_cancelFetchingAllImages_calls_cancelAllOperations() {
		// WHEN
		sut.cancelFetchingAllImages()

		// THEN
		XCTAssertEqual(mockOperationQueue.cancelAllOperationsCountCallCount, 1)
	}
}

4a. Assert that calling a method in the SUT has a side effect in the SUT

Note: The code in this example is for illustrative purposes as some implementations are missing.

A very common pattern in iOS is to have a model object such as the previously defined Person and use it setup a custom view. For example:

struct Model { /* some properties */ }

class View: UIView {
	func configure(with model: Model) { /* configure the view */ }
}

This kind of example is best tested using screenshot testing instead of asserting each and every property that would be changed in the View by the Model. The test is simpler to write and if the View’s implementation changed the differences could be seen clearly by inspecting the before and after screenshots of the view. This can be done using FBSnapshotTestCase, for example one test case for a Model with predefined properties:

class ViewTests: FBSnapshotTestCase {
	
	var sut: View!
	
	override func setUp() {
		super.setUp()
		sut = View()
	}
	
	override func tearDown() {
		sut = nil
		super.tearDown()
	}
	
	func test_ViewWithModel() {
		// GIVEN
		let model = Model( /* initialisation with mocked parameter*/ )
		
		// WHEN
		sut.configure(with: model)
		
		// THEN
		FBSnapshotVerifyView(sut)
	}
}

4b. Assert that calling a method in the SUT has a side effect in a mock.

Assuming we have a view controller with a table view displaying a list of strings. When a cell is tapped the view controller notifies it’s delegate about this and passes the item selected. The code looks something like this:

protocol SelectionViewControllerDelegate: class {
	func didSelect(_ selectionViewController: SelectionViewController, item: String)
}

class SelectionViewController: UIViewController, UITableViewDelegate {
	
	private weak var delegate: SelectionViewControllerDelegate?
	private let items: [String]
	
	init(items: [String], delegate: SelectionViewControllerDelegate) {
		self.items = items
		self.delegate = delegate
		super.init(nibName: nil, bundle: nil)
	}
	
	func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
		let item = items[indexPath.row]
		delegate?.didSelect(self, item: item)
	}
	
	required init?(coder aDecoder: NSCoder) { fatalError() }
}

To test the delegate pattern communication, the SelectionViewControllerDelegate can be mocked by creating an object that conforms to it and storing the item. The MockSelectionViewControllerDelegate can be injected using constructor injection. The capturedItem can then be used in a test case to assert that selecting a row in the tableView calls the delegate method with the correct item:

class MockSelectionViewControllerDelegate: SelectionViewControllerDelegate  {
	var capturedItem: String?
	func didSelect(_ selectionViewController: SelectionViewController, item: String) {
		capturedItem = item
	}
}

class SelectionViewControllerTests: XCTestCase {
	
	var sut: SelectionViewController!
	var mockDelegate: MockSelectionViewControllerDelegate!
	
	override func setUp() {
		super.setUp()
		mockDelegate =  MockSelectionViewControllerDelegate()
	}
	
	override func tearDown() {
		mockDelegate = nil
		sut = nil
		super.tearDown()
	}
	
	func test_tableViewDidSelectRowtAtIndexPath_calls_delegateWithSelectedItem() {
		// GIVEN
		let mockItems = ["a", "b", "c"]
		sut = SelectionViewController(items: mockItems, delegate: mockDelegate)

		// WHEN
		sut.tableView(UITableView(), didSelectRowAt: IndexPath(row: 1, section: 0))
		
		// THEN
		XCTAssertEqual(mockDelegate.capturedItem, "b")
	}
}

5. Assert that a change in a (mocked) dependency has a side effect in the SUT

An object used to fetch data from a URL that used the shared URLSession would look something like this:

enum Result<T> {
	case success(T)
	case failure(Error?)
}

class HTTPClient_Untestable {
	func fetchData(forURL url: URL, completion: @escaping (Result<Data>) -> Void) {
		// Use URLSession.shared to make a network request
	}
}

This object is not testable because it uses an internal dependency that cannot be accessed. Therefore, to extract the URLSesssion out we first declare a protocol that URLSession can conform to:

protocol URLSessionType {
	func dataTask(with request: URLRequest, completionHandler: @escaping (Data?, URLResponse?, Error?) -> Void) -> URLSessionDataTask
}
extension URLSession: URLSessionType {}

The updated HTTPClient now takes in a URLSessionType in the initialiser and the fetchData method uses this injected session object.

class HTTPClient {
	
	private let session: URLSessionType
	init(session: URLSessionType = URLSession.shared) {
		self.session = session
	}
	
	func fetchData(forURL url: URL, completion: @escaping (Result<Data>) -> Void) {
		let request = URLRequest(url: url)
		let task = session.dataTask(with: request) { (data, _, error) in
			guard let data = data else {
				completion(Result.failure(error))
				return
			}
			completion(Result.success(data))
		}
		task.resume()
	}
}

To test this, we mock the URLSessionDataTask because it’s an abstract class so resume needs to be overridden otherwise an exception would be thrown. Then we create a mock that conforms to URLSessionType. This mock stores the completion handler sent from the SUT.

class MockURLSessionDataTask: URLSessionDataTask {
	override func resume() {}
}

class MockURLSession: URLSessionType {
	var capturedCompletion: ((Data?, URLResponse?, Error?) -> Void)?
	func dataTask(with request: URLRequest, completionHandler: @escaping (Data?, URLResponse?, Error?) -> Void) -> URLSessionDataTask {
		capturedCompletion = completionHandler
		return MockURLSessionDataTask()
	}
}

This last test case uses XCTestExpectation because the fetchData function calls a completion handler asynchronously. Unfortunately, this means that the THEN part of the test partly needs to be defined before the WHEN. Note that we call the stored completion handler on the WHEN part to simulate a successful response from the session.

class HTTPClientTests: XCTestCase {
	
	var mockURLSession: MockURLSession!
	var sut: HTTPClient!
	
	override func setUp() {
		super.setUp()
		mockURLSession = MockURLSession()
		sut = HTTPClient(session: mockURLSession)
	}
	
	override func tearDown() {
		mockURLSession = nil
		sut = nil
		super.tearDown()
	}
	
	func test_fetchData_calls_completionWithSuccessResult_whenDataIsReturnedFromSession() {
		// GIVEN
		let mockURL = URL(string: "www.test.com")!
		let expectation = self.expectation(description: #function)
		sut.fetchData(forURL: mockURL) { result in
			// THEN (Partly defined before WHEN because of asynchronous nature of test)
			switch result {
			case .success(let data):
				XCTAssertEqual(data, Data())
			case .failure(let error):
				XCTFail("Unexpected failure with error: \(error)")
			}
			expectation.fulfill()
		}
		
		// WHEN
		mockURLSession.capturedCompletion?(Data(), nil, nil)
		
		// THEN (continued)
		waitForExpectations(timeout: 1, handler: nil)
	}
}

I’d like to thank Nahuel Marisi and Neil Horton for reviewing this article.

Marisi Brothers

Swift UI previews on iOS 12 and below

Preview a view controller using SwiftUI

Preview a custom UIView using SwiftUI

Conclusions

New home: Moving to Jekyll

Reasons to leave Blogger

Reasons for choosing GitHub Pages

Reasons for choosing Jekyll

The downsides of Jekyll

Decisions made during migration

Conclusion

Workaround for serializing Codable fragments

Real life example

One possible (and temporary) solution to this problem

Conclusions

Caveats of Swift default protocol extensions

Case 1: Renaming a property defined in a protocol

Case 2: Changing the type of a property defined in a protocol

Conclusions

Using Swift 4’s Codable protocol to configure your UI test environment

The example

2 years later

Learning a new programming language today

Getting started - Understand core principles

Learn the details

Dive in head first

Lazy collections

Lazy map

Using a lazy collection

Filter

Prefix

Memory leak in Swift: Assigning a function to a closure

Unit testing the retain cycle

Breaking the cycle

Common unit testing techniques on iOS

Preamble: Key definitions

Typical kind of unit tests

Unit Test Examples

1a. Assert a method returns an expected value given an input:

1b. Assert a method returns an expected value given the state of a dependency

2. Assert properties instantiated depending on parameters

3. Assert a method in a mock gets called

4a. Assert that calling a method in the SUT has a side effect in the SUT

4b. Assert that calling a method in the SUT has a side effect in a mock.

5. Assert that a change in a (mocked) dependency has a side effect in the SUT

Preview a custom `UIView` using SwiftUI