Tag: Swift

As the title suggests, I have a mature data model, and I want to add conformance to Identifiable but (for backwards compatibility reasons) not actually add id as an instance variable

My model object in question already implements Hashable, so plan A was to use the hashValue generate id. Sadly hashValue is an Int and id needs to be a UUID. So how does one convert an Int to a UUID?

As is often the case there was a discussion on StackOverflow offering alternatives. The option that leapt out at me introduced to Swift language options I had never used before.

1. withUnsafeBytes
2. load(fromByteOffset: as:)

withUnsafeBytes is an array ‘operator’ that will (I believe) iterate over all the bytes in the array. load will pour the bytes into a new object whose type is specified by the as: parameter. As somebody who has done a small amount of writing c and ZERO c++ this code feels very foreign to me.

I chose to solve my problems with two pieces of code. First I extended Int like this:

extension Int {
    public var asID: UUID {
        let vals: [Int64] = [Int64(self), 0]
        return vals.withUnsafeBytes { $0.load(as: UUID.self) }
    }
}

I then added Identifiable conformance like this:

extension Thread: Identifiable {
    public var id: UUID {
        return self.hashValue.asID
    }
}

Solving this problem reminded me just how much complexity there is ‘under the hood’ in almost any code we write. I find it amazing that:

1. There are smart people who are well versed in the (obscure?) corners of the software engineering information domain.
2. By invoking an appropriate combination of keywords in the search bar, I can be connected to the helpful guidance created by these smart people.

Yay technology!

For my flash cards app, I’m currently working on the issue of language selection. This app is going to provide users with a list of many words in many languages. Its goal is to give people a tool to use flash cards for learning and maintaining multiple languages.

Consider a person that doesn’t have this app. Let’s assume their native tongue is French, and they want to practice their English and Japanese. The obvious approach would be to spend one chunk of time working between French and English and another chunk of time working between French and Japanese.

But what if they could work between all three languages? Or maybe just between their non-native languages? (English and Japanese in this case) This is the app for that. Maybe they also want to get to level 1 of Norwegian? Just add it to the mix.

To give credit where it is due, I got this idea from a recent episode of The Tim Ferriss Show.

Tim: If you’re getting too much traffic due to this link, my apologies. I’d be happy to remove it, just let me know.

I confess, Tim Ferriss is definitely a celebrity crush of mine, but back to the topic at hand, enums…

This flash cards app is going to start with approximately ten languages, and I want to give users flexibility in choosing what languages/words get shown, and also what languages they will be expected to use for their answers.

I started by defining a list of askLanguages, and a list of answerLanguages. I envisioned two columns of buttons. The column on the left would let users pick the askLanguages and the column on the right would let users pick the answerLanguages.

But there are some invalid combinations.

If a user selects zero answerLanguages, that is obviously not going to work

But if a user selects all the languages for askLanguages, and selects one answerLanguages, that’s not cool either. If you pick Japanese as your only answerLanguage, it doesn’t make sense to also use Japanese as an askLanguage. But if you add Haida as a second answerLanguage, then Japanese is a valid askLanguage. (eg “What is the Haida word for サーモン?” Trick question, Haida has *many* words for salmon.)

If a user selects two askLanguages, their list of answerLanguages needs to include either both the askLanguages, or at least one other language not in the askLanguages list.

When a user has selected values that can’t actually be used, it could be complicated/messy/challenging for the app to convey why their choice won’t work and what they need to change to make it workable.

So instead of giving users this hyper-flexible way to choose, I assumed users’ selection preferences are going to fall into one of a few categories:

• use all the languages, for both asking and answering
• use a subset of languages, for both asking and answering
• use one language for asking (native language perhaps) and all other languages for answering
• use one language for answering and all other languages for asking
• use one language for asking and one language for answering (old school!)

So I defined an enum that captures these specific cases:

enum LanguageChoice: Equatable, Codable {
    case all
    case oneToOne(Language, Language)
    case oneToAll(Language)
    case allToOne(Language)
    case symmetricSubset(Set<Language>)
}

And now all those obscure invalid corner cases go away. The UI to select a language choice starts with a picker with the five possibilities. For most of the picker choices there will a simple second step for users. Typically either:

