Context

A lot of the time in Swift we will use enums to define bits of state within an app. The beauty of enums is that they represent a complete set of possible options. As such, when switching on an enum we can guarantee that every possible option is accounted for.

One issue I see occasionally is abusing the default case. Consider the following example:

enum Style {
    case small
    case big
}

func size(for style: Style) -> CGFloat {
    switch style {
    case .small:
        8
    default:
        16
    }
}

On the surface this seems perfectly reasonable, but imagine a new developer is tasked with adding a third style - medium. Unless that dev already knows about the size(for:) function, the app will start behaving incorrectly… silently…

enum Style {
    case small
    case medium
    case big
}

func size(for style: Style) -> CGFloat {
    switch style {
    case .small:
        8
    default: // Uh oh!
        16
    }
}

The solution to this particular example is simple. If we explicitly list all the enum cases, when medium is added, the compiler will prompt let us know that the switch must be exhaustive and that we’ve not handled medium.

enum Style {
    case small
    case medium
    case big
}

func size(for style: Style) -> CGFloat {
    switch style {
    case .small:
        8
    case .medium: 
        12
    case .big:
        16
    }
}

Conclusion

Obviously the example presented is contrived but the concept is worth applying whenever you are about to use a default case.

The power of enums is in their completeness, so don’t throw that away with a default case unless you’re sure that’s what you want!

And as a rule of thumb:

Never lay traps for future devs

When structs are better than protocols for dependency inversion

When we think of dependency inversion in Swift, protocols are usually the first thing that come to mind. The well known pattern is to create a protocol that defines some required behaviour and create a concrete implementation that performs that responsibility.

This becomes invaluable when testing our code as we can substitute dependencies for mocked versions which can be primed with desired responses and queried for expected outcomes.

Whilst this pattern is perfectly adequate in most instances, structs can often provide advantages that protocols can not.

Where protocols fall down…

Name-spacing

Once major disadvantage of protocols is that they cannot nest other types. Imagine the following snippet:

If we tried to define a protocol for our House, we would also need to define a protocol for the Inhabitant too, like so:

Annoying, the Inhabiting protocol cannot be nested inside Housing, so it pollutes the global namespace. Over time, this can cause conflicts and cashes, especially in large codebases.

Heterogenous Arrays

Suppose our consuming type required an array of houses. With the following snippet we run into the infamous Protocol ‘Housing’ can only be used as a generic constraint because it has Self or associated type requirements error.

Here we have 2 options. The first is to make Street generic, like so:

The problem here, however, is that now we are tied to one particular type of Housing. On our Street we might have multiple types of house like Bungalows and Mansions so this might not always be what we want.

The other solution is to create a type-erasing wrapper in a similar way to how AnyHashable or AnyPublisher work. Here we could create the type-erased AnyHousing, like so:

But oh no! Here we can see that we’ve tied ourselves to one specific type of Inhabitant per house! To fully implement the type erase we need an AnyInhabiting type too. The final result is as follows:

That’s pretty verbose and if we look closely, the implementations of AnyInhabiting and AnyHousing are suspiciously similar to the Inhabitant and House we started off with!

The trick to using structs…

The answer to how we can use structs to perform the same function as protocols is by keeping them simple! We can write the struct in such a way that it holds only the data and functionality required by the consuming type. Instead of conforming to a protocol we can write an adaptor to map any object to our struct.

Suppose following ViewModel. It allows us to define the text and buttonTapped functionality upon initialisation.

We can now add a convenience initialiser in an extension to map from the services we need to call upon.

When it comes to testing our UI layer, there is no need to create an object and conform to a protocol. We can simply provide test functionality and text upon initialisation.

Conclusion

We’ve now seen an alternative to protocols that performs the same function, maintains the same level of testability and simplifies verbose boilerplate code. Seems too good to be true right?

The one caveat I have seen is that some discipline needs to be applied to the initial struct in keeping it as a data-only object (Kotlin style data-classes would be ideal here).