• pick one item from a list -or-
• pick N items from a list

There are still some invalid cases (eg symmetricSubset requires users to pick at least one language) These cases (so far) are self-evident, and easy to convey to users in the picking UI. The logic to determine validity can be handled via a simple computed property on the enum.

    var isValid: Bool {
        switch self {
        case .oneToOne(let ask, let answer):
            return ask != answer
        case .symmetricSubset(let languages):
            return languages.count > 1
        default:
            return true
        }
    }

And thanks to the great team of people working on the Swift language, encoding and decoding enums with associated values is now built in. This means persisting a users preferred configuration is easy peasy.

If it turns out some users want to specify more complex language choices (eg “I want one askLanguage, and five answerLanguages“) these can be handled with new or modified enum cases. Even if it turns out there is a group of users who want the ‘totally wide open control’ option, it can be handled as a case in the enum. These users will need to navigate the invalid cases described above, but all the users that select less problematic options can remain blissfully unaware of this complexity.

(Not a book by JK Rowling, tho I’m sure many people would purchase and read Harry Potter and the Codable Protocol)

I’m working on a project where I need to write code to convert the following JSON into a structure:

{  "en" : { "stringUnit" : {
              "state" : "translated",
              "value" : "Cat" } },
    "fr" : { "stringUnit" : {
              "state" : "translated",
              "value" : "Chat" } },
    "ja" : { "stringUnit" : {
              "state" : "translated",
              "value" : "ねこ" } }
}

To accomplish this, I created the following model objects:

typealias LocalizationsDict = [String: Localization]

struct Localization: Codable, Equatable {
    let stringUnit: StringUnit
}

struct StringUnit: Codable, Equatable {
    let state: String
    let value: String
}

The code to decode a LocalizationsDict looked like this:

        let languages: LocalizationsDict = try JSONDecoder().decode(LocalizationsDict.self, from: data)

Everything was working wonderfully. But then I got greedy. (queue the jump scare music.) I wanted to see if the keys could be an enum, instead of a String. I felt this would make the code safer, and would mean languages could be types using autocomplete. (The jury may still be out on whether necessity or laziness is truly the mother of invention.)

Here was the code needed to create the Language enum:

enum Language: String, Codable {
    case en = "en"
    case fr = "fr"
    case ja = "ja"
}

Unfortunately…in order for a Swift dictionary to conform to Codable, its key type must be either String or Int. For a Swift dictionary with any other type of key, decode will assume the JSON will be represented as an array, where the first item is the first key, the second item is the first value, third item is the second key, etc.
Thank you Apple Dev forums, yet again. https://developer.apple.com/forums/thread/747665

This would mean the JSON would need to be stored like this:

[  "en", { "stringUnit" : {
              "state" : "translated",
              "value" : "Cat" } },
    "fr", { "stringUnit" : {
              "state" : "translated",
              "value" : "Chat" } },
    "ja", { "stringUnit" : {
              "state" : "translated",
              "value" : "ねこ" } }
}

Sadly, in this situation, the JSON was being generated by the metaphorical ‘somebody else’ and I didn’t have the option to change the format of my incoming JSON.

Instead I added a step when decoding this type of Dictionary. Here’s a code snippet:

typealias LocalizationsDict = [Language: Localization]
typealias LocalizationsDict2 = [String: Localization]

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        let stringKeyedLocalizations = try container.decode(LocalizationsDict2.self, forKey: .localizations)
        var enumKeyedLocalizations: LocalizationsDict = [:]
        for (key, value) in stringKeyedLocalizations {
            if let enumKey = Language(rawValue: key) {
                enumKeyedLocalizations[enumKey] = value
            }
        }
        self.localizations = enumKeyedLocalizations
    }

The details of what’s happening are as follows:

1. Decode the JSON to a [String: Localization] dictionary
2. Create an empty [Language: Localization] dictionary
3. Iterate through the [String: Localization] dictionary
4. For each entry, verify it’s possible to create a valid enum value from the language string. (eg map "en" to Language.en
5. For each entry store the value in the [Language: Localization] dictionary, using the enum key generated in the previous step.

This works, but I thought this seemed like an interesting shortcoming in Swift.