I find this pattern cleaner and less verbose in most cases when compared to protocols, so it continues to be something I use in my daily work

For completeness, here is a gist which continues the House example in the same way!

Why structs are better than protocols for dependency inversion was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.

As an iOS developer, I am forever shocked at how often I see fatalError(“This should never happen”) in production code. This usually arises in situations where an edge case is programatically possible, but logically impossible.

The scenario

Imagine a situation where I’d like an app to catalog the CDs and books on my bedroom shelf. I create an Item struct which tells me the title, and has optional fields for duration and the number of pages depending on if it’s modelling a CD or book.

struct Item {
    var title: String
    var duration: TimeInterval?
    var numberOfPages: Int?
}

This struct leaves me with a problem though. I am able to create an Item with both a duration and a numberOfPages. I am also able to create an Item which has neither field!

When I try to present my Items as rows in a table, the issue becomes apparent:

func makeRow(for item: Item) -> Row {
    if let duration = item.duration {
        return Row(heading: title, subHeading: duration)
    } else if let numberOfPages = item.numberOfPages {
        return Row(heading: title, subHeading: numberOfPages)
    } else {
        fatalError(“This should never happen”)
    }
}

Despite the error message, the fatalError could happen. For my app to crash, I would only have to write the following:

let item = Item(title: “Moby-Dick”)
let row = makeRow(for item) // 💥 Crash here!

It’s concerningly easy to write non-sensical code here, and it’s not immediately obvious from the call site alone that a crash would occur.

What can be done about it?

Any time I am in the situation where I have two mutually exclusive fields, and I need only one, my rule of thumb is to reach for an enum!

By utilising enums, we can structure our code in a way which ensures the compiler will only allow logical states to exist. Once we have eliminated the impossible states, the nonsense fatalErrors disappear!

Take 2: Save me enums!

First, I refactor my code and represent the items with the following enum:

enum Item {
    case song(title: String, duration: TimeInterval)
    case book(title: String, numberOfPages: Int)
}

The row building code now needs refactoring too:

func makeRow(for item: Item) -> Row {
    switch item {
    case let .song(title, duration):
        return Row(heading: title, subHeading: duration)
    case let .book(title, numberOfPages):
        return Row(heading: title, subHeading: numberOfPages)
    }
}

Note how the fatalError has disappeared! There can never be a crash here now, as there can be no invalid Item.

Conclusion

The example presented is clearly contrived, but the architectural pattern is invaluable. I see this problem most commonly in code that handles JSON decoding. Next time you look at structures decoded from JSON, try and spot the mutually exclusive fields. If you end up with an invalid object, chances are your decoding operation should have failed already!

The importance of logical data modelling was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve recently discovered Apple’s Natural Language framework and decided to have a play, test out some ideas and share my findings. This will be a short article about a few things the framework can do and potentially offer some inspiration for your own apps

I started with UITextChecker. As the name implies the text checker does spell checking. You give it a string to check and it spits out the first mis-spelt word. From here you can get the text checker to give some suggestions for what the desired word might be. This is essentially Apple’s version of red squigglies

My immediate though was around search fields and mirroring Google’s “Did you mean x?” functionality. I banged a quick bit of code and voilà! Search field correction suggestions!

Following this, I thought it might be nice to offer suggestions for semantically similar options. As you might have guessed, the Natural Language framework does this too!

By adding the following bit of code, we can get a bunch of similar words. The framework also offers a distance parameter for each of these that indicates how close they are to the original word.

Final thoughts

I can already see how I might use this in apps to provide some nice UX features with minimal complexity. There’s plenty of other cool bits the Natural Language framework can do too, so it’s definitely worth having a play!

Fun with Natural Language Processing was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.

Background

A very common pattern across programming languages is the use of callback functions. A callback function is a reference to executable code passed as an argument to other code, allowing it to be executed at a later time.

In swift we encounter this patten often. One particularly common example is URLSession.dataTask(with:completionHandler:). After a request has been made, the network may take some time to respond. Rather than wait idly, we can give a completion handler to be executed when the response is received allowing the application to proceed in the meantime.

One place we see this pattern in C is in the SQLite3 framework packaged with Swift. SQLite3 facilitates access and manipulation of Structured Query Language databases and is the underlying technology powering CoreData.

As databases can take time to search or alter, SQLite3 provides the function sqlite3_exec with takes a C style callback. When this function is bridged across to Swift the @convention(c) annotation is applied. This annotation denotes that the callback is going to be used in a C context and must follow certain criteria. One of these criteria is that the function cannot capture any data. This poses a problem as we are likely to want to pass the callback arguments onto some other object that exists outside of the callback - we may want pass database information to a view layer example.

Solution

One way many C APIs work around this limitation is by passing an additional context parameter. This allows a reference to some object to be passed through to the callback in addition to the arguments that are returned later. We can then pass the other arguments to the object so they can be transfered outside of the callback scope.

Assume the following setup:

Here we can see that the Callback typealias is marked with the aforementioned @convention(c) annotation. If we modify the code to capture an object within the scope of callback we see the following error:

The way we can work around this is by passing our object as the context argument like so:

Here we create an Unmanaged object which we are expected to manage the lifetime of manually. We convert this to an UnsafeMutableRawPointer so it can be passed into sqlite3_exec as context data. The context data is then passed into our callback where is can be converted back into our Object type ready for use.

passRetained creates a reference keeping the object alive indefinitely until takeRetainedValue is called. At that point, the retain is consumed and the object can be deallocated. If the object was guaranteed to still be alive at the time the callback is executed, passUnretained and takeUnretainedValue could be used, but be aware that if the object goes out of scope, this would result in a crash very similar to how unowned variables work.

Bonus Material

Ideally, we’d like to extend this pattern so we are not reliant on any one object to handle the response of the C API. One way of achieving this is to pass a Swift closure as the context argument. The following repo has an example of that pattern for those who are interested:

Adder/Adder.swift at master · oconnelltoby/Adder

Swift + C: Callback Interoperability was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.

What Is Splatting?

Argument splatting is the concept of extracting the parameters of an object to pass to a function automatically. In Swift this can be done using tuples.

Suppose we had some data and a function that looked like this:

We’d like to pass all our users through the makeGreeting function to generate personalised greetings. One common way to achieve this would be to use the map higher order function like so:

We can make this more concise however by utilising tuple splatting! This will allow our 2 argument function to take a tuple with 2 elements.

Tuple splatting allows us to pass the arguments through without having to extract them from the original data. Note that this can be done with other higher order functions such as filter, flatMap, forEach etc.

Direct splatting

It should be noted that direct splatting cannot work. If we try to call out makeGreeting function with a single tuple we get the following error:

As we know, going through a little indirection like with the map function can solve this problem for us. The following function can be used to achieve that small amount of indirection required:

We can use this new helper like this:

Conclusion

We’ve seen how tuple splatting can be used with higher order function to make code more concise.

Use of the helper certainly make the call site more concise, but it could be argued that it hurts readability. Personally I quite like it, but let me know what you think in the comments :)

Background

Recently I have been implementing a lot of analytics events in a client’s app. Tagging this application (which has a great deal of UI) was always going to a laborious task, so I was looking to architect an ergonomic API to interact with.

Whilst deciding on the interface I remembered the Swift 5.3 feature that allows enum cases to be used as protocol witnesses. This became a great teaching opportunity for the junior I was pairing with. In short, a protocol that requires a static function that returns Self can be satisfied by an enum case with an associated value. Additionally, any static variable of type Self in the protocol can be satisfied by a enum case without an associated value.

Suppose we had the following protocol:

We could satisfy it with the following struct:

Additionally, we could also satisfy the protocol with this enum:

To the API consumer both of these look the same as they are called identically:

The Open-Closed Principle

The Open-Closed principle is one of the 5 SOLID design principles. It states that “software entities should be open for extension, but closed for modification.” What this means is, our API should be extendible without having to change the original source code.

Enum vs Struct

The Open-Closed principle is one place where enums fall down. They cannot be extended to include additional cases, so every time a new event type is added to our protocol, we need to modify the original enums source. This is not the case with a struct that can be extended across multiple files.

One other consideration is the size of the protocol. Currently there are two events, but what happens when the number of events to track explodes? If we had some 60 screens each with 2-5 events we’d end up with around 210 enum cases. These would all have to sit in the same file and in the case of our name variable, we’d have an enormous switch statement too.

In a situation where a backend analytics system can only handle certain events, it may make complete sense to prevent any unknown & unhandled events slipping through by using an enum, but overall I think the struct pattern works best in this scenario.

Conclusion

Using enum cases as protocol witnesses is a cool addition to the Swift language, but we still need to consider if enums are the best tool for the job at hand. As always, when you’ve got a shiny new hammer, it’s tempting to treat everything a nail, but it’s always worth stepping back and assessing the needs of the API & the ergonomics of its ongoing use.

Enums Cases as Protocol Witnesses and the Open-Closed Principle was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.

History

For many years now, the go-to way of encoding and decoding Swift types to JSON has been the Codable protocol.

This gave a more type safe way of handling json than its predecessor JSONSerialization, which spat out [String: Any] dictionaries. Conversely Codable handles conversion upfront, dealing with all the type conversion, and failing if the object cannot be converted successfully.

An additional advantage of Codable is that conformance can be synthesised for many objects if they only contain other Codable or simple types.

The problem

One place common place where Codable conformance cannot be synthesised is when using enums with associated values. The complier will tell us that the type does not conform to Decodable or Encodable.

There are a number of ways of getting around this issue, the most common being to use custom implementations of the Decodable or Encodable protocols. One implementation might look something like this:

Despite the fact that this adds a tremendous amount of boilerplate code, it’s also not reusable. If we have another enum with a different format, we would have to re-write this all again.

Proposals have been made to add Codable synthesis to enums with associated values but as of yet, nothing has been added to the Swift language.

Solution: withUnsafeBytes to the rescue!

One simple solution to solve the problem of reusable conformance for varying types is to use withUnsafeBytes. This allows us to access the underlying memory for a Swift object. We can then use that underlying memory directly or as part of a larger JSON object. Here is a simple (and reusable) protocol that does the encoding for us:

It should be noted that this is not a robust way of serialising data, just a really simple one. Ideally, this data should not be written to disk or transferred between devices as the data format could change between Swift versions or between different devices. Having said that, newer versions of Swift with ABI stability may mitigate this concern somewhat.

I will be using this method to transfer data between my Unit Tests and my Application for testing under different launch conditions. I consider this relatively safe as the device type and Swift version will always match.

Encoding awkward types with minimal boilerplate using `withUnsafeBytes` was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.

Take for example the implementation of Date and Comparable taken from the Swift documentation:

This compares the year, month and day in that order to determine which is greater (later). A simpler (and perhaps more readable) way of writing this same code is this:

The tuple is compared in order of its variables so we achieve the same result.

As an added bonus, the same is true for Equatable conformance:

This last one is a bit of a contrived example as Equatable conformance would be synthesised for Date anyway, but suppose we wanted to omit the year, to compare birthdays, it would be very easy to simply remove year from the tuples

Using tuples for Comparable and Equatable conformance was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.

One major disadvantage to this paradigm is that UIGestureRecognizer only passes the calling object to the called function. This means that if multiple objects call the same function, they need to be differentiable in some way.

Out of curiosity I looked for a solution online. Many suggest using the Objective C runtime to add an Associated Object to manage a closure, but this gets into the realm of hackiness. One cleaner solution I stumbled across was to simply subclass the gesture recogniser and add the action to it:

This simple but elegant solution solves the problem neatly and cleanly. The same solution can also be used for other subclassable target + selector style APIs such as with UIButton.

UIGestureRecognizer with closures was originally published in CodeX on Medium, where people are continuing the conversation by highlighting and responding to this story.